What is a disaster recovery plan? How to build one in 6 steps

Key takeaways

• A disaster recovery plan restores your IT after ransomware, power outages, or hardware failure.
• Every plan starts with two targets for each system: a recovery time objective (RTO) for how long it can be down, and a recovery point objective (RPO) for how much data it can lose.
• You can build a plan in six steps, and the last step, testing, shows whether the plan works.
• Frameworks like PCI DSS and HIPAA expect a recovery plan you can prove you tested, so records are necessary.

If you’re part of an IT team, you’re also the help desk, security lead, and the person who renews the software licenses. A disaster recovery plan sits at the bottom of the to-do list until something goes wrong.

Learn what goes into a plan, how to set recovery targets, and how to test it in six steps. Each step produces something you can use, and at the end you’ll have a plan your team can follow and an auditor can check.

What is a disaster recovery plan?

A disaster recovery plan is a written plan for restoring your data, applications, and hardware after an incident takes them offline. It sets out which systems come back first, who does the work, and how long each step takes. 

The plan covers incidents like:

• Ransomware and other cyberattacks
• Power outages
• Heat waves that overwhelm cooling systems
• Floods
• Hardware failure

The plan is IT-focused and sits inside your business continuity plan, which covers how the whole business keeps operating, including staff, offices, and customers. It also picks up where your incident response plan leaves off. Incident response keeps the problem from spreading, and disaster recovery is what brings your systems back.

Downtime can get expensive, fast. EN Computers estimates that one day of downtime for a 50-person business with $10 million in revenue costs nearly $53,000.

---

A disaster recovery plan is like the fire escape route for your IT. You map it and practice drills before there’s a fire, because during one, there’s no time to figure it out. 

---

Disaster recovery metrics: RTO and RPO

Disaster recovery puts how fast you need to recover, and how much data you can lose into two targets: RTO and RPO.

• Recovery time objective (RTO) is the longest a system can stay down before the damage to your business is more than you can absorb.
• Recovery point objective (RPO) is how much recent data you can afford to lose, measured in minutes or hours. It tells you how old your last usable copy can be., so if you back up every night, you could lose up to a day of data.

Short targets need more in place ahead of time. You can’t meet a four-hour RTO by rebuilding a server from scratch, so you need a standby system ready to take over. A 15-minute RPO calls for replication or very frequent backups.

Set targets for each system separately. Your payment system and your internal wiki don’t need the same RTO. For how to work out the numbers, see our guide to RTO vs RPO.

Key components of a disaster recovery plan

The key components of a disaster recovery plan are a business impact analysis, a risk assessment, an asset inventory, roles and responsibilities, data backup and redundancy, recovery sites, and communication protocols. A plan missing one of these leaves your team guessing during an outage, which means longer downtime and higher costs.

Business impact analysis

A business impact analysis identifies your critical systems and what it costs when each one goes down. It produces the ratings you use to set RTO and RPO. A system that stops revenue gets a tighter target than one that slows down a back-office task.

Risk assessment

A risk assessment lists the threats your plan has to cover and how likely each one is. That can include ransomware, floods, power failures, and hardware failure. Include software that is no longer supported, like CentOS, older Windows servers, and outdated PHP versions, since it no longer gets security patches and gives attackers an easy way in.

Asset inventory

An asset inventory lists your hardware, software licenses, cloud accounts, and data, ranked by how critical each one is. Record dependencies too. If your accounting system needs the database server and the login server to run, bring those back first.

Roles and responsibilities

Roles and responsibilities name the people who run the recovery. At minimum, you need a recovery lead, someone from IT operations, and a communications owner. Name an alternate for each role in case the first person can’t be reached.

Data backup and redundancy

Data backup and redundancy cover how often you back up, where the copies live, and how you restore them. Keep at least one copy separate from your main systems. A standby copy on the same hardware fails along with the original.

Disaster recovery as a service (DRaaS) is one way to handle this. A provider copies your systems to its infrastructure and runs them there when your main environment goes down. DRaaS supports a plan, but it doesn’t replace one. 

Recovery sites

Recovery sites are where your systems run while your main environment is down. There are three main types:

• Hot site: Mirrors your main environment and runs all the time. Recovery takes minutes, at the highest cost.
• Warm site: Has equipment installed and gets copies of your data on a regular schedule. Recovery takes hours, at a moderate cost.
• Cold site: Has space, power, and a network connection, but little equipment. Recovery takes days, at the lowest cost.

Communication protocols

Communication protocols set who gets alerted, in what order, and how. Name one channel that still works during a full outage. If your email and phones run on the systems that went down, a text message tree or an outside messaging app keeps people in touch.

How to build a disaster recovery plan in 6 steps

You can build a disaster recovery plan in six steps.

1. Conduct a business impact analysis and risk analysis

List your systems and estimate what an hour of downtime costs for each one, counting lost revenue, staff who can’t work, and any contract penalties. Then score each threat by how likely it is and how badly it would hit those systems.

Output: Ranked critical systems

2. Define RTO and RPO targets for each application

Use your ranking to set how long each application can be down and how much data it can lose. Group applications into tiers so that similar systems share the same targets. For example, tier 1 could cover systems that have to be back within an hour, and tier 3 systems can wait a day.

