Disaster recovery plan template
Who decides, what comes back first, and how, written down before you need it. A short plan for small software companies and agencies, covering failed servers, deleted data, ransomware and provider outages. Free, in Word or Markdown.
- Roles
- Who leads, who fixes, who tells people
- Recovery order
- Each system with its RTO and RPO
- Scenarios
- Server loss, bad data, ransomware, provider down
- Checklist
- From declaring it to the review
- Testing
- What to test, how often, and the record
Why a small team needs one
In a real incident there's no time to work out who decides, which system matters most, or where the off-site backup's credentials are. The plan settles those questions in advance, so the hours go on recovery.
It's also what customers, auditors and security questionnaires ask for, and "we'd figure it out" is not an answer they accept.
The eleven sections
| Section | What goes in it |
|---|---|
| 1. Scope | What the plan covers, what it doesn't, and the documents it relies on. |
| 2. Roles | Incident lead, technical lead, communications and decision maker, each with a deputy. |
| 3. Recovery order | Every system in priority order, with its owner, RTO, RPO, backup method and where it recovers to. |
| 4. When to invoke it | The triggers, and who can declare a disaster. |
| 5. Scenarios | A failed server, deleted or corrupted data, ransomware, a provider outage, and a key person away. |
| 6. Recovery checklist | The steps from declaring an incident to booking the review. |
| 7. Communication | Staff, customers, suppliers and the ICO: when, how and who. |
| 8. Emergency access | Password manager, break-glass accounts and backup credentials: where they are, not what they are. |
| 9. Backups | Copies, locations, the immutable copy, and the last restore test for each system. |
| 10. Testing and review | Restore tests, tabletop exercises and failovers, with how often and the results. |
| 11. Contacts | Everyone the plan names, plus the hosting, DNS and registrar support routes. |
Getting it right
Set targets you've tested. An RTO of four hours means a timed restore took less than four hours. The RTO and RPO calculator gives a first estimate.
Plan for ransomware. Attackers go for the backups first. The plan only works if one copy is off-site, immutable, and behind credentials the production servers don't have. The 3-2-1 backup rule is the test.
Keep a copy outside the blast radius. A plan stored only in the account that's just been lost can't be read.
Rehearse it. An hour walking through a scenario as a team finds the missing contact, the expired credential and the step nobody owns.
Questions
What is a disaster recovery plan?
A written plan for getting systems and data back after something serious: a failed server, deleted data, ransomware, or a provider outage. It says who decides, which systems come back first, how, and who is told. For IT systems it is often called an IT disaster recovery plan, or DRP.
What is the difference between disaster recovery and business continuity?
Business continuity covers keeping the whole business going: people, premises, suppliers. Disaster recovery is the IT part of it: getting the systems and data back. A small software company or agency can often start with the disaster recovery plan, because the systems are the business.
What should a disaster recovery plan include?
Roles, the systems in order of recovery with their recovery time and recovery point targets, when to invoke the plan, steps for the likely scenarios, a recovery checklist, who to tell and when, emergency access, the backups, and a testing schedule. This template has all of these.
How often should it be tested?
Restore at least one system every quarter, walk through a scenario as a team every six months, and review the plan and its contacts after any change of staff or supplier. Record each test: it is the evidence ISO 27001 auditors and customers ask for.
Do I need one for ISO 27001 or Cyber Essentials?
ISO 27001 expects planned and tested ICT continuity (control 5.30 in the 2022 version). Cyber Essentials doesn't ask for one, but customers' security questionnaires almost always do.
How long should it be?
Short enough to read in an incident: a few pages. Put the step-by-step detail for each system in its runbook and point to it. There is a free server runbook template for that.
Would your plan survive a test?
The £250 GUARD review checks your backups and recovery, access and alerts, and tells you what would fail first. Book a call to start.