Disaster recovery plan template
An IT disaster recovery (DR) plan sets out how you get your systems and data back after a serious outage: ransomware, a failed server, a flooded comms room or a cloud service going down. This free Word template covers the systems inventory, recovery time and recovery point objectives (RTO and RPO), backups, recovery steps, contacts and testing.
Running a company of 30 to 200 people? Documents like this are now worth money.
It's built for companies of roughly 10 to 250 people running a mix of cloud services and their own equipment, with or without an outsourced IT provider.
What's in the template
IT disaster recovery plan
| Company | |
|---|---|
| Plan owner | e.g. IT manager, or your IT provider's account manager |
| Version and date | |
| Linked business continuity plan | |
| Copies kept | At least one outside your own systems, e.g. printed |
| Last tested |
1. When to invoke this plan
Triggers, e.g. a critical system will be down for longer than its RTO, or ransomware has been found. Who can invoke the plan, and their deputy.
2. Recovery team and contacts
| Role | Name | Phone, including out of hours | Deputy |
|---|---|---|---|
| Plan owner (decides and invokes) | |||
| IT lead or IT provider | |||
| Cloud and software suppliers | |||
| Internet and phone provider | |||
| Cyber insurer |
3. Systems, dependencies and recovery objectives
| System or data | Business process it supports | Depends on | RTO | RPO | Recovery order |
|---|---|---|---|---|---|
| e.g. identity and single sign-on | Logging in to everything | Internet connection | 1 | ||
4. Backups
| What is backed up | Method and tool | How often | Where copies are kept (is one offline or immutable?) | Last test restore |
|---|---|---|---|---|
| Data | ||||
| Applications | ||||
| Identity systems | ||||
| Configuration |
5. Recovery procedure
| Step | Action | Who | Time done |
|---|---|---|---|
| 1 | Assess the outage and decide whether to invoke the plan | ||
| 2 | Alert the recovery team and the business continuity lead | ||
| 3 | Suspected attack: isolate systems, keep the logs, follow the incident response plan | ||
| 4 | Connect backups only to known clean devices, and scan them before restoring | ||
| 5 | Restore and test systems in recovery order | ||
| 6 | Enter data recorded manually during the outage | ||
| 7 | Declare recovery complete and record lessons learned |
6. Testing and maintenance
| Test | How often | Last done | Result and fixes |
|---|---|---|---|
| Restore sample files | |||
| Restore a whole critical system | |||
| Walk through this plan with the team |
7. Recovery log
| Time | Action or decision | By |
|---|---|---|
DR plan or business continuity plan?
A business continuity plan asks how the company keeps its critical work going, whatever the cause. The DR plan answers the narrower technical question: how each system and its data come back, in what order and how fast. Write it after the continuity plan's business impact analysis, which sets the targets. As Ready.gov puts it, the recovery time for an IT resource should match the recovery time objective of the business process that depends on it.
On terms: NIST's contingency planning guide uses "disaster recovery plan" narrowly, for moving systems to an alternate site after a major disruption, and calls the plan for restoring a single system an information system contingency plan. Most companies of this size keep one IT DR plan covering both, as this template does.
How to write a disaster recovery plan
- List every system and dataset, cloud services included, with the process each supports and what it depends on, such as single sign-on or the internet connection.
- Agree an RTO and RPO for each with the people who run those processes, not IT alone (see the FAQ below for what each means).
- Check the backups can meet those targets. NCSC advises keeping copies separate from your network, offline or in a cloud service built for the purpose, using more than one backup solution and location, and backing up applications, identity systems and configuration as well as data.
- Write the recovery steps in order, starting with what everything else depends on, and say how work captured on paper or in spreadsheets during the outage will be entered afterwards.
- Keep the plan, contacts and network details away from the systems they describe, so they're available when those systems are down.
- Test it, and update it after every test and every system change.
Example: a fictional 75-person wholesale distributor
Section 3 for a fictional company using cloud systems plus an accounts server in its own office.
| System | Supports | Depends on | RTO | RPO | Order |
|---|---|---|---|---|---|
| Identity and single sign-on | Every login | Internet | 2 hours | 24 hours | 1 |
| Warehouse management system | Picking, dispatch, stock | Single sign-on, label printers | 4 hours | 15 minutes | 2 |
| Email and shared files | Customer orders and queries | Single sign-on | 8 hours | 24 hours | 3 |
| Accounts and payroll server | Invoicing, payments, payroll | Office server, nightly backup | 8 working hours | 24 hours | 4 |
The test that mattered: restoring the accounts server took 19 hours against its 8-hour target. The company now keeps a standby virtual server at its IT provider and repeats the test every six months.
Common mistakes
- Backups that have never been restored. Until you've restored from one, you don't know it works.
- Backups the attacker can reach. Ransomware goes after connected backup drives and accounts, so keep at least one copy offline or immutable.
- An inventory that stops at the server room, missing cloud apps, identity, the internet connection and the configuration needed to rebuild.
- Recovery targets set by IT alone, without the people who know what an hour of downtime costs.
Frequently asked questions
What's the difference between RTO and RPO?
RTO (recovery time objective) is about downtime: how long a system can be unavailable before the damage is unacceptable. RPO (recovery point objective) is about data: how far back in time your restored data may go, which sets how often you need to back up.
Is a disaster recovery plan a legal requirement?
UK GDPR doesn't use the term, but Article 32 includes, among the security measures to take where appropriate, the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident. A tested DR plan is a practical way to show you can.
How often should we test the plan?
No rule sets a frequency. A workable routine is sample-file restores monthly or quarterly, a full restore of each critical system and a walk-through yearly, and a fresh test after major system changes. NCSC advises testing restoration regularly, starting with business-critical services.
Use the template as a framework rather than professional advice, and have your IT provider check it against your actual systems.