DORA testing requirements
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of EU financial entities, including banks, payment and e-money institutions, investment firms, and crypto-asset service providers. DORA testing verifies failover, backup restoration, third-party outage handling, and security controls for critical or important functions. FintechAssuranceLabs produces resilience test scenarios, recovery time results, and DORA-mapped test evidence.
- Jurisdiction
- EU (directly applicable in all Member States)
- Primary source
- eur-lex.europa.eu
Engineering interpretation of testing requirements, not compliance advice.
What DORA and its technical standards require
Regulation (EU) 2022/2554, the Digital Operational Resilience Act, was published in the Official Journal on 27 December 2022 and applies from 17 January 2025 (Article 64). Under the DORA text on EUR-Lex (checked on 2026-09-16), DORA applies to the 20 types of financial entities in Article 2(1), points (a) to (t), and to ICT third-party service providers. Two delegated regulations set the detail for testing: Delegated Regulation (EU) 2024/1774 on ICT risk management (published 25 June 2024) and Delegated Regulation (EU) 2025/1190 on threat-led penetration testing (published 18 June 2025). Articles 24 and 26 exclude microenterprises, which Article 3 defines as entities with fewer than 10 persons and at most EUR 2 million in turnover or balance sheet total.
- ICT risk management, Articles 8 to 10. ICT-supported business functions and their assets are identified and classified (8(1)). Every change to ICT systems is recorded, tested, assessed, approved, implemented, and verified (9(4)(e)). Detection mechanisms for anomalous activity are tested regularly under Article 25 (10(1)).
- Continuity and recovery, Articles 11 and 12. Business continuity plans and response and recovery plans are tested at least yearly and after substantive changes to systems that support critical or important functions (11(6)). For entities other than microenterprises, the test plans include cyber-attack scenarios and switchovers to redundant capacity, backups, and redundant facilities. Backup restoration is tested periodically (12(2)) on systems segregated from the source (12(3)). Recovery time and recovery point objectives are set per function (12(6)). After recovery, the entity runs checks and reconciliations for data integrity, including data rebuilt from external stakeholders (12(7)).
- Testing programme, Articles 24 and 25. The entity keeps a digital operational resilience testing programme (24(1)). Independent parties, internal or external, run the tests (24(4)). Issues are prioritised, remedied, and validated as fixed (24(5)). All ICT systems and applications that support critical or important functions get appropriate tests at least yearly (24(6)). Article 25(1) lists the test types, from vulnerability scans and source code reviews to scenario-based, performance, end-to-end, and penetration testing.
- TLPT, Articles 26 and 27. Entities that the competent authority identifies run TLPT at least every 3 years on live production systems (26(1), 26(2)). Delegated Regulation 2025/1190 Article 2(2) names, among others, payment institutions above EUR 150 billion in total value of payment transactions in each of the two preceding calendar years, and e-money institutions above that value or above EUR 40 billion of outstanding e-money.
- ICT third-party risk, Article 28. The entity keeps a register of information on ICT service contracts (28(3)) and exit strategies for services that support critical or important functions (28(8)).
Delegated Regulation 2024/1774 adds testable rules. ICT systems are tested before first use and after maintenance (Article 16(2)). Non-production environments hold only anonymised, pseudonymised, or randomised production data, except approved and time-limited cases (Article 16(5) and (6)). Continuity tests use severe but plausible scenarios, including failure of an ICT third-party service provider (Article 25(2)).
DORA requirements that testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| Article 11(6) Switchover to redundant capacity is tested | Payment and ledger services move to the secondary site while test transactions are in flight. | Switchover test log with timestamps and the final state of each test transaction |
| Article 12(6) Recovery objectives are set per function | Recovery time and data loss for each critical or important function, measured against its objectives. | Failover and recovery time results per function |
| Article 12(2) and 12(3) Backup restoration is tested on segregated systems | A ledger backup restores into a segregated environment, and record counts and balances match the backup point. | Restore test record with backup time, restore duration, and consistency checks |
| Article 12(7) Data is reconciled after recovery | Ledger balances after recovery match processor and bank settlement files for the same period. | Reconciliation report with each break and its cause |
| Delegated Regulation 2024/1774 Article 25(2) Provider failure scenarios are tested | Processor, cloud, and identity verification providers return outages, timeouts, and slow responses. | Third-party provider outage simulation results with the customer-facing state per scenario |
| Article 25(1) Performance testing | Critical functions hold throughput and latency at peak volume, on primary and redundant capacity. | Latency and throughput report against agreed thresholds |
| Article 10(1) Detection mechanisms are tested | Injected events, such as a missing settlement file or an error-rate spike, raise the alert at the defined threshold. | Event-to-alert trace per injected event |
| Article 9(4)(e) Changes are tested, with fall-back procedures under Delegated Regulation 2024/1774 Article 17(1)(e) | A release that changes a payment or ledger schema rolls back without data loss. | Rollback test result per release |
| Delegated Regulation 2024/1774 Article 16(3) Internet-exposed systems get security testing | Web, API, and mobile attack paths against payment, transfer, and account access functions. | Penetration test report with findings and severity |
| Article 24(5) Fixes are validated | Each finding after the development team deploys a fix. | Retest result linked to the original finding |
Artifacts a supervisor or auditor requests
A competent authority, internal audit, or a partner bank typically requests:
- the classification of ICT-supported business functions and the asset inventory, with critical or important functions marked (8(1), 8(4), 8(6));
- the digital operational resilience testing programme and the yearly test plan per system that supports a critical or important function (24(1), 24(6));
- records that show each tester is an independent party with no conflict of interest in test design and execution (24(4));
- the issue register with priority, remediation, and validation records (24(5));
- continuity and recovery test results, including switchover and cyber-attack scenarios, and the report of deficiencies to the management body (11(6); Delegated Regulation 2024/1774 Article 25(5));
- recovery objectives per function with measured results, and backup restoration test records (12(2), 12(6));
- the register of information and the exit strategy for each provider of a critical or important function (28(3), 28(8));
- for an entity in TLPT scope: the scope specification document within 6 months of the authority's notification, the red team test report, and the remediation plan with a root cause analysis per finding (Delegated Regulation 2025/1190 Articles 9(6), 12(2), 13(2)).
Common DORA testing findings
- Failover tested on an idle system. The switch to the secondary region runs with no transactions in flight. Duplicate payouts and lost card authorisations after the switch stay undetected. The gap breaks 11(6) and Delegated Regulation 2024/1774 Article 25(2)(c).
- Recovery time measured for infrastructure only. The database meets its recovery target, but the transfer API rejects requests until queues drain, and nobody measures the function. The gap breaks 12(6), which sets objectives per function.
- No reconciliation after restore. A ledger restores from a backup taken before the last settlement run. Transactions the processor confirmed after that point are missing, and customer balances are wrong. The gap breaks 12(7).
- Provider timeout treated as success. An identity verification provider times out, and onboarding marks the check as passed. The gap breaks Delegated Regulation 2024/1774 Article 25(2)(b).
- Production data in a load test environment. A performance test runs on an unmasked copy of production with no approval or time limit on record. The defect breaks Delegated Regulation 2024/1774 Article 16(5) and (6).
- Alert rule never triggered. The monitoring rule for a missing settlement file exists, but no test ever fires it, and a wrong file path keeps it silent. The gap breaks 10(1).
- Yearly test plan with missing systems. The plan covers the core ledger but omits the card processor adapter and the mobile API gateway that support the same critical function. The gap breaks 24(6).
How we cover DORA testing
The operational resilience testing service covers Articles 11 and 12 and the continuity test rules of Delegated Regulation 2024/1774 Article 25. It delivers "Resilience test scenarios for critical services", "Failover and recovery time results", "Third-party provider outage simulations", and "Test evidence mapped to DORA requirements". The ledger reconciliation testing guide shows the checks behind Article 12(7).
Performance testing covers the performance tests in Article 25(1) and delivers a "Latency and throughput report against agreed thresholds". Security testing covers penetration testing under Delegated Regulation 2024/1774 Article 16(3) and delivers "Findings with severity, reproduction steps, and retest results" for Article 24(5). Our engineers work as an external party, which gives the tester independence that Article 24(4) describes.
Audit evidence testing builds a "Requirement-to-test traceability matrix" from DORA articles to test results and a "Gap report before the assessment". The DORA resilience testing readiness scenario sets out the sequence and timeline for a first yearly test cycle.
We test DORA requirements for neobanks, payment acquirers, BaaS platforms, remittance, trading, crypto exchange, and open banking products. In these products, an untested switchover or restore can leave duplicate payouts or wrong balances that only the Article 12(7) reconciliation finds.
We do not act as the threat intelligence provider or the red team tester in a TLPT under Article 27 and Delegated Regulation 2025/1190. For an entity in TLPT scope, we run the Article 25 tests between TLPT cycles and retest remediation plan items after fixes.
Related
Services
Segments
- Neobanks and digital banking
- Payment acquiring
- Banking-as-a-Service and card issuing
- Business banking
- International transfers
- Investing and trading apps
- Crypto exchanges and wallets
- Open banking and data aggregation
- AP/AR automation and treasury
- Insurtech
- KYC/AML and anti-fraud
- Spend management and corporate cards
- Robo-advisors and wealthtech
Adjacent standards
Questions
What is DORA?
Who needs to comply with DORA?
What is TLPT?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing