A disaster recovery plan template is a fill-in document that records who can declare a disaster, which systems come back in what order, how fast (the recovery time objective, or RTO) and to what point in time (the recovery point objective, or RPO), and how the plan is tested. The outline below follows NIST SP 800-34 Rev. 1, whose templates split recovery into three phases (activation and notification, recovery, reconstitution), and maps its sections to NIST CSF 2.0, CISA guidance and FEMA’s Ready.gov where they apply. As of October 2026, Rev. 1 (updated November 2010) is the latest revision on NIST’s publication page, which offers free templates for low-, moderate- and high-impact systems and a business impact analysis (BIA).
Related backup and resilience coverage is listed in Enterprise Techie’s topic index.
In this guide
Key facts
| Item | Detail |
|---|---|
| Base framework | NIST SP 800-34 Rev. 1 (May 2010, updated November 11, 2010) |
| Free NIST templates | BIA; contingency plans for low-, moderate- and high-impact systems |
| Plan phases | Activation and notification; recovery; reconstitution |
| Starting point | BIA: maximum tolerable downtime, RTO, RPO, recovery priorities |
| Testing floor | At least annually (NIST templates; CISA CPG 2.0) |
| Review | Organization-defined frequency and after significant change |
| Cyber attacks | Separate runbook, referenced from the DR plan |
What NIST means by a DR plan
SP 800-34 distinguishes two plans. Its disaster recovery plan (DRP) is site-specific: it recovers one or more systems at an alternate facility after a major disruption. Its information system contingency plan (ISCP) assesses and recovers one system, at its current location or an alternate site; once a DRP has moved operations, each system runs its own ISCP. The guide lists the cyber incident response plan as a separate plan type.
The template below combines both: plan-wide sections plus a repeatable per-system block modeled on the ISCP.
How to fill it in: start with a business impact analysis
SP 800-34’s seven-step contingency planning process puts the BIA second, right after the policy statement. NIST’s BIA template has three steps: determine business processes and recovery criticality, identify resource requirements, and set recovery priorities. It yields three values per system:
- Maximum tolerable downtime (MTD): the total outage the system owner or authorizing official will accept for the business process.
- RTO: the longest a system resource can be down before the impact becomes unacceptable. NIST says it must normally be shorter than the MTD, since reprocessing time also counts.
- RPO: the point in time to which data can be recovered from the latest backup. It sits outside the MTD and measures tolerable data loss.
Ready.gov adds that an IT resource’s recovery time should match the RTO of the business function that depends on it, and its BIA guidance suggests a questionnaire for the managers who run each process. If the RTO can’t be met yet and the MTD is inflexible, SP 800-34 says to open a plan of action and milestones documenting the gap and its mitigation.
The template, section by section
Copy the headings and replace every bracketed field; brackets mark placeholders, not recommended values.
1. Plan approval and version history
- Approval statement signed by [designated authority, name and title]: the plan is complete, was last tested on [date] and will be tested at least [frequency].
- Version table: [version], [date], [change summary], [author], [approver].
- Distribution list: [who holds printed and offline copies, and where].
2. Scope, objectives and assumptions
- Covered: [systems, sites, cloud accounts and SaaS applications]. Excluded: [end-user devices, outages shorter than the RTO].
- Objective: restore [tier 1 services] within [RTO] at [primary or alternate site].
- Assumptions: [backups intact offsite], [alternate site available], [trained staff reachable].
- Related plans: [business continuity plan], [crisis communications plan], [incident response plan and ransomware runbook].
3. Roles, contacts and decision authority
- Designated authority who declares a disaster: [name, title]. Successor: [name, title].
- Activation criteria: [outage expected to exceed RTO], [facility unavailable], [other].
- Recovery coordinator, technical leads and system owners: [names, roles, alternates].
- Call tree: [caller] notifies [names] by [primary method], then [alternate method]; if someone can’t be reached within [time], [escalation step].
- Per person: [office phone], [mobile phone], [out-of-band channel].
- Vendors: [vendor], [support line], [contract number], [contracted response time].
4. System inventory and tiers
- Per system: [name], [business process supported], [owner], [platform and version], [site or cloud region], [tier], [recovery priority rank].
- Rebuild materials: [installation media], [license keys], [configuration backups], [golden images or infrastructure-as-code templates].
5. RTO and RPO per system
| System | Tier | MTD | RTO | RPO | Recovery method | Last tested |
|---|---|---|---|---|---|---|
| [System name] | [Tier] | [From BIA] | [From BIA] | [From BIA] | [Restore, failover or rebuild] | [Date, result] |
Enterprise Techie’s RTO and RPO benchmarks map recovery technologies to tiers.
6. Dependencies
- Identity: [directory, identity provider, MFA service, privileged access tooling].
- Name resolution: [internal DNS], [external DNS provider], [registrar account access].
- Network: [core switching], [firewalls], [WAN or VPN], [load balancers], [certificates].
- Interconnections: [upstream and downstream systems], [data exchanged], [contact].
- Restart sequence: [identity], then [DNS and network], then [databases], then [applications].
- Diagrams: [location of current network and system diagrams, stored outside production].
7. Backup and replication
- Per system: [backup tool], [schedule], [retention], [copy locations], [offline or immutable copy: yes or no], [replication target and frequency].
- Restore source order: [primary copy], [secondary copy], [offline copy].
- Who can retrieve offsite or offline copies: [names].
- Last restore test: [date, measured time against RTO].
Related: the 3-2-1-1-0 backup rule and Microsoft 365 backup options.
8. Alternate site
- Type: [cold, warm, hot or mirrored site], [cloud region] or [DRaaS provider].
- Location: [city or region], [distance from primary], [shared hazards with primary: yes or no].
- Access: [who may travel or log in], [how], [where access credentials are held].
- Agreements: [SLA], [setup time], [alternate telecommunications capacity].
Contract terms for provider-run sites are covered in DRaaS pricing.
9. Recovery procedures per system
- Activation and notification: [outage assessment steps], [who receives the results].
- Recovery sequence: [confirm recovery location], [gather resources], [retrieve backups and media], [rebuild platform], [restore system and data].
- Detailed steps: [link to step-by-step runbook], written for a skilled technician who doesn’t know this system.
- Workarounds: [manual or alternate processing], [how data created during the outage is reconciled].
- Reconstitution: [data validation test], [functionality test], [who declares recovery], [user notice], [fresh full backup], [plan deactivation].
10. Communications plan
- Audiences: [employees], [customers], [suppliers], [management], [regulators].
- Spokesperson: [name, title]. Approver for external statements: [role].
- Pre-approved message templates: [location reachable when primary systems are down].
- Status updates: [cadence] to [owners and users] via [channel]; leadership escalation when [conditions].
11. Testing and maintenance schedule
- Test calendar: [tabletop dates], [functional test dates], [failover test dates], [owner], [success criteria tied to RTO and RPO].
- Plan review: every [frequency] and after [system, staff or vendor changes]. Contact lists: every [shorter frequency].
- After-action reports: [location], with each fix’s [owner] and [due date].
SP 800-34 scales exercises with impact: a tabletop for low-impact systems, a functional exercise with recovery from backup media for moderate, and a full-scale exercise with failover to the alternate location for high. The DR testing cadence guide and backup restore testing guide cover frequency by tier.
12. Appendices
[Personnel contacts], [vendor contacts], [BIA results], [diagrams], [hardware and software inventory], [interconnections], [detailed procedures], [validation test plan], [record of changes].
Where each section comes from
| Template section | Source framework | What it contributes |
|---|---|---|
| 1. Approval and version history | SP 800-34 templates | Signed approval; record of changes |
| 2. Scope and assumptions | SP 800-34 templates | RTO-bound scope; assumptions |
| 3. Roles and decision authority | SP 800-34; CSF 2.0 GV.RR-02 | One designated authority and a successor; call tree |
| 4. Inventory and tiers | SP 800-34; CSF 2.0 ID.AM-05; CISA CPG 2.0 goal 2.A; Ready.gov | Inventory; priority by criticality |
| 5. RTO and RPO | SP 800-34 BIA; Ready.gov | MTD, RTO and RPO |
| 6. Dependencies | SP 800-34; CISA CPG 2.0 goal 2.E; UK NCSC | Interconnections, topology, restart order |
| 7. Backup and replication | SP 800-34; CSF 2.0 PR.DS-11; CISA CPG 2.0 goal 3.O | Frequency, offsite copies, tested backups |
| 8. Alternate site | SP 800-34 | Site types; distance from the primary site’s hazards |
| 9. Recovery procedures | SP 800-34; CSF 2.0 RC.RP | Three phases, validation, recovery declaration |
| 10. Communications | Ready.gov; CSF 2.0 RC.CO-03 and RC.CO-04 | Audiences, spokesperson, pre-scripted messages |
| 11. Testing and maintenance | SP 800-34; CISA CPG 2.0 goal 3.O | Exercise type by impact level; annual floor |
Cyber attacks: link to the ransomware runbook
Plans written for fires, floods and failed hardware assume backups and identity systems can be trusted; a cyber attack breaks that assumption. Put attack procedures in a dedicated runbook, such as Enterprise Techie’s ransomware recovery plan, and keep three things in the DR plan:
- The handoff. Under CSF 2.0 outcome RC.RP-01, the recovery portion of the incident response plan is executed once initiated from the incident response process. Name who declares a suspected cyber incident and who releases systems for restore: [incident commander], [security lead].
- Clean restore points. RC.RP-03 calls for verifying backup integrity before restoration, and CISA’s CPG 2.0 says to check restoration assets for indicators of compromise before use. Record per system: [scan method], [approver].
- Offline access. CISA’s #StopRansomware Guide asks for a hard copy and an offline version of the incident response plan. Do the same for the DR plan and its contacts.
Evidence, reporting, rebuild order and payment questions stay in the runbook; vault options are in the cyber recovery vault comparison.
Common mistakes
- Procedures only the author can follow. NIST’s templates say an appropriately skilled technician should be able to recover the system without intimate system knowledge.
- The only copy sits on the network it protects. SP 800-34 says to keep a copy at the alternate site and with the backup media; the UK NCSC says to store recovery documentation separately from production systems.
- Missing dependencies. An application restored before identity and DNS can’t be used. The NCSC names identity services, networking, storage and cloud connectivity as shared infrastructure most services rely on.
- Stale contacts. SP 800-34 says contact lists need more frequent review than the rest of the plan.
- Forgotten workaround data. The NCSC notes that manual processes during an outage create new data, which must be validated and merged with restored data.
Bottom line
- Run the BIA first; every RTO and RPO should trace back to it.
- Name one person who declares a disaster, plus a successor.
- Write per-system procedures, dependencies first, that a skilled stranger could follow.
- Keep offline copies, and send cyber incidents to the ransomware runbook.
- Test at least yearly and record every version.
Frequently asked questions
What should a disaster recovery plan include?
Scope, roles with one designated authority, a call tree, a tiered system inventory, RTO and RPO per system, dependencies, backup and alternate site details, recovery procedures, a communications plan, a test schedule and a signed version history. Most of these sections map to the templates in NIST SP 800-34 Rev. 1.
Is there a free disaster recovery plan template from NIST?
Yes. The SP 800-34 Rev. 1 page offers Word templates for low-, moderate- and high-impact systems and a BIA template. They target federal systems, and NIST notes they may be customized and adapted.
What is the difference between a disaster recovery plan and a business continuity plan?
SP 800-34 describes the business continuity plan as sustaining business processes during and after a disruption, while the DR plan restores information systems. Ready.gov says the IT disaster recovery plan should be developed with the business continuity plan and documented as part of it.
How often should a DR plan be tested and updated?
NIST’s templates attest to testing at least annually, and CISA’s CPG 2.0 says to test backups and recovery no less than once per year. SP 800-34 calls for review at an organization-defined frequency and after significant changes, with contact lists reviewed more often.
Sources
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (publication page and templates)
- NIST SP 800-34 Rev. 1 (PDF)
- NIST contingency plan template, moderate-impact system (Word)
- NIST business impact analysis template (Word)
- NIST Cybersecurity Framework (CSF) 2.0 (PDF)
- CISA Cybersecurity Performance Goals 2.0
- CISA, FBI, NSA and MS-ISAC: #StopRansomware Guide
- Ready.gov: IT Disaster Recovery Plan
- Ready.gov: Business Impact Analysis
- Ready.gov: Crisis Communications Plans
- UK NCSC: Prepare your technical recovery capability
Last checked: October 2026. Guidance changes; check each source before you rely on it.
Buying? Start from RFPhub’s free DRaaS RFP template.