Preparing a DORA resilience testing programme

A first yearly DORA test cycle with a review date

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 (Article 64; text checked on 2026-09-22). The trigger for preparation is a date: a competent authority requests the testing programme, internal audit schedules its first full-year review, the register of information is due, or a notice arrives that the entity must run threat-led penetration testing (TLPT). For the 2026 register cycle, for example, the Luxembourg Commission de Surveillance du Secteur Financier (CSSF) set a submission window from 11 February to 31 March 2026 for data as at 31 December 2025 (CSSF notice, 11 February 2026).

The owners are the head of information and communication technology (ICT) risk, the CTO, and the QA lead. The entities are payment and e-money institutions, neobanks and other credit institutions, investment firms, and crypto-asset service providers. An ICT third-party service provider is in the same position through its contracts: for services that support critical or important functions, Article 30(3)(c) requires the contract to oblige the provider to implement and test business contingency plans, and Article 30(3)(d) to participate and fully cooperate in the customer's TLPT.

Scope depends on the regime. Article 24 applies to financial entities other than microenterprises, which Article 3(60) defines as having fewer than 10 persons and annual turnover and/or balance sheet total of at most EUR 2 million. Under Article 16(1), Articles 5 to 15 do not apply to small and non-interconnected investment firms, payment institutions exempted under Directive (EU) 2015/2366, credit institutions exempted under Directive 2013/36/EU where the Member State has not applied the Article 2(4) option, electronic money institutions exempted under Directive 2009/110/EC, and small institutions for occupational retirement provision. Those entities instead test, on a regular basis, their continuity plans, response and recovery measures, and control effectiveness (Article 16(1)(g)), and Article 26(1) excludes them from TLPT. The article-by-article testing requirements are on the DORA testing requirements page.

The DORA readiness checklist, in order

1. Confirm the regime. Decide whether the full framework, the Article 16(1) simplified framework, or the microenterprise rules apply, and whether a TLPT notice exists. Output: a scope note that names the regime and the articles in force.
2. Map critical or important functions to systems. List each function with its services, databases, queues, and provider connections. Output: a function-to-system map.
3. Reconcile the register with the map. Compare every provider in the map with its register entry and criticality flag. Output: a register-to-map reconciliation list with each mismatch and its owner.
4. Assess test coverage. Compare existing tests with the continuity, recovery, and yearly testing articles. Output: a gap report before the assessment.
5. Write the yearly test calendar. Name each system, test type, independent tester, environment, and date. Output: a test calendar that feeds the entity's testing programme.
6. Run continuity, recovery, and provider failure tests. Run each scenario with synthetic transactions in flight, and reconcile balances after every restore. Output: failover and recovery time results and third-party provider outage simulations.
7. Run security and performance tests. Test internet-exposed payment, transfer, and onboarding functions, and measure critical functions at peak volume. Output: a penetration test report and a latency and throughput report.
8. Fix, retest, and record. Retest each finding after the fix is deployed. Output: retest evidence per finding.
9. Assemble the evidence. Link each DORA article to its tests, dates, and results. Output: a requirement-to-test traceability matrix.
10. Prepare TLPT inputs, where the entity is identified. Hand the function-to-system map and test history to the control team. Output: an inventory for the scope specification document.

How we help with DORA test readiness

We produce the test records; the entity owns its testing programme, the register, and every submission, and the competent authority reviews them. Our engineers work as an external party, which gives the tester independence described in Article 24(4).

• Operational resilience testing covers steps 6 and 9: Resilience test scenarios for critical services, Failover and recovery time results, Third-party provider outage simulations, and Test evidence mapped to DORA requirements.
• Audit evidence testing covers steps 4, 8, and 9: the Gap report before the assessment, Retest evidence after remediation, the Requirement-to-test traceability matrix, and the Test evidence pack per audit scope.
• Security testing covers step 7 and the retests in step 8: the Web, API, and mobile penetration test report and Findings with severity, reproduction steps, and retest results.
• Performance testing covers the peak-volume part of step 7 with the Latency and throughput report against agreed thresholds.

The scope note, function-to-system map, register-to-map reconciliation list, and test calendar are engagement outputs of steps 1 to 3 and 5, not separate service deliverables. We do not act as the threat intelligence provider or red team tester in a TLPT. An ICT provider that has to answer a bank customer's questionnaire on these tests can follow the bank vendor due diligence sequence.