Disaster Recovery Plan (DRP): Complete 2026 Guide

A disaster recovery plan (DRP) is the documented set of procedures that lets an organisation restart its IT after a major incident (fire, infrastructure failure, cyberattack) within a recovery time and with a maximum data loss agreed in advance with the business: the RTO and the RPO. It states what to restore, in what order, by whom, from which backups and onto which infrastructure.

Many DR plans were written for the server-room fire. Today's dominant scenario is ransomware that encrypts production, goes after the backups and compromises the directory. This guide shows how to build, test and evidence a DR plan that holds up in both cases.

The 30-second version

• A DR plan restarts IT; a business continuity plan keeps the business running. The DRP is part of the BCP, not a substitute for it.
• Recovery objectives come from the BIA: each system inherits the most demanding RTO of the processes that depend on it.
• Recovery order matters as much as speed: identity, DNS and backup infrastructure come before business applications.
• Against ransomware, only an offline or immutable copy, restored into a clean environment, gives you a trustworthy starting point.
• DORA requires recovery plans to be tested at least yearly; NIS2 explicitly names backup management and disaster recovery.

What is a disaster recovery plan, and how does it differ from a BCP?

A DR plan covers the technical side of continuity: infrastructure, applications, data, networks, identities. It starts from one assumption: the service has stopped. Its job is to bring it back within the agreed time, with acceptable data loss, without reintroducing whatever caused the outage.

The BCP is the umbrella; the DRP and high-availability design are its technical building blocks. A DRP without a BCP leaves business teams with no instructions while systems are being restored; a BCP without a DRP promises a recovery nobody knows how to execute. The full method is in our business continuity plan guide.

What does a DR plan contain?

A useful DR plan can be read under stress and executed by deputies. Six sections are enough.

1. Scope and scenarios

Sites, platforms (data centre, cloud, SaaS) and scenarios: loss of a site, of a cloud region, of the directory, encrypted or corrupted data, failure of a provider.

2. System inventory, ranked by tier

Each system inherits the most demanding RTO and RPO of the business processes that depend on it, as set by the BIA. Grouping systems into tiers simplifies strategy and budget decisions:

These values are illustrative: yours must come from the BIA. Tier 0 has no "business RTO", but nothing restarts without it. To calibrate: RTO vs RPO explained and the RTO/RPO calculator.

3. Dependencies and recovery order

The most frequently missing section. France's national cybersecurity agency, ANSSI, recommends defining a restore order that accounts for dependencies on infrastructure services (DNS, NTP, directory), application criticality and restore times. In practice: a recovery graph in which each system has its prerequisites and its health checks.

4. Roles and decision rights

Who declares the disaster, who decides to fail over, who signs off the return to production? Named owners and deputies, reachable outside corporate IT. Failing over loses whatever data has not yet been replicated, so the decision belongs to a designated person, on written criteria.

5. Runbooks and communication

One runbook per system: prerequisites, steps, where the backups and encryption keys are, break-glass accounts, the duration measured at the last test, all available offline. Add messages to business teams, customers and, when the incident is reportable, regulators (see NIS2 incident notification: 24h, 72h and 1 month).

6. Failback

Returning to primary infrastructure is a second switchover: data resynchronisation, integrity checks and reconciliations (DORA explicitly requires them after an ICT-related incident), business sign-off, formal closure.

Our disaster recovery plan template follows this structure.

Which DR strategy should you choose?

Four DR strategies cover most cases. The shorter the RTO, the higher the bill:

Two mistakes keep coming back. The first is confusing replication with backup. Replication copies a malicious deletion or an encryption to the recovery site within seconds; only a point-in-time backup kept out of reach lets you go back. Even active-active needs backups. The second is choosing a strategy on technical preference rather than on the BIA. The recovery cost estimator helps make the trade-off explicit.

Backups: is the 3-2-1 rule enough?

