DORA Resilience Testing and TLPT Requirements

DORA penetration testing obligations represent one of the most operationally demanding requirements imposed by the Digital Operational Resilience Act on financial entities in the European Union. Articles 24 through 27 of Regulation (EU) 2022/2554 establish a two-tier testing regime: a baseline programme of digital operational resilience testing applicable to all in-scope entities, and an advanced threat-led penetration testing (TLPT) programme reserved for entities identified by competent authorities. According to the European Supervisory Authorities, fewer than 15% of financial entities had a structured resilience testing programme meeting DORA standards before the regulation entered into application on 17 January 2025.

This article explains both tiers in full, the TIBER-EU framework underpinning advanced testing, the qualifications required for TLPT testers, the purple teaming component, and how the proportionality principle affects smaller entities. For the broader regulatory context, see our complete DORA compliance guide.

What Is Digital Operational Resilience Testing Under DORA?

Article 24 requires every financial entity to establish, maintain, and review a sound and comprehensive digital operational resilience testing programme. This is not optional. Every entity within scope of DORA — from the largest systemically important credit institutions to smaller payment institutions and electronic money institutions — must implement a testing programme proportionate to its size, business profile, and risk exposure.

The testing programme must be integrated into the broader ICT risk management framework required under Articles 5 through 16. It serves as the verification mechanism: where the risk management framework defines policies and controls, the testing programme validates whether those controls actually function under realistic conditions.

Article 24(1) specifies that the programme must include a range of assessments, tests, methodologies, practices, and tools. The results must feed back into the ICT risk management framework as lessons learned, driving continuous improvement. A 2024 ECB supervisory review found that 67% of significant institutions needed to materially enhance their testing programmes to meet DORA standards.

What Are the Basic Testing Requirements for All Entities?

Article 25 defines the baseline tier of testing applicable to all financial entities. This tier requires a range of tests and assessments that collectively cover the entity’s ICT environment. The specific testing activities mandated include:

Vulnerability Assessments and Scans

All entities must conduct regular vulnerability assessments across their ICT infrastructure. This includes automated scanning of systems, applications, and network components against known vulnerability databases. Article 25(1) explicitly lists vulnerability assessments as a mandatory testing category. Given that the ENISA Threat Landscape 2024 recorded over 25,000 new CVEs published in a single year, regular vulnerability scanning is the minimum baseline for any financial entity.

Network Security Testing

Entities must test the security of their network architectures, including perimeter defences, segmentation controls, intrusion detection and prevention systems, and access management configurations. This includes both internal and external network penetration tests. Financial entities subject to DORA who also fall within the scope of the NIS2 Directive will find that network security testing obligations overlap substantially between the two frameworks.

Gap Analyses, Software Reviews, and Source Code Reviews

Article 25 further requires gap analyses against applicable standards, physical security reviews where relevant, software security testing, and — where proportionate and risk-justified — source code reviews of critical ICT systems. Source code reviews apply particularly to proprietary systems supporting critical or important functions, as well as to bespoke software developed by or for the entity.

The gap analysis requirement forces entities to benchmark their existing controls against DORA’s prescriptive standards. A 2025 Deloitte survey on DORA readiness indicated that 41% of mid-tier financial entities identified material gaps during their first structured gap analysis, particularly in business continuity testing and third-party resilience provisions.

How Often Must Basic Testing Be Conducted?

Article 25(2) requires all entities to establish an approach for prioritising, classifying, and remediating issues identified through testing. Recital 43 of DORA clarifies that the testing programme should be conducted at least annually for ICT systems and applications supporting critical or important functions. This annual cycle applies to all entities without exception.

Financial entities must document their testing plans, execute tests according to the plan, and report findings to the management body. Under Article 5, the management body retains accountability for overseeing implementation of the testing programme. Competent authorities may request evidence of testing execution and remediation at any time.

Who Must Perform Advanced TLPT?

The second tier of DORA’s testing regime is threat-led penetration testing under Articles 26 and 27. This advanced requirement does not apply universally. Only financial entities specifically identified by their competent authority are required to conduct TLPT. The identification decision is based on an impact assessment that considers:

