Why DORA Requires Resilience Testing
Digital operational resilience testing is the fourth pillar of DORA. Articles 24 through 27 establish a structured approach to verifying that financial entities can withstand, respond to, and recover from ICT-related disruptions. The regulation treats testing not as an occasional audit exercise but as a continuous programme embedded in the entity's ICT risk management framework.
The logic behind Art. 24 is straightforward: a risk management framework that has never been tested against realistic scenarios provides only theoretical assurance. DORA requires entities to validate their defences through practical, repeatable testing activities that cover the full range of ICT systems supporting critical or important functions.
Testing results must feed back into the ICT risk management framework. If a vulnerability assessment reveals an unpatched exposure or a scenario test shows a recovery process that exceeds the defined RTO, those findings must drive remediation actions. This feedback loop between testing and risk management is a core requirement under Art. 24(5) and is one of the areas supervisors are expected to examine during on-site inspections.
DORA distinguishes between two tiers of testing. All in-scope entities must perform basic testing under Art. 25. A subset of larger or systemically important entities must additionally perform advanced Threat-Led Penetration Testing (TLPT) under Art. 26 and 27. The proportionality principle at Art. 4 applies throughout, meaning the scope and depth of your testing programme should reflect your size, risk profile, and the criticality of your ICT services.
Basic Testing Programme
Art. 25 sets the baseline. Every financial entity within DORA's scope must establish and maintain a testing programme that covers all critical ICT systems and applications. The programme must be proportionate to the entity's size and business model, but the minimum expectation is clear: annual testing of critical systems using a defined set of methods.
The regulation and RTS 2024/1774 enumerate the following types of testing that should form part of the basic programme:
1 Vulnerability Assessments
Systematic scanning of ICT systems to identify known vulnerabilities, misconfigured services, and outdated components. Vulnerability assessments should cover both external-facing systems and internal infrastructure supporting critical functions. Results must be classified by severity and tracked through to remediation.
2 Network Security Reviews
Assessment of network architecture, segmentation, firewall rules, and access controls. These reviews verify that the network design limits the blast radius of a potential compromise and that communication between segments is restricted to what is operationally necessary. Art. 9 protection measures are validated here.
3 Gap Analysis
A structured comparison of the entity's current ICT risk posture against DORA requirements and the applicable RTS/ITS. Gap analysis identifies areas where policies, controls, or processes do not yet meet the regulatory standard. DORA GRC provides a free gap analysis tool that covers all five pillars in 25 questions.
4 Source Code Reviews
Where feasible and risk-appropriate, review of application source code to identify security flaws, insecure coding patterns, and logic vulnerabilities. This applies particularly to in-house developed systems that support critical or important functions. Automated static analysis tools can supplement manual reviews.
5 Scenario-Based Testing
Simulation exercises that test the entity's response to specific ICT disruption scenarios, such as a ransomware attack, the loss of a critical third-party provider, or a data centre failure. Scenarios should be derived from the entity's risk register and threat landscape analysis. Results validate business continuity and disaster recovery plans required under Art. 11.
6 Performance Testing
Load testing, stress testing, and capacity testing of critical ICT systems to verify they can handle expected peak volumes and degrade gracefully under abnormal conditions. Performance testing is particularly important for systems that support real-time transaction processing or market-facing services.
Advanced TLPT Requirements
Threat-Led Penetration Testing goes beyond standard security testing. TLPT simulates real-world attack techniques against live production systems, using current threat intelligence about the specific entity and its sector. The methodology is defined in RTS 2025/1190 and aligns with the TIBER-EU framework that several EU member states already operate.
TLPT is not optional for designated entities. NCAs identify which entities must perform TLPT based on criteria at Art. 26(8), including the entity's systemic importance, its ICT risk profile, and the nature of the critical functions it performs. Once designated, the entity must carry out TLPT at least every three years.
| Aspect | Basic Testing (Art. 25) | TLPT (Art. 26–27) |
|---|---|---|
| Who must do it | All in-scope financial entities | Entities designated by NCA based on systemic importance |
| Frequency | At least annually | At least every 3 years |
| Scope | All critical ICT systems | Critical functions and live production systems |
| Methodology | Standard security testing methods | Intelligence-led, simulating real threat actors (RTS 2025/1190) |
| Testers | Internal or external | Qualified external testers required; internal participation limited |
| NCA coordination | Not required | Mandatory: NCA must be notified before testing begins |
| Third-party involvement | Not required | Critical ICT providers must participate in scope |
Art. 27 adds specific requirements for the TLPT testers themselves. They must be certified or accredited, carry professional indemnity insurance, and have no conflicts of interest with the entity being tested. Where possible, entities should rotate testers between TLPT cycles. The NCA may accept the use of internal testers for certain phases, but at least one external tester must be involved in every TLPT exercise.
Critical ICT third-party providers that support functions in scope for TLPT must participate in the testing. Art. 26(3) requires that the TLPT scope include the ICT services provided by these third parties. Where a provider refuses to participate, the entity must document this and notify the NCA, which may consider it a supervisory concern under the provider oversight framework.
Testing Programme Governance
DORA does not treat testing as a standalone activity. Art. 25 requires the testing programme to be integrated into the ICT risk management framework and subject to governance oversight. The management body must approve the testing programme and receive reporting on its results and any identified gaps.
Key governance requirements for the testing programme include:
The programme must be documented and define the scope of testing, the methods used, the frequency for each system, and the criteria for determining when a test passes or fails. It must also define how findings are prioritised, assigned, and tracked through remediation.
Testing results must be reported to the management body and used to update the ICT risk register. Under Art. 24(5), any vulnerabilities, weaknesses, or gaps identified during testing must be addressed promptly and in full. The remediation actions must be documented and verified through retesting where appropriate.
The testing programme must be reviewed and updated at least annually to reflect changes in the entity's ICT landscape, threat environment, and business operations. New systems, new providers, and material changes to existing infrastructure should trigger a reassessment of the testing scope.
For entities subject to TLPT, additional governance applies. The NCA must be notified before TLPT begins, and the results and remediation plan must be shared with the NCA upon completion. The entity's management body must formally acknowledge the TLPT findings and approve the remediation plan.
What Applies to Smaller Entities
Art. 4 of DORA introduces a proportionality principle that runs through all five pillars. For resilience testing, this means that smaller and less complex entities are not expected to operate the same testing programme as a systemically important bank.
Entities that qualify as microenterprises under the EU definition (fewer than 10 employees and annual turnover below EUR 2 million) benefit from a simplified ICT risk management framework under Art. 16. This extends to testing: while they must still assess their ICT risks and maintain basic security measures, the formal testing requirements are scaled down.
Smaller entities that are uncertain about what level of testing applies should consult their NCA. Several NCAs have published guidance documents that provide more detail on how proportionality applies in their jurisdiction. DORA GRC's compliance guide provides an overview of proportionality across all five pillars.
Building Your Testing Programme Step by Step
Whether you are starting from scratch or formalising existing practices, the following steps provide a practical path to a DORA-compliant testing programme.
Identify Critical ICT Systems
Start from your ICT asset register (Art. 8) and CIF register. Identify which systems support critical or important functions, map their dependencies, and classify them by risk level. These systems form the core scope of your testing programme. DORA GRC's asset register and dependency mapping automate this identification.
Define Testing Methods and Frequency
For each system in scope, determine which testing methods are appropriate and how often they should be performed. Critical systems with high-risk ratings should receive more frequent and more rigorous testing. Document the rationale for each decision so it can be demonstrated to supervisors.
Assess TLPT Applicability
Determine whether your entity is likely to be designated for TLPT by reviewing the Art. 26(8) criteria with your NCA. If TLPT applies, begin planning for the scope, tester selection, and NCA coordination at least 12 months before the expected testing window. Budget for external testers and the internal resources needed to support the exercise.
Establish Governance and Reporting
Create a testing programme charter that defines roles, responsibilities, escalation paths, and reporting lines. The management body should approve the programme and receive a summary of results at least annually. Integrate testing findings into the ICT risk management framework and the remediation tracking process.
Execute, Record, and Remediate
Run the tests according to the defined schedule. Record results systematically, including pass/fail outcomes, identified vulnerabilities, severity ratings, and assigned remediation owners. Track each finding to closure and verify through retesting. DORA GRC's testing module manages this entire lifecycle, linking results to risks, assets, and controls.
Review and Improve Annually
At least once a year, review the testing programme against the current threat landscape, any changes in the ICT estate, and lessons learned from previous test cycles. Update the scope, methods, and frequency as needed. Document the review and present the conclusions to the management body for approval.
Frequently Asked Questions
DORA requires all in-scope financial entities to operate a digital operational resilience testing programme under Art. 24. At minimum this includes vulnerability assessments, network security reviews, gap analysis, software source code reviews where feasible, scenario-based testing, and performance testing. These basic tests must be conducted at least annually on critical ICT systems. Larger entities designated by their NCA must also perform Threat-Led Penetration Testing (TLPT) at least every three years.
TLPT is required for financial entities that are systemically significant or have a high ICT risk profile. National competent authorities designate which entities must perform TLPT based on criteria at Art. 26(8), including systemic importance, ICT maturity, and the nature and criticality of their functions. Smaller and less complex entities are typically exempt. If you are uncertain whether TLPT applies to you, contact your NCA for confirmation.
Basic resilience testing under Art. 25 must be performed at least once a year on all critical ICT systems and applications. TLPT under Art. 26 must be carried out at least every three years for designated entities. The testing programme should be risk-based, meaning higher-risk systems may need more frequent testing than the regulatory minimum. Material changes to critical systems should also trigger additional testing outside the normal cycle.
Basic testing (Art. 25) covers standard security assessments such as vulnerability scanning, network security reviews, and scenario-based testing. It applies to all in-scope entities and can be performed by internal or external testers. TLPT (Art. 26–27) is an advanced, intelligence-led testing methodology that simulates real-world attacks on live production systems using current threat intelligence. TLPT must involve qualified external testers and requires coordination with the entity's NCA before, during, and after the exercise. Only entities designated by their NCA must perform TLPT.