The test of a disaster recovery plan is brutally specific: at 6am, with the server dead or every file encrypted, can a stressed human being open one document and know what to do first, who to call, and in what order to bring things back? Most SME “DR plans” fail that test because they were written to satisfy an insurer’s checkbox: long on policy statements, silent on the actual sequence of recovery.
This template is built for the 6am test. Copy the structure below into a document, fill it in for your business (the filling-in is where the value lives), keep a copy somewhere that survives the disaster, and test it before reality does. It covers IT recovery specifically; the wider question of keeping the business trading during the disruption belongs to your business continuity plan, of which this is the IT annex.
The template
Section 1 — Purpose and activation
Two short paragraphs: what this plan covers, and who can declare a disaster and activate it. Name the roles (with deputies) rather than relying on whoever is nearest. Include the activation criteria in plain terms: total system loss, ransomware, premises loss, extended outage beyond X hours. Ambiguity about whether “this counts” wastes the first hour of every real incident.
Section 2 — Contact tree
The page people actually use. For each: name, role, mobile, out-of-hours contact.
- Internal: incident lead + deputy, management, whoever communicates with staff
- IT provider: support line and escalation contact
- Suppliers that matter in a crisis: ISP, phone provider, key software vendors, landlord/facilities
- External obligations: cyber insurer (policy number here, not in a drawer), broker, and where personal data may be involved, the ICO’s breach line and your legal contact
Print this page. A contact tree that lives only on the dead server is a punchline with a real body count of hours.
Section 3 — Systems inventory and recovery priority
A table of every system your business runs on, each with: what it is, where it lives (on-premises, cloud, vendor-hosted), who supports it, and its recovery priority. Priority does the heavy lifting, so assign it honestly in three tiers:
- Tier 1 — trading stops without it (e.g. order system, phones, email): recover first, measured in hours
- Tier 2 — painful within a day or two (e.g. accounting, shared files): recover second
- Tier 3 — survivable for a week (e.g. archives, internal wikis): recover last
For each Tier 1 and 2 system, record two numbers agreed with management: how long you can afford it down, and how much data you can afford to lose. Those targets (RTO and RPO; our plain-English guide explains them) are what your backup arrangements must actually be able to deliver, which is worth verifying before writing them down as fact.
Section 4 — Backup and restore procedures
For each backup arrangement: what is backed up, how often, where copies live (including the offline or immutable copy that survives ransomware, per the 3-2-1 rule), how to access them when normal logins are gone, and the actual restore steps or where they are documented. Include the last test-restore date and duration; if that line embarrasses you, the plan has found its first action item.
Section 5 — Scenario playbooks
Short, numbered first-response sequences for your four or five likeliest disasters. Each fits on half a page: immediate actions, what not to do, escalation point. At minimum:
- Ransomware / cyber attack: isolate affected machines (pull network, do not power off), preserve evidence, call the IT provider and insurer before touching anything, activate the incident response plan alongside this one
- Server or storage failure: the first-30-minutes triage, then restore per Section 4 in Section 3’s priority order
- Premises loss (fire, flood, no access): where people work from, how phones divert, which Tier 1 systems are cloud-reachable already
- Extended power or internet outage: failover connectivity if any, hotspot fallback, the point at which you invoke premises-loss arrangements
Section 6 — Communication during recovery
Who tells staff what is happening and how (a channel that does not depend on the dead systems: SMS tree, WhatsApp group, phone). Who talks to customers, and the holding line they use. Who decides what is said publicly. Silence during an outage costs more goodwill than the outage.
Section 7 — Test schedule and maintenance
The plan’s heartbeat: restore tests quarterly (log date, what was restored, how long it took), a walkthrough of one scenario playbook annually, and a review of the whole document after any major system change, staff change in named roles, or real incident. A dated revision table at the top of the document keeps everyone honest about whether they are reading a plan or an artefact.
Filling it in: the three mistakes to avoid
Writing aspirations instead of facts. If the backup section describes the backups you intend to have, the plan will fail exactly when consulted. Write what is true today; fix the gaps as actions, not prose.
Letting it grow. Corporate DR plans run to eighty pages because authors are graded on thoroughness. Yours will be used by a stressed person at 6am; every page past ten is a page they will skip. Link out to detailed procedures rather than embedding them.
Storing it only on the systems it protects. Printed copy with the incident lead and deputy, plus a cloud copy reachable from a phone with credentials that do not depend on your own infrastructure.
Frequently asked questions
What should an IT disaster recovery plan include?
Activation authority, a contact tree, a systems inventory with recovery priorities and RTO/RPO targets, backup and restore procedures, scenario playbooks for the likeliest incidents, communication arrangements, and a test schedule. For an SME, ten pages or fewer.
What’s the difference between a DR plan and a business continuity plan?
The DR plan restores IT systems and data. The continuity plan keeps the business operating during disruption (people, premises, suppliers, customers) with the DR plan as its IT component. Insurers and larger clients increasingly ask for both.
How often should we test a disaster recovery plan?
Restore tests quarterly, a scenario walkthrough at least annually, and a review after any significant change. An untested plan should be assumed to contain at least one showstopper, because tested ones almost always did.
Who should own the DR plan in a small business?
A named person with a named deputy: typically the operations lead or owner, with your IT provider owning the technical procedures inside it. Ownership by “the management team” means ownership by nobody at 6am.
Can our IT provider just handle all this for us?
The technical recovery, yes: that is what managed disaster recovery is. The plan still needs your business’s decisions in it (priorities, tolerances, who speaks for the company), which is why building it is a joint exercise, and why we run it with clients as part of continuity planning.
Turn the template into a tested plan
The template is free; the value is in honest answers, verified numbers and a first test that finds the surprises on a quiet Tuesday rather than a bad Friday. That is exactly what our business continuity planning service does, and the free IT health check will tell you first whether your current backups could even deliver the recovery times you are about to write down. Get in touch and build it properly once.
