Disaster Recovery Plan Template: What to Include and How to Keep It Usable

Having a disaster recovery plan is the easy part. The trouble starts on the day you need it: the plan sits on the file server that just went down, the on-call number belongs to someone who left last spring, and the restore steps describe a system you replaced two years ago.

A good disaster recovery plan template fixes the first problem: it tells you what to write down. This guide answers what a disaster recovery plan should include, section by section, with a short example for each. It also covers the part templates usually skip: how to keep the plan current, owned, and reachable, so it works when everything else doesn't.

What is an IT disaster recovery plan?

An IT disaster recovery plan is a written set of procedures for restoring your systems, applications, and data after a disruption, in a set order and within agreed time limits. It names who does what, how they get notified, and how you know a system is truly back.

In US federal guidance (NIST SP 800-34), the equivalent document is the information system contingency plan. It is organized around three phases:

1. Activation and notification. Decide that the plan is in effect and alert the recovery team.
2. Recovery. Restore the system, either at an alternate site or with backup capabilities.
3. Reconstitution. Test the restored system, confirm it works, and return to normal operations.

That structure works as a skeleton whether you run a 20-person company or a large IT department.

Disaster recovery plan vs. business continuity plan

These two plans are related but not the same.

• A business continuity plan covers how the whole organization keeps operating during a disruption: people, facilities, suppliers, customers, and communications.
• A disaster recovery plan covers the technology part: getting hardware, software, connectivity, and data back.

Ready.gov, the US government's preparedness site, recommends developing the IT disaster recovery plan in conjunction with the business continuity plan. The business side decides which processes matter most and how long they can be down. The IT plan then sets recovery times that meet those needs. Written in isolation, the IT plan ends up guessing at priorities.

Three terms to settle before you fill in the template

Your template will ask for these numbers. Agree on them with the business owners first, through a business impact analysis (BIA).

• Maximum tolerable downtime (MTD): the total time the business is willing to accept a process being unavailable.
• Recovery time objective (RTO): the longest a system can stay unavailable before it causes unacceptable impact. NIST ties it to the MTD: you pick technology and procedures that can meet the RTO so the MTD isn't exceeded.
• Recovery point objective (RPO): the point in time to which data must be recovered after an outage. In plain terms: how much recent data you can afford to lose. Your RPO drives how often you back up.

Write these per system, not once for the whole company. Your payroll system and your internal wiki will not have the same targets.

Disaster recovery plan template: section by section

Use the outline below as your template. Where it helps, each section includes a disaster recovery plan example to show the level of detail.

1. Purpose, scope, and assumptions

State which systems, locations, and services the plan covers, and which it doesn't. List your assumptions, such as "backups are stored at a second location" or "staff can work remotely."

Example: "This plan covers the customer portal, billing database, and email. Office phones are covered by the facilities plan."

2. Roles, responsibilities, and contacts

Name a plan owner (often called the plan coordinator) and the recovery team. For each role, list a primary and a backup person. Include a call tree: who calls whom, in what order.

Add external contacts too, such as your hosting provider, internet provider, key software vendors, and insurer, with account numbers and support contract details.

3. System inventory and priorities

Ready.gov's guidance starts here: inventory your hardware, software applications, and data, and identify which applications are critical. For each system, record:

• what it does and who depends on it
• its RTO and RPO
• what it depends on (network, identity provider, database, another service)
• where its backups live

Then rank the systems in recovery order. Dependencies decide much of this ranking: there's no point restoring an app before the database it reads from.

4. Activation criteria and notification

Define when the plan is triggered and who has the authority to trigger it. Vague criteria cost time while people debate whether it's "bad enough."

Example: "Activate if the billing database is unavailable for more than 30 minutes, or immediately on confirmed ransomware. The IT lead or the COO can activate."

Then describe how the team is notified. Include a backup channel that doesn't depend on your own email or chat, because those may be down too.

5. Recovery procedures

This is the core of the plan. Write step-by-step restore procedures for each critical system, in recovery order. Good procedures:

