Disaster Recovery Plan Template

A disaster recovery plan template helps you write down exactly how your team will restore systems and data after a major failure, before you are in the middle of one. Use this free disaster recovery plan template to set recovery targets, assign roles, and document step-by-step recovery procedures, then keep the plan somewhere your team can still reach when things go wrong.

Use this template in HelpDocsDownload for Word

AI prompt

Copy prompt

Open in

ClaudeChatGPTHelpDocs AI Copies a version with formatting tips

I need to write a Disaster Recovery Plan. Act as an expert technical writer and draft one for me.

Use this structure, keeping each section clear, concise, and genuinely useful to the reader:

1. Plan overview
2. Scope
3. Disaster scenarios
4. Roles and contacts
5. Critical systems and recovery objectives
6. Backup and replication
7. Activation criteria
8. Recovery procedures
9. Communication plan
10. Testing and maintenance

Before you begin, ask me for the details you need: the product, team, or audience this is for, and anything specific I should include. Then write the full Disaster Recovery Plan in clean, well-formatted Markdown.

Connected HelpDocs over MCP? Add "save this as an unpublished HelpDocs article" to the prompt and the draft lands in your knowledge base, ready to review.

## The disaster recovery plan template

### 1. Plan overview

Spell out what your plan covers, name the owner, and note when it was last reviewed and tested. Then add a single paragraph on the purpose: bringing critical systems and data back within agreed targets once a major disruption strikes.

### 2. Scope

Spell out the systems, sites, and services this plan reaches, and name anything you've intentionally left out. Link to the separate plans that take care of those excluded areas.

### 3. Disaster scenarios

Here are some of the events this plan is built to handle:

- **Infrastructure failure:** when a data center, cloud region, or a critical piece of hardware goes down
- **Cyberattack:** ransomware, a data breach, or someone taking over your accounts
- **Data loss or corruption:** deleting things by mistake or a migration that goes wrong
- **Third-party outage:** when a provider you rely on stops being available
- **Physical event:** fire, flooding, a power cut, or being locked out of your office

### 4. Roles and contacts

Decide who calls a disaster, who drives recovery, and who keeps people informed. Every role needs a backup, and contact info should work even when your systems are down.

| Role | Primary | Backup | Contact method |
| --- | --- | --- | --- |
| Recovery lead | TODO | TODO | TODO |
| Technical lead | TODO | TODO | TODO |
| Communications lead | TODO | TODO | TODO |

### 5. Critical systems and recovery objectives

A prioritized list of the systems you have to bring back, showing the recovery targets that apply to each one.

| System | Priority | Owner | RTO | RPO | Dependencies |
| --- | --- | --- | --- | --- | --- |
| TODO | TODO | TODO | TODO | TODO | TODO |

### 6. Backup and replication

Document which data gets backed up, on what schedule, where the copies live, and how long you keep them. Also explain how those copies stay safe from the same disaster that could bring down production, and how you prove a restore actually works.

### 7. Activation criteria

Decide exactly what conditions trigger this plan, and write them down. Make sure everyone knows who's got the authority to activate it, and describe how the rest of the team gets notified. Keep the distinction clear between a routine incident your normal on-call handles and a disaster that calls for this plan.

### 8. Recovery procedures

Lay out numbered procedures for getting each critical system back online, working in order of priority. Each system needs its own sequence of numbered steps.

1. **Evaluate.** Figure out how big the failure is and which systems are caught up in it.
2. **Stop the spread.** Cut off any further damage, say by quarantining compromised systems.
3. **Recover.** Bring the system back up from a backup or switch over to the standby environment.
4. **Confirm.** Make sure it works and the data is intact before you let users back in.
5. **Back to business.** Once it's safe, migrate back onto the primary infrastructure and close out the plan.

### 9. Communication plan

