Disaster Recovery Planning: A Complete Guide

DORA dedicates specific attention to ICT response and recovery in Articles 11 and 12, establishing requirements that go beyond general DR best practice. Article 11 requires financial entities to put in place a comprehensive ICT business continuity policy, which must define arrangements, plans, procedures, and mechanisms to ensure the continuity of the entity's critical or important functions, respond quickly and effectively to all ICT-related incidents to minimise damage and resume operations, and activate dedicated plans that contain measures, actions, and procedures to be activated for each type of ICT-related incident. Article 11(3) requires that the policy be implemented through dedicated, appropriate, and documented arrangements, plans, procedures, and mechanisms.

Article 11(4) introduces specific requirements for ICT business continuity plans: financial entities must test the plans at least annually and after substantive changes to the ICT systems, ensure that testing covers an adequate range of scenarios (including scenarios with severe business disruptions), and ensure that backup systems can be switched to from the primary systems in a timely manner. The testing obligation is not discretionary — it is a regulatory requirement with supervisory oversight. Article 11(6) further requires financial entities to maintain records of all testing activities and their results, and to address any deficiencies identified during testing through a formal remediation process.

Article 12 addresses backup policies and recovery methods specifically. Financial entities must define and implement backup policies specifying the scope of data subject to backup, the frequency of backup, and the recovery procedures. Article 12(2) requires that when restoring data from backups, financial entities use ICT systems that are physically and logically segregated from the source system, and that restoration does not jeopardise the security of network and information systems or the availability, authenticity, integrity, and confidentiality of data. Article 12(3) mandates that financial entities periodically test the backup procedures and the restoration and recovery procedures to verify that recovery can be achieved within the defined RTO and RPO. The RTS under DORA provide additional technical detail on backup requirements, including expectations for backup encryption, geographically separated storage, and backup integrity verification.

For financial entities subject to DORA, disaster recovery planning is not a technology decision delegated to IT — it is a governance obligation under Article 5, requiring management body approval of ICT business continuity policies and oversight of their implementation and testing. The management body must be informed of test results, aware of any gaps or deficiencies, and satisfied that remediation is progressing appropriately.

The choice of disaster recovery site strategy has fundamental implications for recovery capability, cost, regulatory compliance, and data sovereignty. Traditional DR site strategies are categorised by readiness level: cold sites (space and power available but no pre-installed systems — recovery time measured in days to weeks), warm sites (pre-installed but not current systems — recovery time measured in hours to days), and hot sites (fully replicated and current systems ready for failover — recovery time measured in minutes to hours). The appropriate strategy for each system depends on its RTO: systems with RTOs of minutes require hot sites, systems with RTOs of hours can use warm sites, and systems with RTOs of days may use cold sites.

For EU organisations, DR site strategy must incorporate data sovereignty considerations. NIS2 applies to entities providing services within the EU, and Member State transposition laws may impose data localisation requirements for certain data categories. DORA Article 28(1)(a) requires financial entities to ensure that ICT third-party service providers comply with appropriate information security standards, which includes data processing location. The GDPR constrains personal data transfers outside the EU/EEA unless adequate safeguards exist. These regulatory requirements collectively mean that DR sites must be located within the EU/EEA for many data categories, and the DR site operator must comply with applicable EU regulations.

Cloud-based DR strategies (disaster recovery as a service, or DRaaS) have become the dominant approach for organisations seeking hot or warm site capabilities without the capital investment of physical infrastructure. However, EU organisations must select cloud providers that offer EU-based regions with contractual commitments to data residency, comply with the EU Cloud Code of Conduct or equivalent standards, provide transparency regarding sub-processors and data access jurisdictions, and support the technical controls required by DORA (encryption, access control, audit logging, segregation). Organisations with strict sovereignty requirements — particularly those in the defence, intelligence, or critical national infrastructure sectors — may require sovereign cloud providers that are EU-owned, EU-operated, and subject exclusively to EU jurisdiction. The Gaia-X initiative and national sovereign cloud programmes provide frameworks for assessing provider sovereignty.

Multi-region DR strategies within the EU offer a pragmatic balance between sovereignty and resilience. Deploying primary systems in one EU region (e.g., France) and DR systems in another (e.g., Germany or the Netherlands) provides geographic diversity against regional disasters while maintaining full EU data residency. Ensure that cross-border data flows within the EU do not trigger Member State-specific localisation requirements — while GDPR protects intra-EU data flows, certain sector-specific regulations (financial services, healthcare, public administration) may impose national data residency obligations that constrain the choice of DR region.

Disaster recovery planning is not a project with a completion date — it is an ongoing governance responsibility that requires continuous maintenance, periodic review, and governance-level oversight. The DR plan must evolve as the IT environment changes: new systems are deployed, existing systems are decommissioned, dependencies shift, regulatory requirements change, and the threat landscape evolves. A DR plan that accurately reflected the IT environment twelve months ago may be dangerously inaccurate today.

Establish a DR plan maintenance process that includes triggered updates and scheduled reviews. Triggered updates occur when a material change affects DR: a new critical system is deployed, a system is migrated to new infrastructure, a third-party dependency changes, an organisational restructuring changes recovery team composition, or a test reveals a gap that requires plan modification. Scheduled reviews occur at defined intervals — quarterly for critical system recovery plans, semi-annually for supporting system plans, and annually for the overall DR programme including strategy, governance framework, and resource adequacy. Both triggered updates and scheduled reviews should be documented, with changes tracked and approved through the governance structure.

Governance oversight of DR should include regular reporting to the governing body on DR capability status, test results, and remediation progress. For NIS2-subject entities, DR is part of the business continuity and crisis management measures under Article 21(2)(c), which the management body must approve and oversee under Article 20. For DORA-subject entities, the management body must approve the ICT business continuity policy under Article 11 and be informed of testing outcomes and gaps. Include DR status in the regular cybersecurity and ICT risk governance reporting — not as a separate reporting stream but integrated into the overall resilience posture assessment.

Finally, ensure that DR governance addresses the human dimension. Recovery teams must be trained, drilled, and supported. Maintain up-to-date contact lists with multiple communication channels (mobile, personal email, out-of-band messaging) in case primary communication systems are affected by the disaster. Define clear succession arrangements for key DR roles — if the primary recovery lead is unavailable during a disaster, the plan must not depend on their unique knowledge. Cross-train team members, document procedures at a level of detail that enables execution by competent staff who may not be the plan authors, and conduct regular walkthroughs to maintain familiarity. The most sophisticated DR technology is useless if the people responsible for operating it are unreachable, untrained, or unclear on their responsibilities.