IT Disaster Recovery Plan Template, With a Filled-In Example

An IT disaster recovery plan is the written procedure for restoring your systems and data after ransomware, hardware failure, a cloud outage or loss of the office. A usable template has nine parts: purpose and scope, roles and contacts, a system inventory with recovery tiers (RTO and RPO), backup locations, step-by-step recovery procedures, a communications plan, vendor contacts, a testing schedule and a change log. Below are the steps to write one, the template as a table, a filled-in example for a small office and a checklist to confirm the plan is finished.

We write and test these plans as part of our IT disaster recovery services. The sections draw on NIST SP 800-34, the federal contingency planning guide, adapted for a small business. A disaster recovery plan restores technology; keeping the business running in the meantime is business continuity planning, which has its own business continuity plan template, and the two plans should point at each other.

What is an IT disaster recovery plan?

NIST SP 800-34 calls it an information system contingency plan and organizes it in three phases: activation and notification, recovery, and reconstitution, which means returning to normal operations. In NIST's own vocabulary a disaster recovery plan is narrower: a site-focused plan for moving systems to an alternate location after a major, usually physical disruption, such as losing the office. Most small businesses use the term for both, and the template below covers both cases. NIST's guide also lists the appendices a plan usually carries, such as contact lists, vendor contacts, detailed recovery procedures, equipment lists and testing procedures.

Two numbers drive every plan. The recovery time objective (RTO) is how long a system can stay down before the impact becomes unacceptable. The recovery point objective (RPO) is the point in time you can recover data to, which sets how much recent work you could lose. NIST defines both, and our BCDR glossary entry shows how they fit with continuity planning.

How do you write an IT disaster recovery plan, step by step?

NIST SP 800-34 sets out a seven-step contingency planning process. Scaled down for a small business, it looks like this:

1. Write a one-page policy. Name the plan owner, the systems and locations it covers, and how often it is reviewed and tested. NIST puts this policy first because it gives the plan its authority.
2. Run a business impact analysis. For each business process, list the systems it needs and how long it can go without them. NIST's guide includes a template for this step.
3. Put preventive controls in place. Backup power, patching, MFA and endpoint protection make many disruptions smaller or shorter.
4. Choose a recovery strategy for each system. Restore from backup, replicate to a second site or the cloud, or fail over, depending on its RTO and RPO.
5. Write the plan with the nine-section template below.
6. Test it and train the people in it. Testing shows the recovery works; training makes sure the people named in the plan know their part.
7. Maintain it. Update the plan after significant changes and record each update in the change log.

What should a disaster recovery plan template include?

Copy this table into a document and fill in each row. Print it as well: CISA tells organizations to keep a hard copy and an offline version of their incident response plan, and the same logic applies here, because the network may be down when you need the plan.

Keep the body of the plan short enough to use under stress. NIST's guide puts the details that do not belong in the main body, such as full procedures and equipment lists, in appendices.

What does a filled-in IT disaster recovery plan look like?

Here is a sample plan: an illustrative planning example for a fictional 25-person professional services office. It is not a client, nothing in it describes a real result, and the targets are placeholders to replace with numbers your own system owners agree.

The rest of the example plan, in brief:

• Scope: every system above, at the office and on remote laptops, for ransomware, hardware failure, a cloud outage or loss of the office. The operations director owns the plan and reviews it each January and after any major change.
• Roles: the managing partner declares a disaster, the IT provider leads technical recovery, the operations director handles staff and client communication, and the controller approves emergency spending.
• Communications: staff hear first by text from a phone list printed in the plan. Clients hear from the operations director by phone or a prepared email. The cyber insurer's claims line and policy number sit at the top of the contact list.
• Testing: a monthly file and mailbox restore, a quarterly restore of the file server to an isolated network, and a yearly tabletop exercise.
• Change log: one row per change, with the date, what changed and who approved it.

How do you set RTO and RPO for each system?

Start from the business process, not the server. Ask each process owner how long they can work without the system before money, clients or compliance suffer, and how much re-entry of lost work they can tolerate. NIST describes the maximum tolerable downtime as the total outage a business process can accept, and says the RTO normally has to be shorter so recovery finishes in time. Shorter targets cost more, because they need replication or failover instead of a restore. Our guide to disaster recovery cost for small business shows how the targets move the price.

Where should backups live?

At least one copy has to be out of an attacker's reach. CISA's #StopRansomware Guide tells organizations to keep offline, encrypted backups of critical data and to test their availability and integrity in a disaster recovery scenario, because many ransomware variants look for accessible backups to delete or encrypt. An immutable backup serves the same purpose in the cloud. Cloud services need their own backup too: Microsoft keeps Microsoft 365 running, but recovering your deleted or encrypted data is your job, as we explain in Microsoft 365 backup and shared responsibility. The 3-2-1 backup rule is a simple way to decide how many copies to keep and where.