• The entity’s systemic importance
• The criticality of the ICT services and functions it provides
• Specific ICT risk factors, including the entity’s ICT risk profile and maturity
• The potential impact of ICT disruptions on financial stability

Article 26(8) states that competent authorities must identify the financial entities required to perform TLPT. According to the ECB, approximately 100 to 150 significant institutions in the euro area are expected to be designated for mandatory TLPT, though exact numbers depend on national competent authority decisions. Banks and credit institutions with large retail footprints or those providing critical market infrastructure are the most likely candidates.

What Is the TLPT Testing Cycle?

Entities identified for TLPT must carry out such testing at least every three years. Each TLPT must cover several critical or important functions of the financial entity and must be performed on live production systems. Article 26(2) explicitly prohibits testing exclusively on non-production environments — the test must simulate realistic attack scenarios against the systems that actually run in production.

The three-year cycle is a minimum. Competent authorities may require more frequent testing based on the entity’s risk profile or in response to emerging threats. Each TLPT exercise must be scoped to cover a sufficient range of critical functions to provide meaningful assurance about the entity’s resilience posture.

How Does TLPT Align with the TIBER-EU Framework?

Article 26(1) requires that TLPT be conducted in accordance with the TIBER-EU framework. TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) was developed by the European Central Bank as a standardised approach for conducting intelligence-led red team testing of entities’ critical live production systems. DORA effectively elevates TIBER-EU from a voluntary good practice to a legal requirement for designated entities.

The TIBER-EU process follows a structured lifecycle:

1. Generic Threat Landscape — analysis of the broader threat environment facing the financial sector
2. Targeted Threat Intelligence — bespoke intelligence gathering focused on the specific entity’s attack surface, threat actors, and vulnerabilities
3. Red Team Testing — execution of realistic attack scenarios based on the threat intelligence, targeting live production systems
4. Closure and Remediation — debriefing, findings documentation, and remediation planning

Article 26(3) specifies that each TLPT must include the threat intelligence phase and the actual red team execution phase. The threat intelligence informs the attack scenarios, ensuring that testing reflects plausible, current threats rather than arbitrary or outdated techniques. A 2023 ECB analysis of TIBER-EU exercises conducted across the euro area found that 78% of tested institutions had at least one critical finding requiring immediate remediation.

What Are the Requirements for TLPT Testers?

Articles 26 and 27 impose strict qualification requirements on those conducting TLPT. These requirements go well beyond standard penetration testing procurement.

External, Certified, and Independent

Article 27(1)(a) mandates that TLPT testers must be external to the financial entity. Internal red teams cannot conduct the TLPT exercise alone. Testers must possess the highest professional suitability and competence, hold relevant certifications, demonstrate technical expertise in threat intelligence, penetration testing, and red teaming, and carry professional indemnity insurance.

Article 27(1)(b) further requires that TLPT testers be certified or accredited by a Member State authority, or adhere to formal codes of conduct and ethical frameworks. Independence is non-negotiable: the testing firm must have no conflicts of interest that could compromise the objectivity of the exercise.

There is one limited exception. Article 27(2) permits financial entities to use internal testers for the red team execution phase, provided that the competent authority grants explicit approval, the entity has sufficient in-house resources, and an external threat intelligence provider is engaged for the threat intelligence phase. Even in this scenario, the threat intelligence must come from an external, independent source.

What Is the Purple Teaming Requirement?

Article 26(4) introduces a mandatory purple teaming component. At the conclusion of the red team testing phase, the financial entity must conduct a purple team exercise. Purple teaming brings together the red team (attackers) and the entity’s internal blue team (defenders) to collaboratively review the attack scenarios, detection failures, and response gaps identified during the test.

This is not a suggestion — DORA makes purple teaming a required element of every TLPT cycle. The purpose is to ensure that the entity’s defensive teams understand the specific attack techniques used, evaluate why controls failed or succeeded, and develop targeted improvements. Purple teaming transforms the TLPT exercise from a point-in-time assessment into an active learning process.

The purple team exercise must produce documented findings that feed into the entity’s ICT risk management framework and inform updates to detection rules, incident response procedures, and security architecture.

How Does the Proportionality Principle Apply?