Decide now who needs to hear about the incident (staff, customers, partners, and any regulators you're required to notify), plus when and through which channel each group gets the news. Write your message templates ahead of time, and jot down which channels will still reach people if your usual tools are down.

### 10. Testing and maintenance

You'll see how and when you test the plan, who approves the results, and when the next review is due.

| Test date | Test type | Systems covered | Result | Actions |
| --- | --- | --- | --- | --- |
| TODO | TODO | TODO | TODO | TODO |

The disaster recovery plan template

Start a new article from this structure, then swap out the sample guidance beneath each heading for the specifics of your own environment. Keep the writing clear enough that a teammate who never touched these systems could still carry out the plan, even in the middle of a crisis.

TemplateCopy as MarkdownDownload for Word

1. Plan overview

Spell out what your plan covers, name the owner, and note when it was last reviewed and tested. Then add a single paragraph on the purpose: bringing critical systems and data back within agreed targets once a major disruption strikes.

2. Scope

Spell out the systems, sites, and services this plan reaches, and name anything you’ve intentionally left out. Link to the separate plans that take care of those excluded areas.

3. Disaster scenarios

Here are some of the events this plan is built to handle:

• Infrastructure failure: when a data center, cloud region, or a critical piece of hardware goes down
• Cyberattack: ransomware, a data breach, or someone taking over your accounts
• Data loss or corruption: deleting things by mistake or a migration that goes wrong
• Third-party outage: when a provider you rely on stops being available
• Physical event: fire, flooding, a power cut, or being locked out of your office

4. Roles and contacts

Decide who calls a disaster, who drives recovery, and who keeps people informed. Every role needs a backup, and contact info should work even when your systems are down.

Role	Primary	Backup	Contact method
Recovery lead	TODO	TODO	TODO
Technical lead	TODO	TODO	TODO
Communications lead	TODO	TODO	TODO

5. Critical systems and recovery objectives

A prioritized list of the systems you have to bring back, showing the recovery targets that apply to each one.

System	Priority	Owner	RTO	RPO	Dependencies
TODO	TODO	TODO	TODO	TODO	TODO

6. Backup and replication

Document which data gets backed up, on what schedule, where the copies live, and how long you keep them. Also explain how those copies stay safe from the same disaster that could bring down production, and how you prove a restore actually works.

7. Activation criteria

Decide exactly what conditions trigger this plan, and write them down. Make sure everyone knows who’s got the authority to activate it, and describe how the rest of the team gets notified. Keep the distinction clear between a routine incident your normal on-call handles and a disaster that calls for this plan.

8. Recovery procedures

Lay out numbered procedures for getting each critical system back online, working in order of priority. Each system needs its own sequence of numbered steps.

1. Evaluate. Figure out how big the failure is and which systems are caught up in it.
2. Stop the spread. Cut off any further damage, say by quarantining compromised systems.
3. Recover. Bring the system back up from a backup or switch over to the standby environment.
4. Confirm. Make sure it works and the data is intact before you let users back in.
5. Back to business. Once it’s safe, migrate back onto the primary infrastructure and close out the plan.

9. Communication plan

Decide now who needs to hear about the incident (staff, customers, partners, and any regulators you’re required to notify), plus when and through which channel each group gets the news. Write your message templates ahead of time, and jot down which channels will still reach people if your usual tools are down.

10. Testing and maintenance

You’ll see how and when you test the plan, who approves the results, and when the next review is due.

Test date	Test type	Systems covered	Result	Actions
TODO	TODO	TODO	TODO	TODO

Tip

Your recovery plan does you no good if nobody can pull it up at 3am. Start a free HelpDocs trial and tuck your plan, runbooks, and contacts into one spot the whole team can search.

How to fill in this disaster recovery plan template

Write this plan for the worst day of the year, because that’s when you’ll find out if it holds up:

• Put the business impact first. Decide which systems would hurt the most if they went offline, and how long you could live without them. That ordering shapes everything else in the document.
• Write steps that anyone could follow. The engineer who built something may be off site when it breaks. Include the commands, the locations, and screenshots so nobody has to guess.
• Store contacts away from your own systems. When email and chat go down, a contact list living inside them is worthless.
• Verify that your backups actually restore. A backup you have never pulled back up is wishful thinking, not a plan. Run restore tests on a schedule and log what you find.
• Refresh the plan after every change. New systems, new vendors, and new teammates all age a document fast. Build plan reviews into your change process.
• Take lessons from every test and incident. Push what went wrong back into the plan, and document it in an incident report.

For the bigger picture of keeping your whole business going, use this alongside our business continuity plan template.