IT disaster recovery plan checklist: is your plan finished?

Before you call the plan done, check each line:

• Every system in the inventory has an owner, a tier, an RTO and an RPO that the owner has signed off on.
• At least one backup copy is offline or immutable, and Microsoft 365 data has its own backup.
• Each recovery procedure says where credentials, license keys and installers are kept, and someone other than the usual administrator has followed it.
• Emergency administrator accounts work, with their credentials stored offline.
• Contact lists for staff, vendors, the insurer and counsel exist on paper and outside company systems.
• The network is covered: firewall and switch configurations backed up, internet circuit IDs and provider numbers listed, a current network diagram, and a plan for losing the main internet connection.
• Cloud workloads are covered. Servers in Azure, for example, can be replicated to another region with Azure Site Recovery, and each software-as-a-service application has written recovery steps.
• The ransomware scenario is written down: who isolates devices, which backups are trusted, and who calls the insurer and counsel. It points to your incident response plan.
• A restore test or exercise has happened in the last year, with results and fixes recorded.
• The plan shows its last review date, and the change log records the latest change.

How often should you update and test the plan?

NIST says to review the plan at a frequency the organization sets and whenever significant changes occur, with contact lists reviewed more often. Tie updates to change management, so a new server, a migration or a new application triggers an edit and a test. Our guide to testing a disaster recovery plan covers the five test types and what to record, and the backup and disaster recovery FAQ answers the questions owners ask most. If storms are your main risk, add our hurricane season IT checklist.

How does NetSys build recovery plans?

We sort systems into tiers with the person who owns each process and write the agreed RTO and RPO into the plan. We keep offline and immutable copies, add failover where downtime costs most, and prove the plan with scheduled restore tests, recording the date, the scope, what restored and the measured time. A time measured in one test is evidence for that system, not a promise for every outage, so results feed the next fix and the next test.

Frequently asked questions

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

A disaster recovery plan restores technology: the systems, the data and the order they come back in. A business continuity plan keeps the business working while that happens: where people work, how they reach customers and which processes run by hand. Write both, and have each one point to the other. Our business continuity vs disaster recovery guide compares the two in detail.

Do you need disaster recovery plan software?

Not to write the plan. A document that is also kept in print and offline does the job, and the template above is enough for most small businesses. Software matters for running the recovery: backup, replication and failover tools carry out the steps the plan describes, and many of them can run test restores and keep a record of each one.

How does NetSys start a disaster recovery plan with a new client?

With an assessment of the current environment and a business impact review, so each system gets an owner, a recovery order and an RTO and RPO the owner agrees. Then we document the recovery procedures and the testing schedule, put backups and any failover in place, and run the first scheduled restore tests. The plan, the results and the fixes go to the plan owner, month to month.

What affects the cost of a disaster recovery plan?

Writing the plan is the smaller part. The cost follows the recovery design: how many systems need failover instead of a restore, how much data you keep and for how long, how short the recovery targets are, cloud replica and storage costs, and how often you test. Our guide to disaster recovery cost for small business shows how each one moves the price.

Who handles support and escalations during a disaster?

The plan names them: the person who declares a disaster, the technical recovery lead, the person who speaks to staff and clients, and the person who approves spending. For NetSys clients, the help desk is staffed seven days a week from 4 a.m. to 11 p.m. Eastern, and emergency service is available around the clock, so a disaster can be reported and escalated at any hour while your named decision makers keep their roles.

How long should an IT disaster recovery plan be?

Long enough to recover each critical system without the person who built it, and short enough to use under stress. Keep the main body to decisions, roles and the order of recovery, and move detailed procedures, vendor lists and equipment lists into appendices, as NIST's guide does.

Who should own the disaster recovery plan?

A named person in the business, usually the owner or the head of operations, with the IT provider keeping the technical sections current. Owning the plan means scheduling reviews and tests and signing off on the results, not doing every task.

Do small businesses need a written disaster recovery plan?

Yes, if an outage would cost money or clients. Cyber insurers ask about backups and recovery on their applications, and some regulations expect a plan: the HIPAA Security Rule, for example, requires a data backup plan and a disaster recovery plan for systems that hold electronic patient information (45 CFR 164.308(a)(7)).

Sources and further reading

• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: the seven-step planning process, plan types and phases, appendices, RTO, RPO and maximum tolerable downtime, and plan maintenance, checked October 2026.
• CISA #StopRansomware Guide (September 2023): offline, encrypted backups, backup testing, and hard copies of response plans, checked October 2026.
• Microsoft Learn: About Azure Site Recovery: replication of Azure virtual machines between regions and of on-premises servers to Azure, checked October 2026.
• 45 CFR 164.308(a)(7): the HIPAA contingency plan standard, eCFR, checked October 2026.