DORA’s resilience testing regime is explicitly subject to the proportionality principle. Article 24(2) directs that the testing programme be established with due regard to the entity’s size, business, and risk profiles. This applies to the basic testing tier; TLPT applies only to entities specifically designated by competent authorities.

For smaller entities — particularly those qualifying under the simplified ICT risk management framework described in Article 16 — the testing obligations are calibrated accordingly. A micro-enterprise with limited ICT infrastructure is not expected to maintain the same testing cadence or sophistication as a global systemically important bank. However, proportionality does not mean exemption. Even the smallest in-scope entities must conduct appropriate testing activities aligned with their risk profile.

In practice, proportionality affects the following dimensions:

• Scope: smaller entities may limit testing to their most critical systems rather than the full ICT estate
• Frequency: while annual testing of critical functions remains the baseline, the breadth of each cycle may be reduced
• Methodology: automated vulnerability scanning and standardised assessments may substitute for bespoke manual testing
• Source code reviews: these are risk-justified rather than universally mandatory, and smaller entities with minimal proprietary software may reasonably exclude them

Entities evaluating how to build a proportionate testing programme while managing compliance costs should consider platforms that centralise compliance documentation and workflow. Legiscope, for example, enables financial entities already managing GDPR obligations to extend their compliance infrastructure into DORA testing documentation, leveraging existing records and processes.

How Does DORA Penetration Testing Interact with Other Frameworks?

Financial entities rarely operate under DORA alone. The resilience testing requirements intersect with several other regulatory and voluntary frameworks.

The NIS2 Directive imposes security testing obligations on essential and important entities, many of which are also financial entities subject to DORA. Article 4(2) of DORA contains a lex specialis provision: where DORA’s requirements are more specific than NIS2’s, DORA takes precedence. In practice, an entity performing DORA-compliant resilience testing will exceed NIS2 baseline requirements.

ISO 27001 Annex A controls on vulnerability management and technical compliance testing align with DORA’s basic testing tier. Entities certified under ISO 27001 will have an existing testing structure, but must ensure it meets DORA’s specific requirements around scope, frequency, and management body reporting.

For entities evaluating DORA compliance software, testing programme management — including scheduling, evidence capture, findings tracking, and remediation workflows — is a critical capability to assess in any platform.

Frequently Asked Questions

What is dora penetration testing?

DORA penetration testing refers to the two-tier digital operational resilience testing regime established under Articles 24 through 27 of the Digital Operational Resilience Act. It includes basic testing for all in-scope financial entities and advanced threat-led penetration testing (TLPT) for entities designated by competent authorities. The basic tier covers vulnerability assessments, network security tests, gap analyses, software reviews, and source code reviews. The advanced TLPT tier requires intelligence-led red team testing on live production systems at least every three years.

Which financial entities must perform TLPT?

Only financial entities specifically identified by their competent authority must perform TLPT. The designation is based on systemic importance, criticality of ICT services, risk profile, and potential impact on financial stability. Estimates suggest 100 to 150 significant institutions in the euro area will be designated, but exact determinations rest with national competent authorities.

Can internal teams conduct TLPT?

Article 27(2) permits internal red teams only if the competent authority grants explicit approval, the entity has adequate in-house capability, and the threat intelligence phase is conducted by an external provider. In all other cases, the full TLPT exercise must be performed by external, certified, independent testers.

How often must resilience testing be performed?

Basic resilience testing of ICT systems supporting critical or important functions must be conducted at least annually. Advanced TLPT must be conducted at least every three years for designated entities. Competent authorities may require more frequent testing based on risk assessments.

What is purple teaming under DORA?

Purple teaming is a mandatory component of every TLPT exercise under Article 26(4). It brings together the external red team and the entity’s internal blue team to jointly review attack scenarios, analyse detection gaps, and develop remediation plans. The objective is to convert testing findings into concrete defensive improvements.

Does DORA testing apply to smaller financial entities?

Yes. All in-scope financial entities must implement a resilience testing programme proportionate to their size and risk profile. Smaller entities benefit from the proportionality principle, which permits reduced scope, simpler methodologies, and exclusion of activities like source code reviews where not risk-justified. However, no in-scope entity is exempt from basic testing requirements.