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.
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(1) requires financial entities other than microenterprises to establish, maintain and review a sound and comprehensive digital operational resilience testing programme. Microenterprises have specific proportionate testing duties under Article 25(3), and eligible Article 16 entities have the simplified framework’s requirements. Distinguish those provisions before choosing a programme.
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(2) 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.
Which Basic Testing Requirements Apply?
Article 25 gives a range of appropriate assessments and tests for the programme, applied under the Regulation’s risk-based and proportionate approach. It does not require every entity to perform every listed method in every cycle. Document why selected methods adequately address the relevant systems and risks.
Vulnerability Assessments and Scans
Vulnerability assessments and scans are among the methods listed in Article 25. Define the assets, authenticated access where appropriate, coverage limits and process for evaluating findings. A scan result should lead to prioritised remediation and verification, not merely be archived as proof that a tool ran.
Network Security Testing
Assess network architecture, perimeter controls, segmentation, detection and access management, and select appropriate tests for the risks. Define whether internal or external penetration testing is needed and what systems it covers. A provider or group company may separately fall within NIS2; assess that scope rather than assuming every DORA entity duplicates NIS2 testing obligations.
Gap Analyses, Software Reviews, and Source Code Reviews
Article 25 lists gap analyses, physical-security reviews, software-security testing and source-code reviews where feasible, alongside other testing methods. Choose and justify methods that address the actual risks. For a proprietary critical application, explain what the review covers and what remains dependent on supplier assurance.
A gap analysis compares the actual control position with the applicable requirements. Distinguish design gaps from operating failures: a documented backup policy and a failed restore exercise require different corrective actions.
How Often Must Basic Testing Be Conducted?
Article 24(6) requires entities other than microenterprises to perform appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. Article 24(5) requires procedures for prioritising and remedying issues and validating that weaknesses have been addressed. Article 25(2), by contrast, concerns vulnerability assessments by central securities depositories and central counterparties before relevant deployment or redeployment.
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
Competent authorities identify entities under Article 26, with detailed criteria in Delegated Regulation (EU) 2025/1190. Retain the actual identification and supervisory instructions. Banking teams can connect the testing decision to their wider governance and supervisory evidence using the bank implementation guide. Microenterprises and Article 16(1) entities are excluded from the Article 26(1) TLPT requirement.
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 Regulation sets testing at least every three years, but Article 26(1) allows the competent authority, based on risk profile and operational circumstances, to reduce or increase that frequency where necessary. Use the applicable authority decision when scheduling the next exercise.
How Does TLPT Align with the TIBER-EU Framework?
DORA Articles 26–27 and Delegated Regulation 2025/1190 provide the legal requirements. The ECB’s 2025 TIBER-EU framework is operational guidance aligned with those requirements. Do not describe Article 26(1) as incorporating every TIBER document by name.
The TIBER-EU process follows a structured lifecycle:
- Generic Threat Landscape — analysis of the broader threat environment facing the financial sector
- Targeted Threat Intelligence — bespoke intelligence gathering focused on the specific entity’s attack surface, threat actors, and vulnerabilities
- Red Team Testing — execution of realistic attack scenarios based on the threat intelligence, targeting live production systems
- Closure and Remediation — debriefing, findings documentation, and remediation planning
The detailed TLPT standards specify preparation, threat intelligence, red-team testing, closure and remediation. Keep the threat scenarios linked to the entity’s critical functions, with authority involvement at the prescribed stages. A generic penetration-test report cannot demonstrate completion of this process.
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.
Competence, Independence and Internal Testers
Article 27 requires suitability, competence, relevant capabilities, appropriate assurance or ethical frameworks, safeguards for confidential information and suitable professional indemnity cover. Evaluate the actual team and contractual protections; a generic “TIBER-certified” marketing label is not the statutory test.
Internal testers are permitted only under the approval and safeguards in Articles 26–27 and the technical standards. These include appropriate resources, conflict-of-interest controls and external threat intelligence. Significant credit institutions under the SSM use external testers. Where internal testers are used, Article 26 requires external testers for at least every third test. Confirm the detailed conditions with the TLPT authority before procurement.
What Is the Purple Teaming Requirement?
Purple teaming is addressed in the detailed TLPT methodology under Delegated Regulation 2025/1190. In the closure phase, testers and defenders work through the exercise to identify how detection and response can improve. Article 26(4) itself concerns pooled testing with ICT third-party providers; it is not the purple-teaming clause.
Apply the closure and purple-teaming requirements in the technical standards to the exercise. 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.
When a test identifies a weak alert path, a detection use-case validation card can record a safe test action, expected telemetry, observed alert and retest decision after a rule change. This operational check supports the finding record; it does not replace the TLPT closure requirements.
How Does the Proportionality Principle Apply?
DORA’s resilience testing regime is explicitly subject to the proportionality principle. Article 24(1) refers to Article 4(2)’s proportionality criteria, while Article 24(3) requires a risk-based approach to the programme. This applies to the basic testing tier; TLPT applies only to entities specifically designated by competent authorities.
For smaller entities, distinguish ordinary proportionality, provision-specific microenterprise treatment and eligibility for Article 16. Headcount alone does not determine the simplified framework. Article 25(3) expressly requires microenterprises to combine a risk-based approach with strategic planning and balance the resources, time and risks involved.
In practice, proportionality affects the following dimensions:
- Scope: justify coverage against risk while meeting the applicable duty to test all systems and applications supporting critical or important functions; size is not a blanket coverage exemption
- Frequency: apply the annual obligation where Article 24(6) applies, and separately document the applicable microenterprise or simplified-framework approach
- 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
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.
For covered financial entities, the sector-specific interaction follows DORA Article 1(2) and NIS2 Article 4. A supplier may independently be in NIS2 scope. A test performed under DORA should not be presented as an automatic determination that every NIS2 obligation is satisfied.
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.
Prepare the evidence before booking the test
Start with the authority’s identification and scope process, a map of the critical functions, live systems and providers, and the intended control-team membership. Confirm who can authorise actions, pause testing, handle an actual incident and protect sensitive evidence. Identify a service dependency that the proposed scope misses before agreeing the statement of work.
For a payment platform, the scope might include authentication, transaction processing and supporting provider systems. The control team must understand what an interruption could affect and the agreed safeguards. A provider’s refusal to permit an activity is a planning issue to resolve through the applicable authority and contractual process, not permission to silently remove a critical dependency from scope.
At closure, map each finding to an owner, action, target date and validation method. Keep the red-team result distinct from management’s remediation decision. When a fix is declared complete, retain the evidence of validation and update the ICT risk framework. Where a finding concerns provider access or cooperation, reopen the contract assessment. This makes the exercise a source of verified improvements rather than a certificate stored until the next cycle.
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?
The obligation concerns entities identified under Article 26 and the applicable technical standards, excluding microenterprises and Article 16(1) entities. Confirm the actual authority position for the entity; a forecast of how many firms will be selected is not a designation.
Can internal teams conduct TLPT?
Internal testers require the applicable authority approval, resources, independence controls and external threat intelligence. Significant SSM credit institutions use external testers; entities permitted to use internal testers must also comply with the periodic external-test requirement.
How often must resilience testing be performed?
Article 24(6) requires appropriate tests at least yearly on systems and applications supporting critical or important functions for entities other than microenterprises. Designated TLPT entities follow Article 26’s three-year rule and any authority adjustment. Check separate microenterprise and Article 16 requirements.
What is purple teaming under DORA?
The TLPT technical standards provide the purple-teaming and closure methodology. Testers and defenders examine scenarios, detection gaps and remediation together. Cite that methodology rather than Article 26(4), which concerns pooled testing.
Does DORA testing apply to smaller financial entities?
Smaller entities still have applicable testing obligations, but microenterprises are expressly treated differently in Articles 24 and 25. Article 16 eligibility is category-based. Document the applicable regime before deciding scope, methods and frequency.
FAQ
What is TLPT under DORA?
Threat-Led Penetration Testing (TLPT) is an advanced cyber resilience test mandated by Article 26 DORA for significant financial entities. Based on the TIBER-EU framework, TLPT simulates real threat actor techniques against live production systems using intelligence-led scenarios developed from current threat intelligence.
Which financial entities must conduct TLPT under DORA?
Significant financial entities designated by competent authorities based on: systemic importance, scale of ICT operations, risk profile, and nature of activities. Typically: large banks (credit institutions), significant insurers, major payment institutions, and systemically important market infrastructures.
How often must TLPT be conducted?
Article 26(1) DORA requires TLPT every 3 years. Competent authorities can require more frequent testing. Results are confidential but may be shared with other competent authorities under strict conditions.
What is the difference between standard penetration testing and TLPT?
A conventional penetration test may examine specified systems in either production or a test environment. TLPT adds tailored threat intelligence, critical-function scope, controlled live-system testing, supervisory involvement and formal closure/remediation requirements. It cannot be established by relabelling a conventional test.