IT Disaster Recovery Plan Template (With RTO/RPO and Site Comparison)

An IT disaster recovery plan template needs four things to actually work: a list of your critical systems with RTO and RPO assigned to each, a chosen recovery method (hot, warm, or cold site), the step-by-step restore order, and a tested backup behind all of it. Below is a copyable template with each section filled in as an example, plus the reasoning behind hot, warm, and cold site choices and how the whole thing maps to NIST SP 800-34.

This is the IT half of disaster planning specifically. If you’re looking for how the rest of the business keeps operating while systems are down, that’s a separate document. See our business continuity plan guide for the communication tree, alternate work locations, and vendor list that sits around this plan.

Disaster Recovery Plan vs. Business Continuity Plan

A disaster recovery (DR) plan and a business continuity plan (BCP) get used interchangeably in a lot of sales pitches, and that’s where small businesses lose the thread.

DR answers one question: how do we get systems, servers, and data back online? It’s technical. It lives in backup jobs, replication settings, and restore procedures.

BCP answers a bigger question: how does the business keep running while that happens? It includes DR, but it also covers where people work, how customers get notified, and who’s authorized to make decisions during the outage.

Put plainly, DR is a chapter inside BCP. You can have a flawless DR plan and still miss payroll if nobody planned for where the accounting team works that week. This article is about that one chapter, in enough detail that you can actually build it.

RTO and RPO, Briefly

Every system in your DR plan needs two numbers attached to it.

RTO (Recovery Time Objective) is how long the system can stay down before the damage gets serious. A four-hour RTO means the business has decided four hours of downtime is survivable, and past that, it starts to hurt.

RPO (Recovery Point Objective) is how much data loss is acceptable, measured in time. A 24-hour RPO means backups run once a day, so a failure right before the next backup costs up to a day of work. A 15-minute RPO means backups (or replication) need to run far more often, which costs more to maintain.

Not every system gets the same numbers. A dispatch system might need a two-hour RTO. Archived project photos can wait a week. That’s the point of assigning them individually instead of picking one number for everything.

Our business continuity guide covers RTO and RPO from the whole-business angle, with a Hampton Roads example. Here, the numbers are just inputs into the template below.

Hot Site vs. Warm Site vs. Cold Site: Which Recovery Method Fits

This is the decision that drives everything else in a DR plan: where do your systems come back online, and how ready is that location before disaster hits?

Hot site. A fully running, continuously synced duplicate of your production environment. It can take over in minutes because it’s already on, already updated, and already holds current data. Hot sites cost the most to maintain because you’re paying to keep a second environment live around the clock, even when it’s doing nothing but waiting.

Warm site. Infrastructure exists (servers, network, sometimes software already installed) but data isn’t continuously synced and services aren’t running live. Failover takes longer, typically hours, because someone has to sync data, start services, and verify before the site is usable. Cost and recovery time both land in the middle.

Cold site. Bare space or bare infrastructure with nothing live. No pre-installed systems, no synced data. Recovery means building the environment and restoring from backup, which can take days. It’s the cheapest option to maintain month to month, and the most expensive option in the hours it takes to actually recover.

Most small businesses don’t pick one tier for the whole company. A dispatch or payment system might justify a warm site. Marketing files and archived records are usually fine cold. The RTO/RPO numbers from the section above should decide the tier, not the other way around, because paying for a hot site on a system with a one-week RTO is money that could go toward the systems that actually need it.

For businesses on the Virginia coast, site selection has a geographic angle too. A cold or warm backup location outside the storm surge and flood zone matters more here than it does inland, since the failure mode that takes out your primary systems (extended power loss from a hurricane or nor’easter) can just as easily reach a nearby backup site if it’s in the same flood plain.

The IT Disaster Recovery Plan Template

Copy this into your own document. The bracketed items are where you fill in your own information. The rest is structure that should stay as-is.

This is a starting point, not a finished plan. Filling it out gets you a real first draft; testing it is what turns that draft into something you can trust.

IT DISASTER RECOVERY PLAN

1. PLAN OWNER AND CONTACTS
   Plan owner: [name, title, phone]
   Backup plan owner: [name, title, phone]
   IT provider / internal IT lead: [name, phone, after-hours number]
   Last reviewed: [date]
   Next scheduled review: [date]

2. CRITICAL SYSTEMS INVENTORY
   For each system, record:
   - System name: [example: line-of-business software]
   - Business function it supports: [example: order processing]
   - RTO: [example: 4 hours]
   - RPO: [example: 1 hour]
   - Recovery method: [hot / warm / cold]
   - Backup location and frequency: [example: cloud, every 15 minutes]
   - Last successful restore test: [date]
   - Dependencies: [example: requires internet, requires vendor API]

   Repeat this block for every critical system. Most small businesses have
   between 5 and 15 systems that belong here.