In its guide Sauvegarde des systèmes d'information – Les fondamentaux (version 1.1, November 2025), ANSSI recommends the 3-2-1 rule: three distinct copies of the data (production plus two backups), on different media, one of them offline. It considers an offline copy indispensable, even if less frequent. Immutable (WORM) copies are an acceptable compromise for frequent backups, offline remaining more robust. Vendors also talk about "3-2-1-1-0": one immutable or offline copy, zero errors on restore verification.

The same ANSSI guide adds precautions without which the rule does not hold:

• Isolate the backup infrastructure: outside the production Active Directory domain, with independent authentication and dedicated admin accounts.
• Back up the backup: catalogue, binaries, import procedures, encryption keys. Without them, the media are unusable.
• Test restores regularly, following a written procedure.

Geography matters too. When fire hit OVHcloud's Strasbourg data centre on the night of 9–10 March 2021, some customers discovered that their backups were stored on the same site as their servers.

And a backup that has never been restored is only a hypothesis. The one metric that counts is the date of the last successful restore test, with its measured duration.

How do you recover from ransomware?

Ransomware changes the nature of recovery. According to ANSSI, attackers frequently try to encrypt, erase or disable the backup infrastructure to slow down the rebuild. Recovery becomes a remediation project (containment, eviction, eradication, rebuild) that can last weeks or even months. Ransomware recovery deserves its own section in the plan.

Isolate the backups first

This is the priority measure ANSSI recommends in a security incident. It requires a "red button" prepared in advance: a script, a network switch you can disconnect.

Preserve the evidence

Every remediation action destroys traces needed by the investigation and by any legal proceedings. You have to balance recovery speed against evidence collection, together with the forensic team. Reusing compromised servers straight away loses evidence; a time-stamped incident log will matter later for the courts and the insurer.

Rebuild the core of trust first

The directory (usually Active Directory) and IT administration form what ANSSI calls the core of trust. If it stays compromised, everything restored afterwards is compromised too; according to the agency, a failed rebuild typically leads to compromise-and-remediation cycles that can last months, or even years. A ransomware recovery sequence therefore starts with identity, not with the ERP.

Restore into a clean, isolated environment

Backups may contain the attacker's implants. Reinstall systems from trusted images and applications from vendor-signed binaries, check configurations, scan data before re-importing it. The restore point must predate the compromise, often well before the latest backup: your real RPO then exceeds the planned one. DORA, for its part, requires financial entities restoring with their own systems to use systems physically and logically segregated from the source system.

Plan for hardware, licences and outside expertise too: rebuilding a clean environment needs all three, and the contracts are negotiated before the crisis. To rehearse, see our 10 crisis exercise scenarios, which open with ransomware.

Cloud and SaaS DR: who is responsible for what?

Under the shared responsibility model, the provider is accountable for the resilience of its infrastructure; configuration, data, identities and the recovery strategy for your workloads remain yours.

• Losing a region. Multiple availability zones protect you against losing a building, not a whole region. On 20 October 2025, a defect in DynamoDB's DNS management disrupted the AWS us-east-1 region for more than fourteen hours for its main services, according to AWS's post-event summary.
• The account as a single point of failure. A compromised admin account can delete production and the backups stored alongside it. Keep copies in a separate account, locked against deletion.
• SaaS. The vendor restores its service, not necessarily your data to the point you need. Check retention, export and exit terms, and keep regular exports of critical data.

Another hidden dependency: on 19 July 2024, a faulty CrowdStrike update took down about 8.5 million Windows devices, according to Microsoft; the fix required hands-on work on each machine, sometimes with the BitLocker recovery key. Where are those keys, and how do you reach them without corporate IT?

Detailed architectures: BCDR for AWS and BCDR for Azure.

How should you test a disaster recovery plan?

Each type of disaster recovery testing answers a specific question:

For financial entities other than microenterprises, DORA requires these tests to include cyberattack scenarios and switchovers to redundant capacity.

The RTO gap: the metric that matters

The BIA's RTO is a requirement; the recovery time measured in testing is a capability. The gap between them is the most useful thing a DR plan can tell senior management. To measure it honestly:

