DORA requires certain financial entities to conduct threat-led penetration testing at least once every three years. This requirement, codified in Articles 26 and 27 of Regulation (EU) 2022/2554, is not a repackaging of the annual penetration test your security team already commissions. It is a fundamentally different exercise — one that simulates real-world adversary behaviour against your live production environment, based on genuine threat intelligence about the actors most likely to target your specific organisation.
The distinction matters because the preparation, cost, and organisational disruption involved in TLPT are an order of magnitude beyond standard testing. Getting it wrong does not just mean a failed audit finding. It means a botched exercise that consumed months of senior leadership attention, hundreds of thousands in fees, and produced results that neither your risk committee nor your competent authority find credible.
TLPT vs Regular Testing: What Makes Threat-Led Different
DORA Article 24 requires all financial entities to establish a digital operational resilience testing programme. This includes vulnerability assessments, open-source analysis, network security assessments, gap analyses, and penetration testing. These are the standard testing activities that most mature financial institutions already conduct.
Articles 26 and 27 sit above this baseline. They mandate threat-led penetration testing — a specific methodology that differs from standard penetration testing in several critical dimensions.
Threat intelligence drives the scope. In a standard pentest, the scope is defined by the client: "test these IP ranges, these applications, these network segments." In TLPT, the scope is driven by a threat intelligence phase that identifies the specific threat actors, tactics, techniques, and procedures (TTPs) most relevant to the target entity. The red team simulates these specific adversaries, not a generic attacker model. If the threat intelligence identifies a state-sponsored group with a history of targeting the entity's sector, the red team replicates that group's tradecraft.
Testing occurs on live production systems. Standard penetration tests often run against staging or pre-production environments. TLPT, by definition, tests the entity's actual production environment — the systems that process real transactions, hold real customer data, and support real business operations. This is where operational risk enters the picture. The entity must manage the exercise so that testing activity does not cause an actual incident.
The exercise simulates real compromise, not just vulnerability identification. A standard pentest identifies vulnerabilities and demonstrates exploitability, often stopping at proof-of-concept. TLPT goes further: the red team attempts to achieve specific objectives (data exfiltration, transaction manipulation, access to critical systems) that reflect what a real adversary would pursue. The exercise tests not just whether vulnerabilities exist, but whether the entity's detection and response capabilities would identify and contain a genuine attack.
Three distinct teams operate in coordination. TLPT involves a threat intelligence provider, a red team, and the entity's own blue team (which operates without advance knowledge of the exercise). After the red team phase, a purple team exercise brings red and blue teams together to review findings, test additional scenarios, and develop remediation plans. This structure is more complex and more personnel-intensive than standard testing.
Who Must Conduct TLPT
Not every financial entity subject to DORA is required to conduct TLPT. Article 26(1) establishes that competent authorities shall identify which financial entities are required to perform TLPT based on several criteria:
- Impact-related factors: the systemic importance of the entity, the criticality of the services it provides, and its interconnectedness with other financial entities
- ICT risk profile: the nature, scale, and complexity of the entity's ICT systems and the types of data they process
- Proportionality: the entity's overall risk profile and its degree of ICT maturity
The competent authority — the entity's primary financial supervisor (ECB for significant credit institutions under SSM, national competent authorities for others) — makes the determination. The entity does not self-select into the TLPT requirement. Instead, the competent authority notifies the entity that it must conduct TLPT and may specify the scope of critical or important functions to be tested.
In practice, TLPT will apply to:
- Systemically important credit institutions (G-SIBs and O-SIIs under ECB supervision)
- Central counterparties (CCPs)
- Central securities depositories (CSDs)
- Large payment institutions and electronic money institutions
- Significant insurance and reinsurance undertakings
- Trading venues operating critical market infrastructure
- ICT third-party service providers designated as critical (CTPPs) under DORA Article 31
Medium-sized financial entities — a regional bank with moderate systemic importance, a smaller asset manager, a niche payment service provider — are less likely to be identified for TLPT. However, the competent authority has discretion, and entities that process high volumes of sensitive data or provide infrastructure services to other financial entities may be identified despite their smaller size.
The Article 26(1) identification process is not a one-time decision. Competent authorities review and update the list of entities required to conduct TLPT. An entity not currently identified may be added in a future cycle based on changes in its systemic importance, risk profile, or the broader threat landscape.
The TIBER-EU Framework Relationship
TLPT under DORA did not emerge in a vacuum. It builds directly on TIBER-EU (Threat Intelligence-Based Ethical Red Teaming), a voluntary framework published by the European Central Bank in 2018. TIBER-EU was adopted by multiple Member States as a national framework (TIBER-DE, TIBER-NL, TIBER-BE, TIBER-FI, and others) before DORA codified TLPT as a regulatory requirement.
DORA Article 26(2) explicitly references TIBER-EU, stating that TLPT shall be carried out "in accordance with the European framework for threat-led penetration testing" referred to in Article 26(11). The European Supervisory Authorities (ESAs) were mandated to develop regulatory technical standards (RTS) on TLPT that align with TIBER-EU.
The practical consequence: if your entity has previously conducted TIBER-EU testing, you are substantially prepared for DORA TLPT. The methodology, the three-phase structure, the provider requirements, and the competent authority oversight model are closely aligned. The primary differences are:
- DORA TLPT is mandatory for identified entities, whereas TIBER-EU was voluntary
- DORA specifies a minimum frequency of every three years, whereas TIBER-EU left frequency to national discretion
- DORA's RTS on TLPT introduce additional standardisation on reporting formats and competent authority involvement
- DORA explicitly permits pooled testing (Article 26(4)), which TIBER-EU addressed less formally
For entities that have not previously participated in TIBER-EU, the framework's publicly available documentation provides an excellent preparation resource. The TIBER-EU framework document, the TIBER-EU Services Procurement Guidelines, and national implementation guides (particularly TIBER-DE and TIBER-NL, which are among the most mature) describe the process in operational detail.
Three Phases: Preparation, Testing, Closure
TLPT follows a structured three-phase process. Each phase has distinct deliverables, stakeholders, and timelines.
Phase 1: Preparation and Threat Intelligence (8-12 weeks)
The preparation phase establishes the scope and produces the threat intelligence report that will guide the red team.
Scoping. The entity, in consultation with its competent authority, defines which critical or important functions will be included in the test. DORA Article 26(2) requires that the scope cover "critical or important functions" and that testing be performed on "live production systems supporting such functions." The scoping decision is consequential — too narrow, and the exercise fails to test the entity's resilience at meaningful scale; too broad, and the exercise becomes unmanageable.
Threat intelligence engagement. A specialised threat intelligence provider conducts a targeted threat intelligence assessment. This is not a generic threat landscape report. It identifies the specific threat actors most likely to target the entity, analyses their known TTPs, and produces a targeting report that the red team will use to design its attack scenarios. The threat intelligence provider must be independent from the red team to ensure the intelligence is objective.
Control team establishment. The entity establishes a small control team (typically 2-4 senior individuals) that manages the exercise. The control team knows the exercise is occurring; the entity's broader security and IT teams (the blue team) do not. The control team's role is to manage operational risk — ensuring that red team activity does not cause genuine harm to production systems — and to serve as the liaison between the entity, the red team, and the competent authority.
Phase 2: Red Team Testing (12-16 weeks)
The red team executes attack scenarios based on the threat intelligence report. The testing is conducted against live production systems, with the red team attempting to achieve specific objectives defined during the scoping phase.
The red team operates covertly. The entity's blue team — its SOC, incident response team, and security monitoring capabilities — should not be informed that a test is underway. The purpose is to assess whether the entity's defences detect and respond to adversary activity under realistic conditions.
During the testing phase, the control team maintains oversight. If red team activity risks causing genuine operational disruption (data loss, service outage, regulatory reporting obligations), the control team can modify or halt specific test actions. This safety mechanism is essential for testing on production systems.
The red team documents its activities in detail: initial access vectors, lateral movement paths, privilege escalation techniques, detection evasion methods, and whether the blue team detected and responded to the activity at each stage. This documentation forms the basis for the closure phase.
Phase 3: Purple Team and Closure (4-8 weeks)
After the red team phase concludes, a purple team exercise brings the red and blue teams together. The red team reveals its attack paths and techniques. The blue team reviews its detection logs, identifies where it detected (or failed to detect) activity, and works with the red team to understand gaps.
The purple team phase is where the operational value of TLPT concentrates. Identifying that the red team achieved a specific objective is useful; understanding why the blue team's detection failed at a specific point in the kill chain is actionable. The purple team session produces specific remediation recommendations tied to observed detection gaps.
The entity produces a TLPT report that summarises findings, the red team's assessment, the purple team outcomes, and a remediation plan. This report is submitted to the competent authority. DORA Article 26(6) requires that the competent authority validate the TLPT results, confirm that the testing was conducted in accordance with applicable standards, and review the entity's remediation plan.
The Pooled Testing Option
DORA Article 26(4) permits financial entities to conduct TLPT on a pooled basis where multiple entities share ICT third-party service providers. This provision addresses a practical problem: if ten banks all use the same core banking platform provider, conducting ten separate TLPT exercises against that provider's infrastructure is neither efficient nor desirable.
Under pooled testing, one TLPT exercise covers the shared infrastructure, with results shared among the participating entities and their respective competent authorities. The ICT third-party service provider participates directly, and the exercise tests the shared infrastructure's resilience rather than requiring each financial entity to independently test the same systems.
This option is particularly relevant for entities that rely heavily on cloud service providers, core banking platform vendors, or payment processing infrastructure. The entity still bears responsibility for conducting TLPT on its own critical functions that are not shared — but the pooled option significantly reduces the burden for shared infrastructure.
The resilience testing framework under DORA requires careful coordination between the entity's TLPT obligations and its broader digital operational resilience testing programme. TLPT addresses the most critical functions on a three-year cycle; the annual testing programme under Article 24 covers the broader landscape.
Selecting a TLPT Provider
Competent authorities impose requirements on TLPT providers. DORA Article 27 specifies that TLPT testers shall:
- Be of "the highest suitability and reputability"
- Possess technical and organisational capabilities specifically relevant to threat-led penetration testing
- Hold certifications from an accreditation body in a Member State, or adhere to formal codes of conduct or ethical frameworks
- Provide independent assurance relating to the sound management of risks associated with the test, including protection of the entity's confidential information
- Be covered by professional indemnity insurance
The entity may use internal testers for certain aspects, but DORA Article 27(1)(a) requires that an external tester be used at least for every third TLPT exercise. Where internal testers are used, the competent authority must approve the arrangement, and the entity must demonstrate that no conflict of interest exists.
In practice, the TLPT provider market is concentrated. A relatively small number of firms have the combination of threat intelligence capability, red team expertise, and experience operating within TIBER-EU or equivalent frameworks that competent authorities will recognise. Engaging a provider early — 6 to 12 months before the planned exercise start date — is advisable, particularly given the increasing demand as DORA TLPT obligations activate.
Provider selection criteria beyond regulatory requirements should include:
- Sector experience: a provider with experience testing entities in the same financial sub-sector (banking, insurance, market infrastructure) will produce more credible threat intelligence and more realistic attack scenarios
- Competent authority relationships: providers with established relationships with the relevant competent authority can navigate the oversight process more efficiently
- Operational safety track record: TLPT on production systems carries inherent risk; the provider's history of managing exercises without causing operational disruption is a material selection criterion
Operational Preparation: What to Do Before the Exercise Starts
Entities identified for TLPT should begin preparation well before the testing window. Key preparation activities include:
Identify critical and important functions. DORA Article 3(22) defines "critical or important function" as a function "the disruption of which would materially impair" the entity's financial performance, service continuity, or ongoing compliance. This identification drives the TLPT scope and should align with the entity's existing ICT risk assessment under DORA Article 6.
Establish the control team. Select senior individuals (typically from risk, IT security leadership, and legal) who can manage the exercise. The control team must have authority to modify or halt testing and direct access to senior management. Brief the control team on TLPT methodology and their specific responsibilities.
Prepare legal documentation. TLPT involves a third party attempting to compromise live production systems. Legal agreements must cover liability, data handling (the red team will inevitably access production data), incident reporting obligations (if a genuine incident occurs during testing), and confidentiality. The entity's legal team should engage early.
Review detection and response baseline. Before the exercise, the CISO should ensure that security monitoring, logging, and incident response procedures are functioning as designed. TLPT will test these capabilities under pressure; known gaps in logging coverage or detection rules should be addressed beforehand. Not because the goal is to "pass" the test — it is not a pass/fail exercise — but because known-broken detection capabilities produce findings that are obvious rather than insightful.
Engage the competent authority. Competent authorities are involved throughout the TLPT lifecycle. Early engagement — informing the authority of the planned timeline, proposed scope, and selected providers — establishes the working relationship and allows the authority to provide guidance on its expectations.
Budget and timeline realistically. A TLPT exercise, from preparation through closure, typically spans 6 to 9 months. Costs vary by scope but generally range from €200,000 to €500,000 for the threat intelligence and red team engagement alone, excluding internal staff time. Entities conducting TLPT for the first time should plan for the upper end of both dimensions.
Using Fortis Arena for resilience testing simulation and preparation can help teams build familiarity with adversary-driven testing methodologies before committing to the full TLPT engagement.
Key Takeaways
- TLPT is not a pentest. It is a threat-intelligence-driven, production-environment exercise that simulates specific adversary TTPs. The methodology, cost, and organisational commitment are fundamentally different from standard penetration testing.
- Not every DORA entity must conduct TLPT. Competent authorities identify which entities are required based on systemic importance, ICT risk profile, and proportionality. If you have not been notified, you are likely not currently in scope — but the list is reviewed periodically.
- Preparation starts 6-12 months before testing. Control team establishment, legal documentation, provider selection, competent authority engagement, and scoping all require lead time. Entities approaching their first TLPT cycle should begin preparation immediately.
- Pooled testing reduces burden for shared infrastructure. If your critical functions depend on third-party infrastructure shared with other financial entities, Article 26(4) permits coordinated TLPT that avoids redundant testing of the same systems.