> cat /regulation/EU/2022-2554/chapter-iv.txt | grep 'penetration' && echo 'mandatory'_
The Digital Operational Resilience Act — Regulation (EU) 2022/2554, known as DORA — came into force on 16 January 2023 and has been applicable since 17 January 2025. It establishes a comprehensive legal framework for managing ICT risk across the EU financial sector, covering everything from risk management and incident reporting to third-party oversight and — critically — digital operational resilience testing.
Before DORA, penetration testing in financial services was a patchwork of national frameworks, voluntary guidelines, and industry expectations. Some entities tested rigorously. Others treated it as a checkbox exercise. Many tested only because a client contract or insurance policy required it. DORA changes this fundamentally: it creates a uniform, legally binding testing obligation across all EU member states, with two distinct tiers of requirements depending on the entity's systemic importance.
For the most significant financial entities, DORA goes further still — mandating Threat-Led Penetration Testing (TLPT): a full-scale, intelligence-driven red team exercise conducted against live production systems, under supervisory oversight, with mandatory purple teaming. This isn't a vulnerability scan. It's a regulated adversary simulation designed to test whether the entity can withstand a realistic cyberattack.
DORA's scope is deliberately broad. Article 2 defines 20 categories of financial entity subject to the regulation. The testing requirements apply to all of them — though the intensity of testing varies by the entity's size, systemic importance, and the nature of its operations.
| Entity Type | General Testing (Articles 24–25) | TLPT (Articles 26–27) |
|---|---|---|
| Credit institutions (banks) | Required — annual testing of all ICT systems supporting critical or important functions. | Required for Global Systemically Important Institutions (G-SIIs) and other significant credit institutions as identified by the TLPT authority. At least every 3 years. |
| Payment institutions and electronic money institutions | Required — annual testing programme. | May be required if identified as significant by the TLPT authority based on ICT risk profile and systemic importance. |
| Investment firms | Required — annual testing programme. | May be required for significant firms as identified by the relevant competent authority. |
| Insurance and reinsurance undertakings | Required — annual testing programme. | May be required for significant undertakings based on systemic importance and ICT risk profile. |
| Central securities depositories, central counterparties, trading venues | Required — plus mandatory vulnerability assessments before any deployment or redeployment of new applications and infrastructure. | Required — these entities form part of the critical financial infrastructure. |
| Crypto-asset service providers | Required — annual testing programme. | May be required based on systemic importance as the sector matures. |
| ICT third-party service providers | Not directly subject to DORA testing requirements, but financial entities must ensure their critical ICT providers participate in testing — including TLPT where required. | Must be contractually required to participate in the financial entity's TLPT under Article 30(3)(d). Designated critical ICT third-party providers are subject to the ESA oversight framework. |
| Microenterprises (fewer than 10 employees, turnover/balance sheet under €2 million) | Simplified requirements — risk-based approach with proportionate testing, balancing resources against risk. | Exempt from TLPT requirements. |
Articles 24 and 25 establish the general digital operational resilience testing programme. This is the baseline tier — applicable to all financial entities except microenterprises — and it requires a comprehensive, ongoing testing programme that covers all ICT systems and applications supporting critical or important functions.
| Requirement | What DORA Mandates | Article Reference |
|---|---|---|
| Testing programme | Financial entities must establish, maintain, and review a sound and comprehensive digital operational resilience testing programme as an integral part of their ICT risk management framework. | Article 24(1) |
| Annual testing | At least yearly, appropriate tests must be conducted on all ICT systems and applications supporting critical or important functions. | Article 24(6) |
| Independence | Tests must be undertaken by independent parties, whether internal or external. Where internal testers are used, sufficient resources must be dedicated and conflicts of interest avoided throughout design and execution. | Article 24(7) |
| Types of testing | The programme must include (as appropriate): vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, scanning software solutions, source code reviews (where feasible), scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. | Article 25(1) |
| Pre-deployment testing | Central securities depositories and central counterparties must perform vulnerability assessments before any deployment or redeployment of new or existing applications, infrastructure components, and ICT services supporting critical or important functions. | Article 25(2) |
| Remediation | Financial entities must establish procedures and policies to prioritise, classify, and remediate all issues identified during testing. They must establish internal validation methodologies to confirm that all identified weaknesses, deficiencies, or gaps are fully addressed. | Article 24(5) |
| Continuous improvement | Lessons from resilience testing, real-life ICT-related incidents, and cyber-attacks must be incorporated into the ICT risk assessment process on a continuous basis. | Article 24(4) / Article 13(4) |
Article 25's list of testing types is not exhaustive — it's a non-prescriptive range of appropriate tests. The regulation deliberately avoids mandating a specific methodology, recognising that the appropriate testing approach depends on the entity's size, nature, complexity, and risk profile. What it does require is that the programme is comprehensive, that it covers all critical systems, and that it's conducted at least annually.
TLPT is the advanced tier — reserved for financial entities whose failure or disruption would have systemic consequences. It is not a standard penetration test. DORA defines TLPT as "a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity's critical live production systems."
The Regulatory Technical Standards (RTS) specifying the detailed requirements for TLPT were finalised by the European Supervisory Authorities (EBA, EIOPA, and ESMA) in July 2024, adopted by the European Commission on 13 February 2025 as Commission Delegated Regulation (EU) 2025/1190, and entered into force on 8 July 2025. The RTS are developed in accordance with the TIBER-EU framework — the European framework for threat intelligence-based ethical red teaming — which was itself updated in February 2025 to align with DORA's requirements.
| TLPT Requirement | Detail |
|---|---|
| Frequency | At least every three years, unless a different frequency is specified by the TLPT authority. Each test must cover several or all critical or important functions, and must be performed on live production systems. |
| Scope | Must cover critical or important functions of the financial entity. Where these functions have been outsourced to ICT third-party service providers, the TLPT scope must include those providers — and the financial entity must contractually ensure their participation (Article 30(3)(d)). |
| Threat intelligence phase | Before the red team engagement begins, a threat intelligence provider produces a Targeted Threat Intelligence Report — identifying the real-world threat actors most likely to target the specific financial entity, their tactics, techniques, and procedures, and the most realistic attack scenarios. This intelligence drives the red team's approach. |
| Red team testing | External testers (red team) execute the attack scenarios against the entity's live production systems, simulating realistic adversary behaviour. The test must be conducted without the knowledge of the entity's defensive security teams (blue team) to ensure realistic conditions. |
| Mandatory purple teaming | The RTS makes purple teaming mandatory in the closure phase. After the red team exercise concludes, red and blue teams collaborate in a structured purple team session — replaying the attack techniques, identifying detection gaps, and developing improved detection and response capabilities. This was previously encouraged but optional under TIBER-EU. |
| Supervisory oversight | TLPTs are conducted under the oversight of the designated TLPT authority — which may be a national competent authority or, for significant credit institutions, the European Central Bank. The TLPT authority is involved throughout: from scoping and planning through to reviewing results and the remediation plan. |
| Attestation | Upon completion, the TLPT authority issues a formal attestation confirming the test was conducted in accordance with DORA requirements (Article 26(7)). This attestation enables mutual recognition — a TLPT conducted under one member state's authority is recognised across the EU. |
A DORA TLPT is a structured, multi-phase exercise involving distinct teams with defined roles. Understanding the team structure is essential to understanding how the test operates.
| Phase | What Happens | Key Deliverables |
|---|---|---|
| 1. Preparation | Scope defined in consultation with the TLPT authority. Control team established. External providers engaged. Risk management arrangements agreed. Rules of engagement documented. | Scope document. Risk management framework. Provider contracts. Rules of engagement. |
| 2. Threat intelligence | External threat intelligence provider produces the Targeted Threat Intelligence Report based on the entity's threat landscape, sector-specific threats, and the defined scope. | Targeted Threat Intelligence Report. Attack scenarios derived from real-world threat actors and TTPs. |
| 3. Red team testing | Red team executes the attack scenarios against live production systems. Blue team is unaware. Testing may span weeks to months depending on the scope and scenarios. The control team monitors safety and manages any escalations. | Red team activity logs. Evidence of compromise. Attack path documentation. |
| 4. Closure (including mandatory purple teaming) | Red team exercise concludes. Blue team is informed. Mandatory purple team session: red and blue teams collaborate to replay attack techniques, assess detection and response effectiveness, identify gaps, and develop improved defences. | Purple team report. Detection gap analysis. Improved detection rules and response procedures. |
| 5. Remediation | Financial entity produces a remediation plan addressing all findings. The plan is reviewed by the TLPT authority. Remediation is tracked and validated. | Remediation plan. Implementation evidence. Validation results. |
| 6. Attestation | The TLPT authority reviews all deliverables and issues a formal attestation confirming the TLPT was conducted in accordance with DORA requirements. This attestation enables EU-wide mutual recognition. | Formal TLPT attestation. |
DORA sets specific requirements for testers — both for general resilience testing and for TLPT. Article 27 establishes the qualifications, and the RTS provides further detail.
| Requirement | General Testing (Articles 24–25) | TLPT (Articles 26–27) |
|---|---|---|
| Independence | Tests must be undertaken by independent parties — internal or external. Conflicts of interest must be avoided. | External testers required. Internal testers permitted subject to conditions (see below). Threat intelligence provider must always be external. |
| Qualifications | Testers must be suitably qualified. No specific certification mandated for general testing. | Testers must be of the highest suitability and reputability, with specific expertise in threat intelligence, penetration testing, or red team testing. Must be certified by an accreditation body in a member state or adhere to formal codes of conduct or ethical frameworks. |
| Insurance | Not specifically mandated. | External testers must be fully covered by relevant professional indemnity insurance, including against risks of misconduct and negligence. |
| Internal testers | Permitted with appropriate independence and resources. | Permitted subject to: approval by the TLPT authority, adequate internal resources, no conflicts of interest, and the threat intelligence provider must be external. Critically, where internal testers are used, every third TLPT must be conducted by an external provider (Article 26(8)). |
| Confidentiality | Testers must manage findings securely. | Agreements must require sound management of TLPT results — including generation, storage, aggregation, reporting, communication, and destruction — ensuring no risks are created for the financial entity (Article 27(2)). |
DORA's TLPT requirements are developed "in accordance with the TIBER-EU framework" — the Eurosystem's voluntary framework for threat intelligence-based ethical red teaming. In February 2025, TIBER-EU was updated to align with the DORA RTS. The two are now closely aligned, but they are not identical.
| Aspect | TIBER-EU (Pre-DORA) | DORA TLPT |
|---|---|---|
| Legal status | Voluntary framework. Adopted at national level (TIBER-BE, TIBER-LU, TIBER-DK, TIBER-DE, etc.). No legal obligation to participate. | Legally binding regulation. Directly applicable in all EU member states from 17 January 2025. Non-compliance carries penalties under national law. |
| Scope | Financial entities that voluntarily adopted the framework or were encouraged by national authorities. | All financial entities identified by TLPT authorities based on systemic importance, ICT risk profile, and financial stability concerns. |
| Purple teaming | Strongly encouraged but not mandatory. | Mandatory in the closure phase. This is one of the most significant changes. |
| Terminology | White Team managed the process internally. | Renamed to Control Team for consistency with DORA. |
| Mutual recognition | Limited. National frameworks varied in implementation. | Full mutual recognition across the EU via the attestation mechanism. A TLPT attested in one member state is recognised in all others. |
| Enforcement | No penalties for non-participation. | National penalties for non-compliance. For example, Germany's Banking Act (KWG §56(5e)(3)) imposes fines for TLPTs not carried out, carried out incorrectly, incompletely, or not in a timely manner. |
Financial entities that have previously completed TIBER-EU exercises are well positioned for DORA TLPT — the testing process, the team structure, and the deliverables are fundamentally similar. The key differences are the legal obligation, mandatory purple teaming, and the formal attestation mechanism that enables EU-wide mutual recognition.
DORA enforcement is implemented through national law, with competent authorities in each member state responsible for supervisory activities. The consequences of non-compliance are significant.
| Consequence | Detail |
|---|---|
| Regulatory fines | Member states implement penalties through national law. Germany's KWG already provides for fines where TLPT has not been carried out or has been carried out incorrectly, incompletely, or not in a timely manner. Other member states are implementing equivalent provisions. |
| Supervisory action | Competent authorities can require financial entities to take specific actions — including ordering additional testing, requiring remediation within a defined timeframe, or restricting certain activities until deficiencies are addressed. |
| Reputational impact | Non-compliance with DORA signals to clients, counterparties, and insurers that the entity has not met the minimum standard for digital operational resilience in the EU financial sector. |
| Insurance implications | Cyber insurers increasingly reference DORA compliance when assessing risk. Non-compliance may affect coverage terms, premiums, or eligibility — particularly where the insurer can demonstrate that mandated testing would have identified or prevented the exploited vulnerability. |
DORA has transformed penetration testing in the EU financial sector from a best practice into a legal obligation. The regulation establishes two tiers: a general resilience testing programme (Articles 24–25) requiring annual testing of all ICT systems supporting critical functions, and Threat-Led Penetration Testing (Articles 26–27) requiring intelligence-driven red team exercises against live production systems for systemically significant entities — at least every three years, with mandatory purple teaming and supervisory oversight.
The RTS on TLPT, in force since July 2025, provides the detailed operational framework aligned with TIBER-EU. Financial entities that have previously participated in TIBER-EU exercises have a strong foundation. Those that haven't must build their testing programmes from the ground up — establishing the governance, selecting qualified providers, updating third-party contracts, and preparing for a level of testing rigour that many have not previously experienced.
The message from EU regulators is unambiguous: digital operational resilience is no longer demonstrated by policy documents and risk registers alone. It's demonstrated by testing — regular, comprehensive, and, for the most significant entities, conducted under supervisory oversight with a level of rigour that reflects the systemic risk these entities carry. Penetration testing under DORA isn't a compliance exercise. It's the mechanism by which the EU financial sector proves it can withstand the cyber threats it faces.
We deliver DORA-aligned penetration testing programmes for financial entities — from annual resilience testing under Articles 24–25 through to supporting TLPT exercises under Articles 26–27. Our reports are designed to feed your ICT risk management framework, satisfy supervisory expectations, and provide the evidence of digital operational resilience that DORA demands.