How TIBER-FI works and who can require it in Finland
If your Finnish financial entity has been told, or expects to be told, to run a threat-led test, the first thing to know is that TIBER-FI is the Bank of Finland's implementation of TIBER-EU, and the Financial Supervisory Authority (FIN-FSA) is the authority that can require threat-led penetration testing under DORA. The Bank of Finland states that this requirement can be met through a test that complies with the TIBER-FI framework, so the two regimes are designed to run as one process rather than two parallel exercises.
Cost, timing and the exact deliverables depend on three things: the scope of the entity's critical or important functions and the systems behind them, the formal requirements its competent authority sets for that entity, and the state of its own environment. The roles are distinct. The Bank of Finland, through its TIBER-FI team (TCT-FI) and test managers, runs the TIBER-FI procedures and guidelines. FIN-FSA decides whether a DORA threat-led test is required and what the entity must formally deliver. The entity owns its controls, prepares its control team and blue team, and carries the cost of its own test and remediation. Any external providers work for the entity within that structure.
Before engaging anyone, confirm in writing with FIN-FSA whether a requirement has been issued to your entity, the test frequency it has set, and which formal deliverables it expects. Then review the Bank of Finland's published TIBER-FI framework and its procedures so your scope document and procurement plan match them. Cybersecurity providers who want to follow TIBER-FI communications and attend periodic provider meetings can write to tiberfi@bof.fi, which is the route the Bank of Finland gives for that purpose.
Who is involved in a TIBER-FI test
The TIBER-FI team, known as TCT-FI, sits at the Bank of Finland and includes test managers. It runs the test on the authority side: it receives the notification, starts the test, supervises the scope and the procurement, and keeps the test within the TIBER-EU process. The team reviews the outputs at each stage, including the targeted threat intelligence report, the red team test plan and the test reports. The test manager is the day-to-day point of contact for the tested entity during the test.
- Owns: the process, the timelines, the supervision of the test and the review of each key deliverable.
- Owns: the assessment of the test results that feeds the closing documents, including the attestation.
- Must not: take over the entity's controls, decide how the entity fixes its weaknesses, or run the red team attacks itself.
- Must not: treat a test as a pass or fail exercise, since TIBER-EU tests show strengths and weaknesses.
- Confirm: with the Bank of Finland which contact, channel and document formats it expects from your organization.
Before the test starts, ask the TIBER-FI team who your named test manager will be and how the authority wants scope and procurement documents submitted.
The tested entity owns its controls, and its control team is the internal group that manages the test on the entity's side. The control team, which the 2025 framework renamed from the White Team, coordinates with the authority, protects the test's confidentiality, controls the flow of information to the red team and keeps the test inside agreed limits. The blue team is the group that defends the systems in the test, detects activity and responds to it. The blue team's work is measured during the test, so its reports are part of the evidence.
- Owns: the systems in scope, the controls, the detection and response work, and any remediation after the test.
- Owns: the internal knowledge of which people and systems are critical, kept secret from the red team until the test design requires it.
- Must not: tip off the blue team or alter the test environment outside the rules the control team sets.
- Must not: expect the Bank of Finland or the testers to issue reports or certificates on the entity's behalf.
- Confirm: the internal reporting lines and the names of people who may be told about the test, so the control team can protect that secrecy.
Your control team should be named and briefed before the procurement phase begins, since its role runs from the preparation phase through to the closure.
The threat intelligence provider is procured by the tested entity and approved within the TIBER-FI process. It prepares the targeted threat intelligence report, which describes the threat actors and scenarios most relevant to the entity, and it identifies the flags that the red team will try to reach. The provider's output shapes the entire testing phase, so its independence and quality matter. It does not run the attacks or supervise the closing documents.
- Owns: the targeted threat intelligence report and the scenario selection that builds on it.
- Owns: the work within the agreed scope, the sources it uses and its own confidentiality obligations.
- Must not: perform red team attacks or act as a tester on the same test.
- Must not: share the entity's information with third parties or use it outside the agreed engagement.
- Confirm: the provider's selection criteria and the procurement requirements the Bank of Finland publishes through its TIBER-FI communications, including the guidance on service provider procurement.
Ask any shortlisted provider how it separates its threat intelligence work from red team work and how it handles the test's sensitive information.
The red team testers carry out the active attacks against the flags during the testing phase, under the supervision of the control team and the test manager. They write the red team test plan before testing starts and the red team test report afterwards, and they take part in the replay and purple teaming in the closure phase. Their role is to reproduce realistic attack paths within the agreed rules, not to damage systems or access data beyond what the scope allows.
- Owns: the red team test plan, the attack activity inside the agreed rules and the red team test report.
- Owns: the safe handling of any data or access obtained during testing, including its deletion or return as the rules require.
- Must not: act outside the scope, attack systems or flags that the control team has not approved, or continue after a stop condition.
- Must not: write or issue the closing documents as if they were the authority's, or present their findings as a certificate.
- Confirm: the testers' qualifications and contractual terms, and the escalation route if a test causes unexpected impact.
Before signing, confirm how the testers handle stop conditions and what happens to evidence they collect.
How a TIBER-FI test moves through its phases
The sequence runs from a written notification through threat intelligence, red team testing and closure, and each phase ends with a defined output that the next phase depends on. The Bank of Finland's TIBER-FI 2.0 documents set the Finnish detail, so confirm each handover against them before work starts.
Receive written notification and initiate the test
The preparation phase begins when the authority gives the tested entity written notification that a TIBER-FI test is required or proceeding. The entity then holds an initiation meeting with the TIBER-FI team (TCT-FI), where the test manager explains the process and the roles of the five parties. The output is an agreed initiation document. Confirm the notification route, contacts and document templates in the TIBER-FI 2.0 procedures.
Set up the control team and risk management
The entity appoints a control team, which supervises the test on its behalf and keeps it safe for live systems. The entity also agrees its risk management arrangements for the test, including how the red team's activity is controlled and escalated. The output is a named control team and a documented risk management approach that the test manager has reviewed. Confirm the Finnish requirements for control team composition with the Bank of Finland.
Agree the scope and flags
The entity and the test manager identify its critical or important functions and the ICT systems that support them. The team then sets the flags, which are the specific objectives the red team will try to reach to show what an attacker could achieve. The output is a scope specification document approved by the test manager. Ask the authority which systems must be included and how third-party services are handled.
Procure the threat intelligence and red team providers
The entity procures a threat intelligence provider and red team testers that meet the framework's requirements for suitability, independence and experience. The contracts must align with the procedures set by the TIBER-FI framework. The output is signed contracts and a provider-approved team, all confirmed to the test manager before testing begins. Review the Finnish provider expectations in the TIBER-FI 2.0 documents and the Bank of Finland's guidance on provider communications.
Produce the targeted threat intelligence report
The threat intelligence provider researches threat actors likely to target the entity and selects the attack scenarios the red team will use. The provider then writes a targeted threat intelligence report, which the control team and test manager review. The output is an approved report that sets the scenarios and the red team test plan builds on. Check the report's scope against the flags before the red team begins.
Run active red team testing against the flags
The red team executes its approved test plan against the flags for at least 12 weeks of active testing, under supervision of the control team and test manager. The control team manages the test so that live services are not disrupted, and the blue team is kept unaware of the exercise. The output is a logged record of active testing that marks its end date, which starts the closure deadlines.
Deliver closure reports, replay and purple teaming
Within 10 weeks of active testing ending, the red team issues its test report and the blue team issues its own. The parties then run a replay, where the red team walks through its attack path with the blue team, followed by purple teaming to test detection and response improvements. The output is both reports and a record of the replay and purple teaming sessions. Confirm the Finnish closure timelines in the TIBER-FI 2.0 procedures.
Issue the summary, remediation plan and attestation
The 360 degree feedback is collected, and the test manager and entity produce the test summary report. The entity then writes a remediation plan within 8 weeks of the authority's assessment, setting out how it will address the weaknesses found. The test closes with an attestation confirming the test followed the framework. The output is the test summary report, the remediation plan and the signed attestation, which the entity uses as evidence in its DORA threat-led testing record.
When FIN-FSA can require a DORA threat-led test
In Finland, the Financial Supervisory Authority (FIN-FSA) is the authority that can identify financial entities that must carry out threat-led penetration testing (TLPT) under Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA). An entity that FIN-FSA identifies must test at least every three years. FIN-FSA can ask for testing more or less often depending on the entity's risk profile, so the interval is not fixed for every firm. The first decision for a board or CISO is whether the entity has been identified at all, because that determines whether the test is mandatory or voluntary. Confirm your status directly with FIN-FSA rather than assuming it from the size of your organization or your sector.
The Bank of Finland says the DORA requirement can be met through testing that complies with the TIBER-FI framework. Meeting it, however, depends on satisfying the formal requirements that FIN-FSA sets for the test, such as who must be involved, how the test is documented, and how results are reported to the supervisor. These formal requirements sit on top of the shared core requirements of TIBER-EU and DORA TLPT. Ask FIN-FSA in writing which formal requirements apply to your entity, whether any of them differ from the standard TIBER-FI procedures, and what it expects to receive at each stage. Settle these points before you procure providers or write a scope, because changes made later can affect the timeline and cost.
Plan for the three-year cycle now, not when the notice arrives. Record which of your critical or important functions and ICT systems would be in scope, keep your provider procurement and contract terms ready, and confirm how your current testing and remediation records would be presented to the authority. If FIN-FSA has not identified your entity, a voluntary TIBER-FI test can still build capability, but it will not count as the DORA requirement unless FIN-FSA confirms otherwise in writing. Treat that confirmation as a formal question for the authority, and do not rely on general guidance to answer it.
How cybersecurity providers engage with TIBER-FI
Cybersecurity providers who want to work on TIBER-FI tests usually start with the Bank of Finland, then prepare for the procurement steps set out in the ECB's TIBER-EU guidance. The cards below cover the practical routes and the points to confirm directly with the Bank before any bid.
Contact the Bank for communications
Providers interested in TIBER-FI can write to tiberfi@bof.fi to ask to receive TIBER-FI communications and to be considered for the periodic provider meetings the Bank of Finland invites. Send a short note identifying your firm, the services you offer (threat intelligence, red teaming or both) and the Finnish or Nordic market you cover. Ask the Bank how it will notify providers of changes to its TIBER-FI 2.0 procedures before you plan any staffing around them.
Review the ECB procurement guidance
The ECB published guidance on service provider procurement with the 2025 TIBER-EU framework. Read it before you engage with the Bank, because it describes how a tested entity selects threat intelligence and red team providers in the preparation phase. Compare its expectations with your own certifications, references and team structure so you can answer procurement questions quickly and accurately.
Confirm threat intelligence qualifications
Ask the Bank of Finland which qualifications and experience it expects from the threat intelligence provider, who produces the targeted threat intelligence report that shapes the test scenarios. Confirm whether the Bank or the tested entity sets these requirements, and whether any evidence must be supplied in writing. Do not assume that a qualification held for another TIBER-EU country applies in Finland.
Confirm red team qualifications
Confirm with the Bank which qualifications, references and team arrangements it requires from red team testers, including how it treats testers who work across several jurisdictions. Ask whether the requirements differ between voluntary TIBER-FI tests and tests that meet the DORA threat-led penetration testing requirement set by FIN-FSA. Keep a record of the answers, since they will form part of your bid.
Plan for the authority's role
FIN-FSA is the authority that can require threat-led penetration testing under DORA, so a provider may be asked to work on a test that FIN-FSA has required. Ask the Bank how it coordinates with FIN-FSA on scope and timing, and which parties you will report to during the test. Clarify early who holds the contract, since the tested entity procures the providers under the framework.
What a TIBER-FI test costs and who is paid for each part
This table lists each cost component of a TIBER-FI test, who pays for it, whether it is one-time or recurring within the three-year cycle, and what drives it. Use it to build your questions for the Bank of Finland and for each provider before you commit to a scope.
| Cost component | Who is paid or who bears the cost | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Authority team time (TIBER-FI team and test managers) | Bank of Finland staff time; not billed as a provider fee unless the Bank states otherwise | Recurring per test cycle | Confirm in writing whether any Bank costs are passed to the entity. Ask what the entity must still fund. |
| Threat intelligence provider | Paid by the tested entity under its own contract | One-time per test | Scope of the targeted threat intelligence report and number of scenarios. Request a written, scoped quote. |
| Red team testers | Paid by the tested entity under its own contract | One-time per test | Length of active testing (at least 12 weeks under TIBER-EU), number of flags and systems in scope. Request a written, scoped quote. |
| Entity control team and blue team staff | Internal payroll of the tested entity | One-time per test, plus time before and after | Number of staff released from normal duties and the closure work, including replay and purple teaming. Estimate internal hours with your own managers. |
| Procurement and project management | Internal staff or an outside advisor paid by the entity | One-time per test | How many providers you procure and how much coordination the Bank expects. Confirm the procurement steps with the TIBER-FI team. |
| Remediation work | Internal teams or vendors chosen by the entity | Recurring until closed, often beyond the test cycle | Number and severity of weaknesses in the remediation plan. Remediation is not a test fee, so budget it separately. |
| Next test within the three-year cycle | Entity, through the same provider types | Recurring every three years as the norm | Changes to systems, scope and risk profile can shift the cycle. Confirm the next testing date with the Bank. |
What a financial entity should have in place before a TIBER-FI test
Before a TIBER-FI test starts, the entity needs its governance, its critical functions and its test boundaries settled. The four items below are drawn from the preparation phase of TIBER-EU, which the Bank of Finland applies through TIBER-FI, and each can be checked against the initiation documents and the scope specification guidance published by the ECB.
A named control team
The control team is the group inside the entity that knows the test is happening and manages it on the entity's side, while the blue team defends without that knowledge. Confirm that named individuals hold this role, that they have authority to stop or steer the test, and that the list of members is current. Check the arrangement against the ECB's guidance on the control team, which the Bank of Finland points to for TIBER-FI.
Risk management arrangements for the test
A TIBER-EU test runs live attacks against production-grade systems, so the entity must agree in advance how risk is managed, who can halt activity and how the authority is informed. Ask for a written risk management approach that covers test boundaries, escalation paths and rules for handling incidents caused by the red team. Confirm that these arrangements are documented before the scope is fixed.
An inventory of critical functions
The scope starts from the entity's critical or important functions, and the systems that support each one. Build a current inventory that maps each function to its underlying ICT systems, data flows and third-party dependencies, and mark which of these the entity considers critical. Check that the inventory matches what the scope specification document will ask for, since gaps here delay the whole preparation phase.
Agreed flags and scope
Flags are the target assets or objectives that the red team tries to reach, and the scope specification records which functions, systems and locations are in play. Agree the flags with the authority and the control team, then confirm that each flag traces back to a critical function. Exclusions, such as systems the entity cannot test, should be written down with the reason, because the red team cannot test around them later.
A procurement route for independent providers
TIBER-EU requires the entity to procure a threat intelligence provider and red team testers from outside its own organization, and the authority reviews that procurement. Decide the route early, including how providers are shortlisted, how contracts and confidentiality terms are handled, and who signs. Ask the Bank of Finland for the current guidance on service provider procurement, and check that providers can meet the framework's requirements for independence and quality.
Questions about TIBER-FI and DORA threat-led testing
Can FIN-FSA's DORA threat-led testing requirement be met through TIBER-FI?
Yes. The Bank of Finland says the requirement can be met through testing that complies with the TIBER-FI framework, and FIN-FSA is the authority that can require threat-led penetration testing under DORA. The ECB states that the core requirements of DORA TLPT and TIBER-EU are identical, so a TIBER-FI test that meets those core requirements is positioned as DORA TLPT compliant. The entity still has to meet the formal requirements that FIN-FSA sets for its own case, so confirm those with the authority before scoping. Entities identified for TLPT must test at least every 3 years, and FIN-FSA may ask for more or less frequent testing based on the entity's risk profile.
How long does a TIBER-FI test take from start to finish?
The TIBER-EU framework sets fixed windows for each phase, and Finland applies the same framework. Preparation lasts up to six months from the authority's written notification. Active red team testing runs for at least 12 weeks under supervision. Replay and purple teaming take place within 10 weeks of the end of active testing, and the remediation plan is due within 8 weeks of the authority's assessment. The total calendar time depends on how long providers take to procure, how the scope is agreed and how many feedback loops the test needs. Ask the Bank of Finland to confirm any timing specific to its TIBER-FI 2.0 procedures before you commit to a schedule.
What must a financial entity provide for a TIBER-FI test?
The entity must supply people, scope information and procurement support, and it must carry the test through to closure. In practice this means:
- A named control team and blue team, with a clear point of contact for the test manager and the TIBER-FI team (TCT-FI)
- A scope specification covering the critical or important functions and the flags the threat intelligence and red team work will target
- Support for procuring the threat intelligence provider and red team testers under the framework's rules
- Access to systems, documentation and staff during active testing, under control team and test manager supervision
- A remediation plan and the closure attestation, based on the red team and blue team reports and the test summary report
Can our own team run a TIBER-FI test without outside providers?
No. A TIBER-EU test involves five parties: the TIBER Cyber Team and test manager at the authority, the control team and blue team at the tested entity, a threat intelligence provider and red team testers. The threat intelligence and red team work must be carried out by independent providers, and the authority oversees the whole process. Your internal staff can fill the control team and blue team roles, but they cannot replace the external providers. DeployOpen plans, hardens and documents self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for compliance assessments. It does not issue reports or attestations, and it should not be assumed to act as a TIBER-FI provider. Confirm with the Bank of Finland which roles an outside firm may take.
How do we contact the Bank of Finland about TIBER-FI?
Write to tiberfi@bof.fi. The Bank invites cybersecurity providers interested in TIBER-FI communications and periodic provider meetings to use that address, and entities that need to understand their status or the procedures can ask the same team. Read the TIBER-FI framework and the TIBER-FI 2.0 procedures and guidelines on the Bank of Finland's TIBER-FI page first, since most questions about scope, roles and process are answered there. The ECB's TIBER-EU guidance documents, which the Bank points to, cover the individual deliverables in more detail. When you write, state whether you are an entity that may be identified for testing or a provider, and name the systems or functions you expect to be in scope.
What drives the cost of a TIBER-FI test up or down?
No price or budget figure has been published for this page, so the cost depends on the written scope. The main cost components are the fees for the threat intelligence provider and the red team testers, which the entity procures, plus internal staff time for the control team and blue team, and the work needed to fix weaknesses after the test. Costs rise with the number of critical or important functions and flags, the number of systems and locations in scope, the length of active red team testing, and the depth of replay and purple teaming. Costs fall when the scope is tightly defined, systems and evidence are already documented, and the entity's detection and response processes are mature. Ask any quote to be itemized by phase and role, to state which fees are one-time and which recur on the three-year cycle, and to list the assumptions about flags and scope.
What an implementation partner can and cannot do
An implementation partner such as DeployOpen can help a financial entity get ready for a TIBER-FI test, but it cannot take over the roles that the framework assigns to others. In practice, DeployOpen can prepare the systems in scope, document the controls the entity owns, assemble the evidence the control team will need, and help the entity's own staff prepare for the preparation phase, including the scoping of critical or important functions and flags. The entity keeps ownership of its controls and decisions. DeployOpen does not issue the attestation, a test summary report, or any other report or certificate. Those documents come from the entity and the Bank of Finland's TIBER Cyber Team, and assurance statements come only from independent parties.
Two roles need particular care. DeployOpen does not act as the threat intelligence provider or the red team tester for a TIBER-FI test if that would conflict with the procurement rules that apply to those providers. The entity must procure both providers in its own right, and a firm that helped prepare the systems may face restrictions on bidding for the testing itself. Before engaging any firm, ask the Bank of Finland in writing which independence and conflict rules apply, whether a preparation role affects eligibility for the testing roles, and what documentation the Bank expects the entity to keep. Contact tiberfi@bof.fi to confirm these points, and ask whether provider meetings are open to the firm before the engagement starts.
The scope document should state exactly what the partner will and will not do, so that the Bank, the entity and the partner read the same boundaries. A useful written scope lists the systems prepared, the evidence delivered, the people involved, and the points where the partner hands work back to the entity. DeployOpen agrees such scope in writing before work starts, and any change to the roles in a TIBER-FI test should be reviewed against the independence rules before it is made.
How DeployOpen prepares systems and evidence for a threat-led test
DeployOpen works on the preparation side of a TIBER-FI test: the systems, controls and documentation that a regulated entity needs before its threat-led test begins. We run in the client's own infrastructure and do not issue reports, attestations or certifications, which remain with the independent testers and the authorities.
How we scope
- We agree the written scope for the critical systems and functions the entity puts forward for TIBER-FI testing.
- We map which environments, networks and platforms fall inside the scope and which sit outside it, in writing.
- Engagements are fixed-scope, so deliverables and timelines are agreed before any work starts.
How we build
- We plan, implement and harden the self-hosted open-source platforms that support the in-scope systems inside the client's own infrastructure.
- We configure logging, monitoring and access records so the control team can review what the testers touched.
- We run security testing of applications, APIs and infrastructure ahead of the formal test to surface weaknesses the entity can fix in time.
How we hand over
- We document system architecture, configurations, control owners and evidence locations so the entity can present them to its testers and authority.
- We prepare runbooks for backup, upgrade and recovery so the entity can operate the platforms after the engagement closes.
- We hand over the documentation and evidence in a structured form that the entity keeps under its own control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- Ask us to confirm which TIBER-FI deliverables the written scope covers and which the entity owns internally.
- Confirm with FIN-FSA and the Bank of Finland which formal requirements apply to your entity before scoping starts.
Sources and further reading
- TIBER-FI framework, Bank of Finland ↗
- Adopting TIBER-EU will help fulfil DORA requirements (September 2024), ECB ↗
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
- Commission Delegated Regulation (EU) 2025/1190 (TLPT RTS), EUR-Lex ↗
- TIBER-EU framework, European Central Bank ↗
- TIBER-ES Implementation Guide (January 2022), Banco de Espana ↗