1. Time it end to end: from the disaster declaration to business sign-off, not to the moment the virtual machine boots.
2. Follow the critical path: an ERP restored in 2 hours is useless if the directory takes 10.
3. Decide: revise the RTO, invest, or formally accept the risk. Leaving the gap undecided is not an option.

Every finding becomes a corrective action with an owner and a due date.

Is a DR plan mandatory? What NIS2, DORA and GDPR require

None of these texts uses the words "disaster recovery plan" as a document title, but all require the capability:

DORA has applied since 17 January 2025 (text on EUR-Lex); NIS2 transposition is still incomplete in several member states, but the directive's text already sets the bar. Either way, auditors will ask for the plan, the date and outcome of the last test, and how gaps are tracked. See our DORA guide 2026.

What ResiPlan does, concretely

ResiPlan is the management layer for your DR plan, not a backup tool: it does not run backups, failovers or infrastructure orchestration.

• DRP pre-filled from the BIA: one of 8 plan types; the BIA's RTOs and RPOs become its objectives.
• AI first draft, reviewed and approved by your team.
• Recovery gaps surfaced: process ↔ IT service links flag where a process's RTO is shorter than the recovery capability of the systems it depends on.
• Dependencies simulator: simulate the loss of an asset or supplier and see which processes are hit.
• Tracked tests: "technical DR test" exercises, findings turned into tracked corrective actions.
• Evidence: NIS2 Article 21, DORA and ISO 22301 mapped, downloadable evidence pack.

Business data is hosted in the EU. Software does not make anyone compliant and certifies no one: ResiPlan structures and evidences the work your team does. Free 7-day trial, no credit card.

Checklist: is your DR plan ready?

• Every system has a tier, an RTO and an RPO derived from the BIA.
• Directory, DNS, backup and key management have their own rebuild procedure.
• The recovery order is written down, with each system's prerequisites.
• At least one copy of critical data is offline or immutable, on a separate site.
• The backup infrastructure sits outside the production domain; its catalogue and encryption keys are reachable without corporate IT.
• Ransomware is handled as its own scenario: isolation, evidence, core of trust, clean environment.
• Cloud and SaaS dependencies are identified, with exports and exit terms checked.
• Critical systems have been successfully restored in the last 12 months, with measured duration.
• A DR exercise, failback included, took place this year and the RTO gap is tracked.

FAQ

What is the difference between a disaster recovery plan and a business continuity plan?

A BCP keeps essential activities running during a disruption, across the whole organisation: business units, people, premises, suppliers and IT. A DR plan restarts IT after the outage. The DRP is part of the BCP, which relies on its recovery times to size degraded-mode procedures.

Is a disaster recovery plan mandatory?

No regulation requires a document with that exact title. But NIS2, DORA and GDPR all require the capability it describes: backups, recovery, tested recovery plans, restored access to data. Without a DR plan, you cannot demonstrate it.

How often should a DR plan be tested?

A significant exercise at least once a year for the critical scope, which is DORA's minimum, and after every major infrastructure change. Restore tests are worth running more often: they are cheap and quickly expose a failing backup.

Are backups enough to recover from ransomware?

No. You need a copy out of the attacker's reach (offline or immutable), a backup infrastructure isolated from the production domain, and a restore into a clean environment after the directory has been rebuilt. Otherwise you restore the attacker along with the data.

Does moving to the cloud remove the need for a DR plan?

No. The provider ensures the resilience of its infrastructure, not the recovery of your workloads: configuration, data, identities, multi-region design and backups remain your responsibility. At a minimum, plan for the loss of a region and of your admin account.

Further reading

• Business Continuity Plan (BCP): 8-step guide for 2026
• RTO vs RPO: matrix and sector benchmarks
• BIA guide: the complete business impact analysis playbook
• Disaster recovery plan template
• RTO/RPO calculator

A DR plan is only as good as its last successful test: that is the first date an auditor, an insurer or a board should ask you for.