3. RECOVERY SITE / METHOD DETAILS
   Primary recovery method: [hot / warm / cold]
   Recovery site location or provider: [name, address or region]
   Access credentials location: [where stored, who has access]
   Estimated time to operational: [based on hot/warm/cold tier above]
   Physical distance from primary site: [relevant for regional outages]

4. RESTORE SEQUENCE
   List systems in the order they get restored, not alphabetically,
   by actual dependency and business priority.
   1. [example: network/internet connectivity]
   2. [example: authentication/identity system]
   3. [example: line-of-business software]
   4. [example: email]
   5. [example: file storage]
   Continue until every system from section 2 has a position in this list.

5. DECLARATION CRITERIA
   Who decides this is a "disaster" and the DR plan activates: [name/role]
   What triggers activation: [example: primary site unreachable for 2+ hours,
   confirmed data loss/corruption, confirmed ransomware]
   What does NOT trigger full activation: [example: single-user outage,
   ISP issue under 30 minutes]

6. COMMUNICATION DURING RECOVERY
   Who tells staff systems are down and what to do: [name/role]
   Who tells customers/vendors if recovery affects them: [name/role]
   Status update channel (not dependent on primary systems): [example: SMS
   group, dedicated line]

7. TESTING LOG
   Date | Test type (restore / full failover / tabletop) | Result | Issues found
   [date] | [type] | [pass/fail] | [notes]

8. NIST SP 800-34 CROSSWALK (for compliance-driven plans)
   Business impact analysis completed: [date]
   Recovery strategy selected and documented: [yes/no, date]
   Plan developed and distributed: [yes/no, date]
   Testing, training, and exercise completed: [date, next due]
   Plan maintenance schedule: [frequency]

That eighth section matters if you’re a government contractor or operate under a framework that references NIST’s contingency planning process. It’s covered next.

How This Maps to NIST SP 800-34

NIST Special Publication 800-34 Revision 1, “Contingency Planning Guide for Federal Information Systems,” lays out a seven-step process for building a recovery plan. It was written for federal systems, but the structure holds up for any business, and it’s the reference point a lot of compliance frameworks build from.

The seven steps, in short: develop a contingency planning policy, conduct a business impact analysis, identify preventive controls, create recovery strategies, develop the actual contingency plan, test the plan through training and exercises, and maintain the plan over time.

The template above covers the plan-development and testing steps directly. The business impact analysis, deciding what’s actually critical and what the impact of losing it looks like, is the step most small businesses skip, and it’s the one that determines whether your RTO and RPO numbers in section 2 mean anything or are just guesses.

You don’t need federal-grade documentation to benefit from this structure. But if you’re pursuing CMMC or responding to a compliance questionnaire, assessors and auditors are often looking for evidence that traces back to exactly this process: a documented impact analysis, a tested plan, and a maintenance schedule, not just a backup that runs.

Testing Cadence

A DR plan that’s written once and never tested is a document, not a plan. Three cadences cover most small businesses:

Quarterly: Test individual backup restores. Pull a file or a database backup and confirm it actually opens and the data is intact. A backup dashboard showing a green checkmark is not the same thing as a restore that works.

Annually: Run a full recovery test. If your plan calls for failing over to a warm or cold site, actually do it, on a schedule where a failed test doesn’t cost you a business day. This is where plans built on paper meet reality, and it’s usually where the gaps show up.

After any major change: New server, new core application, new backup provider, new hosting arrangement. The plan is only accurate as of the last time someone updated it after a change like this.

Where This Plan Fits With Backup and Disaster Recovery Services

A template gets you a documented plan. It doesn’t get you a tested backup, a working failover environment, or someone who notices when a backup job silently stops running. That part is ongoing work, not a document.

Helix Stax builds and manages the technical side of disaster recovery, backup configuration, recovery site setup, and restore testing, as part of Backup & Disaster Recovery engagements. The assessment work that determines where your gaps actually are runs through the CTGA Framework, which looks at controls, technology, growth, and adoption together instead of treating backup as an isolated line item.

If you’d rather start with the checklist version of this before writing a full plan, our Backup and Disaster Recovery Checklist is a shorter, faster starting point. Use it first if you’re not sure where your gaps are; use the template above once you know which systems need a documented plan.

If you want a look at where your current backups and recovery setup actually stand before you commit to writing any of this, start with the free Helix Score assessment. It tells you what’s already in decent shape and what needs work before you invest time building a plan around it.