Executive introduction
DORA changed the regulatory architecture for digital operational resilience in European finance, but regulatory implementation should not be confused with resilience itself. The regulation has applied since 17 January 2025 and creates a harmonised framework for ICT risk management, incident reporting, resilience testing, information sharing and third-party ICT risk.
The management challenge in 2026 is to demonstrate that the structures created for DORA improve the institution's ability to continue critical services during disruption. That requires a shift from document-centric compliance toward service mapping, dependency analysis, recovery capability, tested alternatives and decision-useful management information.
Key takeaways
- Operational resilience should begin with critical services, not with isolated risk events.
- DORA registers become more valuable when connected to service and dependency mapping.
- Third-party exit plans need to be operationally executable, not merely contractually possible.
- Compound scenario testing is more informative than testing one technology failure at a time.
- Boards need concise evidence on service vulnerabilities, recovery performance and unresolved concentrations.
From operational risk to service resilience
Traditional operational-risk frameworks often start with the question: what can go wrong? Resilience frameworks should first ask: which services must continue even when something goes wrong? That changes the sequence from event-loss analysis to critical service, dependency, disruption scenario, tolerance and recovery capability.
The objective is not to eliminate incidents. It is to prevent incidents from becoming unacceptable service failures. This means risk appetite needs operational measures such as recovery time, dependency concentration, manual fallback capacity and restoration success, in addition to historical loss data.
Dependency mapping
For each critical or important service, banks should map applications, infrastructure, data, people, locations, vendors, subcontractors, identity services, cloud regions and manual alternatives. The purpose is not inventory for its own sake; it is to identify common-cause failure paths.
Apparent vendor diversification can conceal infrastructure concentration. Several applications supplied by different firms may depend on the same cloud region, identity layer or network. Resilience analysis therefore has to look through contractual counterparties to the underlying technical architecture.
Third-party resilience and exit
Outsourcing a process does not outsource accountability. A credible third-party framework should assess criticality, substitutability, data access, subcontracting chains, recovery arrangements, service-level dependencies and exit feasibility.
A contractual termination right is not an operational exit plan. Banks should estimate migration time, data portability, alternative-provider capacity, parallel-running requirements, specialist skills, regulatory constraints and interim operating arrangements.
Testing severe but plausible disruption
Useful scenarios combine failures: a cloud outage during peak payments, a cyberattack alongside impaired communications, data corruption discovered during restoration, or a supplier incident coinciding with geopolitical disruption. Tests should assess both technical recovery and management decision-making under uncertainty.
The strongest evidence is not that a test completed on time; it is that the test revealed where dependencies, communications, manual alternatives or escalation procedures would fail and that remediation was subsequently verified.
Technical framework
A resilience dashboard can track recovery time against tolerance, percentage of critical dependencies without tested alternatives, unresolved severe vulnerabilities, third-party concentration, restoration success rates, incident-detection latency and the age of critical remediation findings. These are forward-looking capability measures rather than purely historical loss indicators.
Practical example
A payment service may use several applications from different vendors, yet all depend on the same cloud identity service. A vendor-count metric would suggest diversification. A dependency graph would identify one common node whose outage can stop the entire service. The remediation may be architectural rather than contractual.
What risk leaders should do now
- Connect DORA registers to end-to-end service maps.
- Assign explicit business ownership for critical services and resilience tolerances.
- Test compound disruptions and management decision-making, not only system failover.
- Challenge third-party exit plans for realistic time, capacity and data portability.
- Converge ICT-risk and operational-risk reporting where they describe the same vulnerability.
- Prioritise remediation by potential service impact rather than finding count alone.
Frequently asked questions
Is DORA compliance the same as operational resilience?
No. Compliance establishes minimum governance and control requirements. Resilience is demonstrated by the ability to continue or recover critical services during severe disruption.
Why are dependency maps important?
They reveal common infrastructure, data and provider dependencies that ordinary supplier inventories can miss.
What makes an exit plan credible?
It needs executable alternatives, realistic migration time, data portability, available capacity and tested decision rights.
Conclusion
DORA provides the regulatory foundation, but resilience is ultimately an operating capability. Banks need to know which services matter, what they depend on, how quickly disruption becomes unacceptable and which actions can restore service.
The strongest frameworks integrate ICT controls, third-party management, business continuity, incident management, cyber defence and operational risk into one service-based resilience architecture.