Output: Targets by tier

3. Inventory your assets

Start with each critical application and list everything it needs to run, including servers, databases, login systems, software licenses, and DNS. Ask the person who runs each system what’s missing, since small dependencies like a license key or a DNS record are the ones that stall a recovery.

Output: Inventory in recovery order

4. Establish procedures for data backup, failover, and restoration

Write a runbook for each critical system, sorted by incident type. Each runbook covers how to restore the system, the order things come back in, and how to fail back to your main environment once it is fixed. Keep a printed copy and an offsite copy, since a plan stored only on your servers won’t help when they’re down.

Output: Runbook per critical system

5. Assign team roles and contact trees

Name who does what during a recovery, and build a contact tree that shows who calls whom. Include your vendors, internet provider, and anyone with access to your domain registrar, then call down the tree once to check that every number works.

Output: Contact tree

6. Test and update the plan through simulations

Testing shows whether your team can follow the plan under pressure. There are three common types of test:

• Tabletop exercise: The team talks through a scenario step by step and finds gaps in roles, access, and contact details.
• Simulation: The team acts out its response to a specific scenario without switching over production systems.
• Full failover: Systems switch to the recovery site, and you time the switch against your RTO.

Test at least once a year, and again after any major change to your infrastructure. Write down what you tested, how long it took, what failed, and what you changed afterward.

Output: Dated test report

Disaster recovery plan examples

Disaster recovery plan examples show how a plan holds up during an incident.

Ransomware at a dental practice (hypothetical)

Scenario: A 40-person dental practice opens on Monday morning and finds its patient records and scheduling system encrypted by ransomware.

What the plan says: The recovery lead disconnects the affected servers and calls the practice’s IT provider. The team restores the records from the last backup made before the encryption started and checks that it is clean before bringing it online.

Under HHS guidance, ransomware that encrypts patient data is presumed to be a HIPAA breach unless the practice can show a low probability that the data was compromised. So the communications owner brings in the practice’s compliance contact to decide whether patients must be notified. Front desk staff work from a printed schedule until the system is back.

Result: Because the practice was closed over the weekend, restoring from the last clean backup loses no patient data, and scheduling is back the same day. It also has a written record of every step it took, in case regulators ask.

For more, see our guide to disaster recovery for ransomware.

Power outage at a law firm (hypothetical)

Scenario: During a heat wave, a 60-person law firm loses power, and its server room overheats when the cooling goes down too.

What the plan says: The utility expects power to be out for at least a day, longer than the four-hour RTO the plan sets for document management. So the recovery lead declares a disaster, and the team fails over to a standby site with redundant power and cooling. The communications owner texts staff instructions for reaching the system there.

Result: Attorneys keep working on filings due that day. When power comes back, the team checks that the cooling works, then fails back to the main environment.

Ready.gov’s business planning resources offer a free structure to start from.

Auditors will also want proof that your plan works.

Compliance requirements for disaster recovery

Compliance requirements for disaster recovery depend on the data you handle. Here’s what four common frameworks expect.

Framework	Who it applies to	What it expects around recovery
PCI DSS v4.0	Any business that stores, processes, or transmits payment card data	An incident response plan that includes business recovery procedures and data backup processes, reviewed and tested at least once every 12 months (Requirements 12.10.1 and 12.10.2)
HIPAA Security Rule	Healthcare providers, health plans, and their business associates that handle electronic patient data	A contingency plan with a data backup plan, a disaster recovery plan, an emergency mode operation plan, and procedures for testing and revising them (45 CFR 164.308(a)(7))
SOC 2	Service organizations whose customers ask for a SOC 2 report	When the Availability criteria are in scope: backup and recovery infrastructure (A1.2) and testing of recovery plan procedures (A1.3)
GLBA	Financial institutions, including banks, credit unions, lenders, and tax preparers	A written incident response plan under the FTC Safeguards Rule. Banks and credit unions must also protect customer information against loss from hazards like fire, water damage, and technology failures, and are examined against FFIEC business continuity guidance.

Two others apply: CMMC, which requires Department of Defense contractors to protect backups of controlled unclassified information, and ISO 27001, which includes controls for information backup and IT readiness for business continuity.

Keep test reports, restore logs, and plan review dates in one folder so you can hand them over when asked, and confirm the details with your auditor.

Managed disaster recovery with Nexcess

Managed disaster recovery with Nexcess powered by Acronis takes most of the work of recovery off your team.

Nexcess Managed Cloud runs your servers, network, and security day-to-day. When you add disaster recovery, you still set your recovery targets. We build and run the systems that meet those targets.

• Disaster recovery built on Acronis, with a hot-standby environment ready to take over
• Automated DR testing and written runbooks, so the recovery steps are known before you need them
• PCI-ready environments, with test results you can give your auditor

What sets Nexcess apart:

• 24×7 experts who answer when something breaks
• Migration without fear, including moves from VMware to Nutanix
• A whole cloud solution, with dedicated servers, our data center, DR, and security working together

You run your business. We run everything else. The result is less risk, predictable cost, and expert-managed support. Talk to a Nexcess engineer about your recovery targets and the plan you have now. Below are short answers to common questions about disaster recovery plans.