DORA (Regulation (EU) 2022/2554) became applicable on January 17, 2025. The UK's parallel framework — PRA Supervisory Statement PS6/21 and the Operational Resilience Policy Statement — has been in force since March 2022 with full compliance expected by March 2025. Both frameworks share a core requirement: financial entities must demonstrate that their ICT systems can withstand, respond to, and recover from operational disruptions.
The examination pattern that is emerging in 2025 and 2026: supervisors are asking for evidence of resilience, not documentation of resilience. The distinction is significant. A business continuity plan is documentation. A test result from a failure injection exercise against production-equivalent infrastructure is evidence.
What DORA's ICT Risk Management Framework Actually Requires
Article 6 of DORA requires a comprehensive ICT risk management framework. Article 9 specifies that financial entities must put in place resilient ICT systems and infrastructure — and that resilience must be validated through testing. The RTS on ICT risk management (published by EBA/ESMA/EIOPA in January 2024) specifies that testing must include vulnerability assessments, open-source analyses, network security assessments, and gap analyses.
Articles 24-27 cover DORA's Digital Operational Resilience Testing requirements. For significant firms (those deemed "significant" by their competent authority), Threat-Led Penetration Testing (TLPT) is required at least every three years. TLPT is not a standard penetration test — it requires a scenario-based approach using real threat intelligence and must be conducted by certified testers.
Most UK and EU financial firms have existing BCM and DR documentation that predates DORA. The critical gap: DORA requires that critical functions are identified and that the ICT assets supporting those functions are mapped. If your CMDB doesn't accurately reflect which systems support which business functions, your DORA compliance documentation is built on a false foundation.
The Incident Classification Problem
DORA Article 17 and the RTS on ICT incident classification (published December 2023) define criteria for classifying ICT incidents as "major." The criteria include: number of clients affected, data losses, geographic spread, criticality of the services affected, and economic impact. Organizations must classify incidents against these criteria — and the RTS specifies specific thresholds. An ICT incident that affects more than 10% of clients, or involves a data loss affecting more than 100,000 clients, is major and triggers mandatory reporting to the competent authority within 4 hours of classification.
Most incident management tooling — ServiceNow, PagerDuty, Jira — does not have DORA classification built in. You need a workflow that, at the point of incident creation, captures the data needed to evaluate the DORA classification criteria and escalates appropriately.
The ICT Third-Party Risk Problem
Chapter V of DORA (Articles 28-44) covers ICT third-party risk. Article 28 requires financial entities to maintain a register of all ICT third-party service providers. Article 30 mandates that contracts with ICT third-party providers include specific provisions — security levels, data location, audit rights, termination rights, and sub-outsourcing limitations. The European Supervisory Authorities have published a list of "critical ICT third-party service providers" subject to direct oversight — if your cloud provider or core banking platform is on this list, your contractual obligations are heightened.
- Map critical business functions to supporting ICT assets — this is the foundation of DORA compliance
- Implement DORA-aligned incident classification in your incident management tooling
- Conduct a gap analysis of ICT third-party contracts against Article 30 mandatory provisions
- Build a resilience testing schedule that satisfies Article 24 — not just DR tests, but failure injection
- Establish the reporting workflow for major ICT incidents: 4-hour initial report, 24-hour intermediate, 1-month final
- For significant firms: start the TLPT scoping process — it requires 12+ months of lead time
The Architecture for Continuous Resilience
DORA compliance built on point-in-time testing will fail examination when supervisors ask for evidence of resilience between tests. The architecture for continuous resilience: chaos engineering practices run in production-equivalent environments on a scheduled basis, with results stored as evidence and fed back into the risk management framework. Our self-healing infrastructure practice and compliance infrastructure service are built around this model.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.