For years, disaster recovery in many organizations was a document that lived on a shared drive, updated before audits and tested, if at all, with a weekend failover of a few servers. The EU’s Digital Operational Resilience Act (DORA) has ended that era for financial services, and its influence is spreading well beyond banks and insurers. DORA treats the ability to withstand, respond to and recover from ICT disruption as a core regulatory obligation, with management bodies personally accountable for it.
At the same time, more critical workloads than ever run on a small number of hyperscale cloud providers. In November 2025, European regulators designated the first list of critical ICT third-party providers subject to direct oversight. That combination, strict resilience requirements and concentrated cloud dependency, makes cloud backup and disaster recovery one of the most consequential infrastructure topics of 2026. This playbook explains what DORA expects, how it changes cloud DR design and how to build a program that will stand up to supervisors and to real incidents.
DORA in Brief: Where Things Stand in 2026
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 to a wide range of EU financial entities, including banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and many others. It is organized around five pillars:
- ICT risk management, including requirements for backup policies, restoration and recovery procedures, and business continuity and response and recovery plans.
- ICT-related incident management and reporting, with classification criteria and tight notification timelines for major incidents.
- Digital operational resilience testing, ranging from vulnerability assessments and scenario-based tests to threat-led penetration testing for the most significant entities.
- ICT third-party risk management, including contract requirements, exit strategies and a register of information on all ICT service arrangements.
- Information sharing on cyber threats among financial entities.
The registers of information that financial entities submitted to their supervisors in 2025 have already had a visible effect. According to the joint press release from the European Supervisory Authorities (EBA, EIOPA and ESMA), those registers fed a criticality assessment that led to the designation of critical ICT third-party providers (CTPPs) on 18 November 2025. Morgan Lewis reports that 19 providers were designated, spanning hyperscale cloud, data center, infrastructure and network services, and financial-sector technology.
What CTPP Oversight Means for Your DR Strategy
It is tempting to read CTPP designation as reassurance: if regulators are directly overseeing your cloud provider, surely the resilience problem is solved. That reading is wrong. Under DORA, financial entities remain fully responsible for managing their own ICT risk, including risks arising from third parties. Oversight of the provider complements, but does not replace, your own controls.
According to Morgan Lewis’s analysis, the ESAs can assess CTPPs’ risk management, governance, incident reporting, subcontracting and ICT security, issue recommendations, publicize non-compliance and, as a last resort, require financial entities to suspend or terminate the use of a provider’s services. That last-resort power is precisely why exit strategies and portable recovery capabilities matter: a scenario in which you must move off a provider is no longer purely hypothetical.
DORA does not ask whether your cloud provider is resilient. It asks whether you can prove that your critical functions will keep running, or recover within tolerance, whatever happens to any single provider, region or system.
How DORA Changes Cloud Backup and DR Design
Translating regulatory text into architecture requires interpretation, and organizations should always confirm specifics with their compliance and legal teams. In practice, though, several design implications appear consistently.
From System Recovery to Function Recovery
DORA centers on critical or important functions, not individual servers. DR planning must therefore start by mapping each critical business function, such as payments processing, trading, claims handling or customer onboarding, to the applications, data, third parties and infrastructure it depends on. Recovery objectives are then set at the function level and decomposed into technical objectives for each component.
Backups That Are Segregated and Restorable
DORA requires documented backup policies and restoration procedures, and expects backups to be restorable without jeopardizing the security of systems or data. A widely accepted reading is that backup copies should be segregated from the source systems, physically and logically, so that a compromise or failure of production does not also compromise recovery. In cloud terms, this points toward separate accounts or subscriptions, immutable vaults, isolated recovery environments and independent key management, the same patterns that defend against ransomware.
Testing That Produces Evidence
Resilience testing under DORA is expected to be regular, risk-based and documented. For DR, that means restore tests and failover exercises with defined scenarios, measured results compared against objectives, identified gaps and tracked remediation. A test that is not recorded, or whose findings are not acted upon, provides little value to a supervisor.
Exit Strategies That Are Executable
For ICT services supporting critical or important functions, DORA requires exit strategies. A credible exit plan for a cloud workload covers how data would be extracted in usable formats, where the workload would run instead, how long a transition would take, and how service would be maintained in the meantime. Backups held in portable formats, infrastructure defined as code and avoidance of unnecessary proprietary dependencies all make exit plans more realistic.
Choosing a Cloud Resilience Pattern
There is no single correct DR architecture. The right pattern depends on each function’s impact tolerance, cost constraints and concentration risk. The main options are:
- Backup and restore within one provider, cross-region. The lowest cost option, with recovery times measured in hours. Suitable for important but not time-critical functions, provided backups are isolated and immutable.
- Pilot light or warm standby in a second region. Core data is replicated continuously and minimal infrastructure is running, allowing recovery in minutes to an hour. A common choice for critical customer-facing services.
- Active-active across regions. The highest availability within a provider, but also the highest complexity, especially for stateful systems requiring strong consistency.
- Cross-provider recovery. Backups or a reduced-capability standby with a second cloud provider or on separate infrastructure. This directly addresses concentration and exit risk but requires portable architecture and regular testing to be credible.
- Hybrid or sovereign options. Some entities keep a recovery capability on private infrastructure or with a sovereign cloud offering to satisfy data residency or concentration concerns.
Many organizations combine these: warm standby across regions for operational resilience, plus immutable, portable backups with a second provider as the “last line” that supports both ransomware recovery and exit planning.
A Step-by-Step DORA-Aligned DR Playbook
Step 1: Map Critical Functions and Dependencies
Work with business owners to identify critical or important functions and trace each one to its applications, data stores, integrations, identity services, networks and third-party providers. Reconcile this map with your register of information so that both tell the same story; supervisors will notice inconsistencies.
Step 2: Set Impact Tolerances and Recovery Objectives
Define how long each function can be disrupted and how much data loss is acceptable before customers, markets or the institution suffer intolerable harm. Translate those tolerances into recovery time and recovery point objectives for each technical component, remembering that a function recovers only when its slowest critical dependency does.
Step 3: Assess the Current Recovery Capability
For each function, compare actual capability with the objectives. Look honestly at backup coverage, isolation, restore speed, documentation, staff knowledge and dependencies on single regions, services or providers. Rank gaps by the criticality of the function and the size of the shortfall.
Step 4: Design and Implement Target Patterns
Select a resilience pattern per function and implement it with infrastructure as code, so that recovery environments can be rebuilt consistently. Include isolated, immutable backups for every critical data store, independent identity and key management for recovery, and automated runbooks where possible.
Step 5: Test, Measure and Remediate
Build a multi-year test plan covering component restores, full function failovers, ransomware scenarios, regional outages and provider-level disruption. Record scenario, scope, participants, measured recovery times, data loss, issues and remediation owners. Feed results into risk reporting to the management body.
Step 6: Align Incident Response and Reporting
DR is closely linked to incident management. DORA’s incident reporting framework requires rapid notification of major ICT-related incidents to the competent authority, followed by intermediate and final reports. Make sure your DR runbooks include decision points for incident classification and that the people executing a failover know who must be informed and when.
Step 7: Maintain Exit Readiness
For each critical cloud dependency, document an exit strategy and test its key assumptions periodically, for example by restoring a representative data set and workload in the alternative environment. Review contracts to confirm that data access, transition assistance and termination rights support the plan.
Worked Example: A Payments Platform on a Single Hyperscaler
Consider a mid-sized payment institution running its card processing platform on one hyperscale provider in a single EU region. Its DR plan relied on nightly database backups stored in the same account and a documented, but never executed, procedure for rebuilding in a second region.
Mapping critical functions showed that card authorization depended not only on the core database but also on a managed message queue, a third-party fraud scoring API and the identity provider used by operations staff. Impact tolerance for authorization was set in minutes, far below what the backup-and-rebuild approach could deliver.
The institution implemented a warm standby in a second region of the same provider, with continuous database replication and infrastructure defined as code. It moved backups to a separate account with locked immutability and added a weekly copy, in an open format, to a second provider, supporting both ransomware recovery and its exit strategy. It agreed a fallback mode with the fraud scoring vendor and created break-glass access independent of the primary identity provider.
The first full failover test exceeded the recovery objective because DNS changes and manual approvals took longer than expected. The team automated those steps and repeated the test, meeting the objective. The test reports, remediation records and updated register entries formed the evidence pack for the next supervisory review.
Evidence Checklist for Supervisors and Auditors
Resilience that cannot be demonstrated is, from a supervisory perspective, resilience that does not exist. Before your next review, confirm that you can produce the following for each critical or important function:
- A current dependency map linking the function to applications, data stores, infrastructure, identity services and third-party providers, consistent with the register of information.
- Approved impact tolerances and the recovery time and recovery point objectives derived from them for every critical component.
- Backup policies showing scope, frequency, retention, segregation and immutability settings, with configuration exported from the cloud platform rather than described from memory.
- Records of restore and failover tests from the past year, including scenarios, measured results, deviations from objectives and the status of remediation actions.
- A documented exit strategy for each critical cloud or SaaS dependency, with the date and outcome of the most recent test of its key assumptions.
- Evidence that the management body has received and discussed resilience reporting, including open risks and investment decisions.
Automating the collection of this evidence, for example by exporting backup policy configuration and test results to a central repository on a schedule, saves considerable effort and keeps documentation aligned with reality as environments change.
Common Pitfalls
- Treating CTPP oversight as outsourced compliance. Provider oversight does not transfer your accountability for resilience.
- Equating high availability with recovery. Multi-zone deployments protect against hardware and data center failures but replicate corruption and malicious changes instantly. Point-in-time, isolated backups are still essential.
- Testing only the easy parts. Restoring a single database is useful; recovering a complete critical function, including identity, networking and third parties, is what demonstrates resilience.
- Paper exit plans. An exit strategy that has never been partially tested is unlikely to convince a supervisor, or to work.
- Inconsistent records. Registers of information, DR plans and test reports that disagree undermine confidence in the entire program.
Outlook: Resilience as a Continuous Discipline
The ESAs have said they will continue to engage with designated CTPPs through examination activities, and supervisors are increasingly focusing on how financial entities test and evidence their resilience. Outside financial services, the EU’s NIS2 Directive and sector regulations elsewhere are pushing in a similar direction. Cloud providers are responding with stronger isolation, recovery testing and sovereignty options. Over the next few years, expect operational resilience to look less like an annual compliance exercise and more like site reliability engineering: continuous, measured, automated and owned jointly by business and technology leaders.
Conclusion
DORA has turned cloud disaster recovery from a technical best practice into a regulatory obligation focused on outcomes. The designation of critical ICT third-party providers underlines that concentration risk is real, but it does not remove the responsibility of each financial entity to recover its own critical functions. Start from functions and impact tolerances, build segregated and immutable backups, choose resilience patterns that match each function’s needs, test end to end and keep exit strategies executable. Organizations that do this will satisfy supervisors and, more importantly, will be able to keep serving customers when something goes wrong.
How Hanoi Technology Can Help
Hanoi Technology helps financial and regulated organizations design, automate and test DORA-aligned cloud backup and disaster recovery.
Further Reading
- European Supervisory Authorities Designate Critical ICT Third-Party Providers Under DORA – European Banking Authority
- DORA: EU Regulators Announce List of Critical ICT Third-Party Providers – Morgan Lewis
- AWS Backup 2025 Year in Review: Advancing Recovery Resilience – AWS Storage Blog
- Enable Soft Delete and Immutable Vaults – Microsoft Learn