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

An IT disaster recovery plan template needs 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 is that template as a table, followed by a filled-in planning example for a small office.

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, and the two plans should point at each other.

What is an IT disaster recovery plan?

It is the written procedure for restoring the systems your business runs on after ransomware, hardware failure, a cloud outage or damage to the office. 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. 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.

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 ransomware 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.

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.

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: plan phases and 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.
• 45 CFR 164.308(a)(7): the HIPAA contingency plan standard, eCFR, checked October 2026.