• start from a known state ("You have access to the backup console and the admin vault")
• use numbered steps with one action each
• say how to check that each step worked
• say what to do and whom to call if a step fails

If you already keep IT runbooks, link to them from here instead of copying them. Copies drift apart. For tips on writing the steps themselves, see our guide on how to write an IT runbook.

6. Backup and data restoration

Record what is backed up, how often, where it's stored, and how to restore it. Base the backup frequency on each system's RPO.

If ransomware is on your risk list, follow the advice of CISA, the US Cybersecurity and Infrastructure Security Agency: keep offline, encrypted backups of critical data. Many ransomware variants look for accessible backups and delete or encrypt them. CISA also recommends regularly testing the availability and integrity of your backups in a disaster recovery scenario.

7. Reconstitution and return to normal

Describe how you confirm a restored system is ready for users: functional tests, data checks, security checks, and who signs off. Then list the cleanup steps: switching traffic back, retiring temporary systems, and telling users that service is restored.

8. Appendices

NIST suggests keeping supporting material with the plan, including vendor contracts and SLAs, software licenses, system user manuals, and operating procedures. Add network diagrams and a contact list, and keep both current. NIST points out that contact lists need more frequent review than the rest of the plan.

Disaster recovery plan steps: how to build yours

If you're starting from scratch, NIST SP 800-34 describes a seven-step process. It scales down well for a disaster recovery plan for small business teams:

1. Write a short policy statement that gives the plan authority and an owner.
2. Run a business impact analysis to find your critical systems and their RTOs and RPOs.
3. Identify preventive controls that reduce the chance or impact of an outage.
4. Choose recovery strategies for each critical system.
5. Write the plan using the template above.
6. Test, train, and exercise the plan.
7. Maintain the plan as a living document.

Step 5 gets most of the attention. Steps 6 and 7 are what keep the plan working.

How to test a disaster recovery plan

An untested plan is a hypothesis. NIST describes two common exercise types:

• Tabletop exercises: the team meets, a facilitator presents a scenario, and people talk through their roles and responses. They're quick to run and good at exposing gaps in who does what.
• Functional exercises: people perform their duties in a simulated environment. These range from testing one piece, like the notification call tree, to a full-scale restore.

Start with a tabletop exercise. If you need a starting point, the UK's National Cyber Security Centre offers Exercise in a Box, a free resource used by small and medium-sized businesses, local government, and emergency services. It covers setting up, planning, and running an exercise, and identifying actions afterward.

Whatever the format, end every exercise by updating the plan with what you learned.

How to keep your disaster recovery plan usable

A template gets you a first version. These habits keep it working.

Make it reachable when your systems are down

NIST recommends giving copies of the plan to recovery staff and storing a copy at the alternate site and with the backup media. CISA's ransomware guide makes the same point for incident response plans: keep a hard copy and an offline version available. Check where your plan lives today. If the only copy is on the network you're trying to recover, you don't really have a plan.

Give it one owner and one source of truth

Copies that drift apart are just as risky as no copy at all. Keep one master version with version history, and make every printed or offline copy from it, so everyone knows which version is current. NIST also suggests that the plan coordinator keep a record of who holds copies.

Review it on a schedule and on every change

NIST's rule of thumb: review the plan at a set frequency, and whenever any part of it changes significantly. New systems, retired vendors, and staff changes all count. Tie plan updates to your change management process so they don't wait for the annual review. Our post on documentation governance covers how to set up owners and review cycles.

Train people so they don't depend on the document

NIST recommends training recovery staff at least annually, and training new team members soon after they join. The goal is that people can do their part even if the plan is out of reach for the first few hours of an outage.

Keep your plan in one place

A disaster recovery plan is documentation, and it fails the same way other documentation does: it gets outdated, duplicated, and forgotten. Treat it like a living document, with one owner, one current version, regular reviews, and copies you can reach on a bad day.

Sonat gives IT teams one place to write, version, and publish documents like this. Draft the plan in Google Docs, keep every version in one history, route changes through an approval workflow, and publish it as a private manual your recovery team can open on any device. You can start for free, with no credit card required.