A disaster recovery (DR) plan is a written, tested procedure for restoring IT systems and data after a major outage, cyberattack or site loss. It names who declares a disaster, which systems return first, how fast (RTO), how much data loss is acceptable (RPO), and the steps to fail over and back.
Key takeaways
- A DR plan restores technology; a business continuity plan keeps the whole business running. You need both, and the DR plan should be a subset of the continuity plan.
- Every recovery decision starts with two numbers per system: the recovery time objective (RTO) and the recovery point objective (RPO).
- Cloud DR follows four standard strategies: backup and restore, pilot light, warm standby and multi-site active/active. Cost and recovery speed rise together.
- An untested plan is a guess. Test at least once a year, and more often for critical systems, using tabletop exercises through to full failover.
- In the EU, NIS2 Article 21 lists "backup management and disaster recovery" as a minimum security measure. In Sweden it applies through the Cybersecurity Act (Cybersäkerhetslagen) from 15 January 2026.
What is a disaster recovery plan?
It is the technical playbook for getting systems back after an event that normal resilience cannot absorb. Typical triggers are ransomware, a data centre or cloud region outage, a corrupted database, a failed change, fire or flooding.
NIST SP 800-34 defines a DR plan as "a written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities" (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). The same guide stresses that a DR plan is information-system focused, while a business continuity plan covers business processes such as payroll or customer service.
You will also see the terms "IT disaster recovery plan" and "DRP". They mean the same thing. A good one is short enough to use under pressure: decision rights, priorities, runbooks, contacts and evidence of testing. A long policy document that nobody has opened since the last audit does not count.
Disaster recovery vs business continuity
Disaster recovery restores IT. Business continuity keeps the organisation delivering its products and services while IT, people, premises or suppliers are disrupted. The AWS whitepaper on DR puts it plainly: the DR plan "should be a subset of your organization's business continuity plan (BCP), it should not be a standalone document."
| Aspect | Disaster recovery (DR) | Business continuity (BC) |
|---|---|---|
| Scope | IT systems, applications, data, networks | Whole organisation: people, processes, premises, suppliers, communication |
| Main question | How do we restore systems and data? | How do we keep serving customers during the disruption? |
| Key targets | RTO and RPO per system | Maximum tolerable downtime per business process |
| Typical owner | CIO, CTO, head of infrastructure | COO, risk or continuity manager |
| Output | Runbooks, failover and failback procedures | Continuity plan, manual workarounds, crisis communication |
For a longer comparison, including BCDR in AWS, Azure and Google Cloud, read our guide to disaster recovery and business continuity in the cloud.
Backup vs disaster recovery
Backup is a copy of data. Disaster recovery is the ability to run the service again. You can have perfect backups and still be down for days if nobody has scripted how to rebuild servers, networks, identities and DNS around them. Backups are one input to the DR plan; the 3-2-1 rule (three copies, two media types, one offsite) is a sensible baseline for them.
What is the purpose of a DR plan?
The purpose is to make recovery predictable. When a disaster hits, the plan replaces improvisation with decisions that were made calmly in advance.
- Limit downtime. Critical systems come back within an agreed time, in an agreed order.
- Limit data loss. Backups and replication run at the frequency the business signed off.
- Remove ambiguity. Everyone knows who can declare a disaster, who leads, and who talks to customers and authorities.
- Control cost. Not every system needs a hot standby. The plan records which ones do and why.
- Show compliance. Regulators, auditors, insurers and enterprise customers increasingly ask for tested recovery capability, not just a policy.
These are also the benefits buyers ask about. A plan that has been exercised shortens real outages because people have already practised the steps.
RTO and RPO: the two numbers that drive the plan
The recovery time objective (RTO) is how long a system may be down. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose. AWS defines RTO as "the maximum acceptable delay between the interruption of service and restoration of service" and RPO as "the maximum acceptable amount of time since the last data recovery point."
Worked example. An online shop agrees an RTO of 4 hours and an RPO of 15 minutes for its order system. If the database fails at 10:00, orders must be accepted again by 14:00 at the latest, and at most the orders placed between 09:45 and 10:00 may need to be re-entered or recovered by other means. A nightly backup cannot meet that RPO; the shop needs log shipping or replication at least every 15 minutes. Its internal wiki, by contrast, might accept an RTO of 3 days and an RPO of 24 hours, which a daily backup covers.
Two practical rules help:
- Set targets per system, through a business impact analysis, not one number for "IT". Impact can also change over time: AWS notes that a payroll outage just before pay day hurts far more than one just after.
- Keep the RTO below the maximum tolerable downtime for the business process. NIST SP 800-34 explains that the RTO "must normally be shorter" than that limit, because data still has to be re-processed after systems return.
For more examples and a step-by-step method for setting both targets, see RPO and RTO in disaster recovery explained.
DR strategies: from backup and restore to active/active
The AWS whitepaper Disaster Recovery of Workloads on AWS groups cloud DR into four strategies. The same patterns apply on Azure (where Azure Site Recovery replicates virtual machines to a secondary region) and on Google Cloud.
| Strategy | What runs in the recovery region | Indicative RPO / RTO (AWS) | Relative cost | Fits |
|---|---|---|---|---|
| Backup and restore | Only backups; infrastructure is rebuilt from code after the event | Hours | Lowest | Lower-priority systems, data-corruption protection |
| Pilot light | Data is replicated and live; application servers are provisioned but switched off | Tens of minutes | Low to medium | Core systems that can tolerate a short outage |
| Warm standby | A scaled-down but fully working copy that already serves traffic at reduced capacity | Minutes | Medium to high | Business-critical systems |
| Multi-site active/active | Full production in two or more regions, all serving users | Near real time | Highest | Mission-critical services where downtime is not acceptable |
The distinction between pilot light and warm standby confuses many teams. AWS puts it this way: a pilot light environment "cannot process requests without additional action taken first", whereas a warm standby "can handle traffic (at reduced capacity levels) immediately." Our article on pilot light disaster recovery covers that pattern in detail.
Two points from the whitepaper are often overlooked. First, a multi-AZ design inside one region "may already meet much of your risk mitigation needs" for data-centre-level failures; a second region is for region-wide events or regulatory demands. Second, backup and restore only works quickly if the infrastructure is defined as code, because you must redeploy networks, servers and configuration as well as data.
DRaaS and cloud disaster recovery
Disaster recovery as a service (DRaaS) means a provider replicates your servers to its cloud and runs the failover tooling. AWS Elastic Disaster Recovery and Azure Site Recovery are the native options; managed service providers build runbooks, monitoring and testing around them. DRaaS turns a capital project (a second data centre) into a running cost, but it does not remove your responsibility to set RTO/RPO, approve the plan and take part in tests.
Hot, warm and cold sites
Before cloud regions, DR strategies were described by the readiness of the alternate site. NIST SP 800-34 describes cold sites as space with power, cooling and connectivity but no equipment, warm sites as partially equipped with hardware and telecoms, and hot sites as fully configured with hardware, infrastructure and staff. A cold site is the cheapest but can take days or weeks to bring up. The cloud equivalents map roughly to backup and restore (cold), pilot light or warm standby (warm) and active/active (hot). Read more in what is a hot site in disaster recovery.
What should a DR plan include? Checklist
Use this checklist to build a new plan or audit an existing one. Each line should exist as a named, dated artefact, not as a promise.
| # | Element | What to document |
|---|---|---|
| 1 | Scope and owner | Systems and locations covered, plan owner, approval date, review date |
| 2 | Risk assessment | Threats per site and service: ransomware, region outage, insider error, supplier failure, fire, flood |
| 3 | Business impact analysis | Business processes, their maximum tolerable downtime and the systems they depend on |
| 4 | Recovery objectives | RTO and RPO per system or tier, signed off by the business |
| 5 | System inventory and dependencies | Applications, databases, identity, DNS, network, SaaS and third-party APIs, in recovery order |
| 6 | Recovery strategy per tier | Backup and restore, pilot light, warm standby or active/active, with the reason and cost |
| 7 | Backup and replication | Frequency, retention, encryption, offsite or cross-account copies, immutable copies, restore tests |
| 8 | Activation criteria | Events that trigger the plan, who can declare a disaster, and their deputies |
| 9 | Roles and contacts | DR lead, technical teams, communications, management, cloud provider and supplier escalation paths, kept offline as well |
| 10 | Runbooks | Numbered failover steps, validation checks, DNS changes, and failback to the primary site |
| 11 | Communication plan | Templates and channels for staff, customers, suppliers, regulators; regulatory deadlines |
| 12 | Testing and maintenance | Test schedule, last test result, open findings, and plan updates after every change or incident |
How to create a DR plan in seven steps
- Run a business impact analysis and risk assessment. This is the first step in any DR effort. List business processes, what an outage costs per hour, and which systems each one needs.
- Set RTO and RPO per system. Group systems into three or four tiers so you design for tiers, not for hundreds of individual servers.
- Choose a strategy per tier. Match each tier to backup and restore, pilot light, warm standby or active/active. Check the cost against the impact you measured in step 1.
- Build the technical capability. Backups, cross-region or cross-account copies, replication, infrastructure as code, monitoring and alerting in the recovery environment too.
- Write the runbooks. Short, numbered steps that an on-call engineer can follow at 03:00, including failback.
- Test and fix. Start with a tabletop exercise, then restore tests, then a failover. Record the measured RTO and RPO.
- Maintain it. Review at least yearly and after every significant change to systems, suppliers or the organisation.
Disaster recovery for cyber incidents and ransomware
For many companies the disaster they actually need to plan for is ransomware or a compromised admin account rather than a flood. That changes the plan in three ways.
- Replication is not enough. AWS warns that continuous replication "may not protect against disaster events such as data corruption or malicious attack (such as unauthorized data deletion) as well as point-in-time backups." Keep point-in-time backups that attackers cannot delete, ideally in a separate account with different credentials.
- Recovery starts after containment. The incident response plan decides when the environment is clean enough to restore into. Restoring onto compromised infrastructure re-infects it.
- Identity is a dependency. If your identity provider or password manager is down or compromised, the runbooks must say how responders get access.
When is a DR plan invoked?
The plan is invoked when an outage exceeds, or is clearly going to exceed, what normal incident handling can fix within the RTO. Write the criteria down, for example "primary region unavailable for more than 30 minutes" or "production data encrypted by ransomware", and name who decides. See when should you activate a disaster recovery plan for typical triggers.
How often should a DR plan be tested?
Test at least once a year, and after every significant change. Critical systems deserve more frequent exercises. NIST's sample contingency policy says recovery capabilities "shall be tested annually", and the guide recommends reviewing the plan "at least annually" and after significant changes.
NIST also scales the depth of testing to the system's impact level. For low-impact systems a tabletop exercise is sufficient; moderate-impact systems need a functional exercise that includes recovery from backup; high-impact systems need a full-scale functional exercise that includes "a system failover to the alternate location."
| Test type | What happens | Disruption | Suggested cadence |
|---|---|---|---|
| Checklist review | Owners confirm contacts, inventory and runbooks are current | None | Quarterly, and after changes |
| Tabletop / walkthrough | A facilitator presents a scenario; the team talks through decisions and steps | None | At least yearly for every plan |
| Simulation / functional exercise | Teams perform real tasks, such as restoring a database, in a test environment | Low | Yearly or more for business-critical systems |
| Parallel test | The recovery environment is brought up alongside production and validated | Low | Yearly for tier 1 and tier 2 systems |
| Full failover (full interruption) | Production traffic actually moves to the recovery site and back | High | For the most critical systems, when the business accepts the risk |
The cadence column is our recommendation for a typical mid-sized company; your regulator or customers may require more. AWS sums up why testing matters: "the only error recovery that works is the path you test frequently." After each test, record the measured recovery time and data loss, compare them with your targets, and assign owners to every gap.
NIS2 and the Swedish Cybersecurity Act
For organisations in scope of NIS2, disaster recovery is no longer optional good practice. Article 21(2)(c) of Directive (EU) 2022/2555 (NIS2) requires the risk-management measures to include at least "business continuity, such as backup management and disaster recovery, and crisis management". Article 23 adds reporting deadlines for significant incidents: an early warning within 24 hours of becoming aware and an incident notification within 72 hours. Your DR plan and your incident reporting process therefore need to work together.
In Sweden, NIS2 is implemented by the Cybersecurity Act (Cybersäkerhetslag, SFS 2025:1506), which entered into force on 15 January 2026. Chapter 2, section 3 lists "kontinuitetshantering och krishantering" (continuity management and crisis management) among the minimum security measures. Expect supervisors to ask for evidence: a current plan, test reports and closed findings.
How Opsio helps
Opsio designs, runs and tests DR for workloads on AWS and Azure as part of its cloud disaster recovery service.
Frequently asked questions
What are the key components of a disaster recovery plan?
The core components are a business impact analysis and risk assessment, RTO and RPO per system, a recovery strategy per tier, backup and replication, activation criteria, roles and contacts, step-by-step runbooks including failback, a communication plan, and a testing and maintenance schedule.
What is the first step in a disaster recovery effort?
The first step is a business impact analysis combined with a risk assessment. It tells you which processes and systems matter most and how long they can be down, which sets the RTO and RPO that every later decision depends on.
How often should a disaster recovery plan be tested?
At least once a year and after every major change to systems or suppliers. Run tabletop exercises for all plans and restore or failover tests for critical systems, as NIST SP 800-34 recommends for higher-impact systems.
What is the difference between disaster recovery and business continuity?
Disaster recovery restores IT systems and data. Business continuity keeps the business operating during a disruption and covers people, premises, suppliers and communication as well. The DR plan should be part of the business continuity plan.
What are the four disaster recovery strategies in the cloud?
Backup and restore, pilot light, warm standby and multi-site active/active. They range from hours of recovery time at the lowest cost to near real-time recovery at the highest cost, according to AWS's DR whitepaper.
Does NIS2 require disaster recovery planning?
NIS2 Article 21(2)(c) requires essential and important entities to cover business continuity, "such as backup management and disaster recovery, and crisis management". In practice that means a documented, tested DR capability you can show to the supervisory authority.
Related reading: What Are the Goals of a Disaster Recovery Plan.
Written By
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by the cloud practitioner named in the byline above. We revise it when the technology or regulation it covers changes; the dates on this page show the latest update. Opsio maintains editorial independence.