Disaster Recovery Plan Template

The complete disaster recovery plan, free to copy from this page or download as an editable Word document. No sign-up. Replace every [bracketed placeholder] with your own details, delete anything that does not apply, and have it approved before you rely on it. The guide below explains what each section has to contain and what an auditor checks.

14

sections

4

with real wording

7

auditor requests

7

failure modes

A disaster recovery plan is about technology, not about the business activities that run on it: which systems come back, in what order, from which backups, by whose hands, and how you prove each one is right before users return. Before section 1, list every system you run and what it depends on, including the unglamorous ones - identity, DNS, the firewall, the backup platform - because nothing else restores until they do. Here is every section in order, what each has to contain and what an assessor is checking when they read it. Four of them carry an example clause, because those four are the ones people get wrong.

1. 1

   Purpose, scope and related plans

   What it must contain

   The sites, data centers, cloud accounts and teams the plan covers, what it excludes, and one short paragraph on how it relates to the continuity plan and the incident response plan: the continuity plan sets what the business needs back, this plan restores the technology, and the incident plan decides when a compromised system may be touched.

   What the auditor checks

   Whether the scope matches your ISMS scope and your asset inventory, and whether the three plans hand over to each other or quietly overlap. Two plans that both claim to run the recovery is a contradiction they can find without testing anything.

2. 2

   System inventory and recovery tiers

   What it must contain

   Every system in scope placed in a tier that sets its recovery order and its level of protection, plus a foundation tier for what everything else needs first: identity, network, DNS and the backup platform itself. Say what happens to anything not listed.

   What the auditor checks

   They compare the list against your asset inventory and pick a system that is missing from it. The foundation tier is the one people leave out, and it is the first thing a real recovery needs.

3. 3

   Recovery objectives per system

   What it must contain

   An RTO and an RPO for every listed system, an owner, and what each system depends on. The numbers come from the business continuity arrangements, translated from activities into systems, not invented by IT to match the backup it already runs.

   What the auditor checks

   Where the numbers came from, and whether the recovery strategy and backup schedule for that system can genuinely meet them. A system with an RPO tighter than its backup frequency is arithmetic, not judgment.

   Where a system supports more than one critical activity, it takes the shortest RTO and RPO of any of them.

   Activities and systems do not map one to one, and the translation is where targets quietly loosen. A shared database behind order taking and reporting inherits the order-taking numbers, not an average of the two. Writing the rule down stops each system owner from picking the target that suits the backup they already have.

4. 4

   Roles and responsibilities

   What it must contain

   The DR coordinator who declares and runs the recovery, the technical recovery team, the system owners who sign off each restored system, the communications lead and whoever chases suppliers. Each with a named alternate, and contact details held somewhere readable without your own email or directory.

   What the auditor checks

   Whether the names are current and the alternates exist. They also look for the system owner role: a recovery signed off by the person who ran the restore has no independent check on whether the data is right.

5. 5

   Invocation: declaring a disaster

   What it must contain

   Who a suspected disaster is reported to, who decides, how long before an alternate decides instead, and the criteria that turn an outage into a disaster: a Tier 1 system down past a threshold, a site or cloud region lost, data destroyed or encrypted, or advice that systems must be rebuilt.

   What the auditor checks

   Whether the criteria are specific enough that two people would reach the same decision, and whether decisions are logged, including the decision not to invoke.

6. 6

   Recovery strategies

   What it must contain

   For each tier, how recovery actually happens: restore from backup, redundancy within the primary site or region, failover to a secondary site or cloud region, or the provider's own recovery for software-as-a-service. And what happens when a strategy cannot meet its target: fund it, or change the target and record the risk.

   What the auditor checks

   They pick a Tier 1 system and ask how it comes back if its whole site or region is gone. Redundancy inside one region answers a server failure, not a regional outage, and they will ask which one you planned for.

7. 7

   Backup arrangements

   What it must contain

   Per system or data set: frequency, where the copies live, whether one of them is immutable or offline, how long they are kept and how often a restore is tested. Include software-as-a-service data, which is often assumed to be backed up by the provider.

   What the auditor checks

   A dated restore test for a system they choose, with the elapsed time, and proof that at least one copy sits out of reach of a compromised administrator account.

   At least one copy of every Tier 1 and Tier 2 backup is immutable or offline, held under credentials separate from the production environment, so that an attacker with administrator access to production cannot alter or delete it.

   An attacker who reaches your domain administrator account usually reaches the backup console too, and deleting backups before encrypting production is a commonly reported step in ransomware attacks. Immutable or offline is the what; separate credentials is the part people forget, and it is what makes the copy unreachable in practice rather than on paper.

8. 8

   Recovery runbooks

   What it must contain

   A runbook per Tier 1 and Tier 2 system in one fixed structure: targets and dependencies, prerequisites such as accounts, licenses and encryption keys, the recovery steps, the validation checks, handback and rollback, and the last test result. Stored where it can be read with the network down.

   What the auditor checks

   They ask for one runbook and who last followed it. A runbook only its author can follow, or one stored on the system it restores, reads as no runbook.

9. 9

   Ransomware and cyber attack recovery

   What it must contain

   What changes when the cause is an attacker: restore only into an environment declared clean, choose the restore point from the earliest evidence of compromise rather than the newest backup, reset privileged and service credentials before reconnecting, preserve evidence, and leave decisions about law enforcement, insurers, regulators and the attacker to the incident process.

   What the auditor checks

   Who declares the environment clean, and how the plan and the incident response plan hand over. A recovery that starts before the incident lead has released the systems restores the attacker along with the data.

   No system is restored into an environment that has not been declared clean by [role, with the incident lead]. Rebuild into an isolated, known-good environment where there is any doubt.

   The pressure in a ransomware recovery is all toward speed, and restoring straight back onto the infrastructure the attacker used is the fastest option. This line puts a named decision in front of it. The two bullets that follow in the template do the rest: a restore point chosen from the earliest evidence of compromise, and every privileged credential reset before anything is reconnected.

10. 10

    Supplier and cloud provider dependencies

    What it must contain

    For each supplier behind a Tier 1 or Tier 2 system: the recovery commitment actually in the contract (or a note that there is none), the out-of-hours support route, and your own fallback if they cannot meet your targets.

    What the auditor checks

    They cross-read this against the contracts and your supplier register. A cloud provider's shared responsibility model usually leaves backup of your own data and configuration with you, and a plan that assumes otherwise is a finding.

11. 11

    Communications during recovery

    What it must contain

    Who updates staff, through which channel, how often, and the fallback when your own systems are the thing that is down. Customer and public messages defer to the continuity plan; this section keeps the recovery team's estimates flowing to whoever speaks for the business.

    What the auditor checks

    That the fallback channel does not run on the failed infrastructure, and that estimates come from the recovery team rather than from someone guessing.

12. 12

    Return to normal operations and failback

    What it must contain

    What recovered means (the owner has checked the data and the system is usable, and its security controls are back), who stands the plan down, how failback from a secondary site or region is run, how long the recovery environment is kept, and when the post-recovery review happens.

    What the auditor checks

    The stand-down record and the review actions, closed. They also ask what was relaxed during recovery, such as temporary accounts or disabled logging, and when it went back.

    Failback from a secondary site or cloud region is scheduled as a planned change, approved by [role], and is not started until a fresh backup has been taken at the recovery site.

    Everything written while running at the recovery site exists only there. Failing back in a hurry, without a backup of that environment, is how data survives the disaster and is then lost on the way home. Treating failback as a planned change also means it is scheduled for a quiet window, not the first evening things look stable.

13. 13

    Testing and exercising

    What it must contain

    Three kinds of test on a stated cycle: a tabletop that includes a ransomware scenario, restore tests timed against the RTO and checked by the system owner, and a failover test for every system that relies on one. Plus the triggers that beat the calendar, and what each test records.

    What the auditor checks

    The last restore test for a system they choose, with its elapsed time against the RTO, and the actions it raised, closed. A test program that has only ever been a tabletop has never measured a recovery time.

14. 14

    Maintenance and document control

    What it must contain

    The review cycle and triggers, what is re-validated at each review (inventory, tiers, objectives, runbooks, suppliers, contacts), then the owner, approver, approval date, version, next review date and where the current copy and its offline copy live.

    What the auditor checks

    The approval record, and whether the system list still matches today's environment. A plan that still lists a system you migrated away from last year tells them nobody has reviewed it.

Get it written for your organization - your first document is free Card required; no charge today.

Assessors rarely comment on how a recovery plan is written. They pick a system and follow it off the page: into the backup configuration, the last restore record, the supplier contract and the continuity plan the targets came from. Answer these about your own draft before somebody else does.

? Show me the current plan, and where you would read it with the network down.

Satisfies A version number, an owner, a dated approval, and a copy held somewhere that does not depend on your own systems, which you can point to on the day.

Fails A plan whose only copy sits on the file server or intranet it exists to recover.

? Pick a Tier 1 system. When was it last restored, and how long did it take?

Satisfies A dated restore test record with the elapsed time, the system owner's confirmation that the data was complete and usable, and the result compared with that system's RTO.

Fails A backup job report showing successful backups, with no restore, no timing and no check of the restored data.

? Where did these RTOs and RPOs come from?

Satisfies The business continuity arrangements or impact analysis the numbers were taken from, and a record of who agreed them, so each system's targets trace back to a business need.

Fails Targets set by IT to match the backup schedule already in place, which no one outside IT has seen.

? If an attacker had your administrator credentials, could they delete your backups?

Satisfies An immutable or offline copy for the systems that matter, held under separate credentials, and evidence that its configuration has been checked, not just purchased.

Fails Every backup copy reachable from the same domain administrator account that runs production.

? What does your cloud provider commit to, and what is left to you?

Satisfies The contracted recovery commitments for each provider behind a critical system, and your own backup or export of the data where those commitments do not meet your RPO.

Fails An assumption that the provider backs up your data and configuration, with nothing in the contract to say so.

? When did you last test a failover, and what failed?

Satisfies A test record with the date, the scenario, who took part, what went wrong, and the actions raised, each with an owner and a due date and later closed, and the plan reissued at a new version.

Fails A test report on which everything passed, with no actions and no change to the plan.

? Does this plan agree with your other documents?

Satisfies The same systems as your asset inventory, the same suppliers as your supplier register, the same retention as your backup configuration, and the same recovery targets as your continuity plan.

Fails A continuity plan promising four-hour recovery for an activity whose system this plan puts in Tier 3.

Notice how little of that is about the document itself. A recovery plan is judged by its records - restores, failovers, test actions closed - and a well-written plan with no records behind it answers none of these questions.

Recovery plans rarely fail because a section is missing. They fail on assumptions nobody tested, and every one of these is visible in a draft long before a real outage finds it. Read your own against the list.

• ! Backups that were never restored

  Green backup reports for years and no record of a single restore. A backup that has never been restored is an assumption: the job can succeed while the data is incomplete, the encryption key is missing or the restore takes far longer than the RTO allows.

• ! Every copy reachable from production

  Backups on a share the domain administrator can delete, or replicated to a second region under the same account. Replication copies corruption and encryption as faithfully as it copies data. Keep one copy immutable or offline, under separate credentials.

• ! Restoring into the attacker's environment

  Rebuilding servers from backup onto the same network, with the same administrator passwords, before anyone has confirmed how the attacker got in. The restored systems are compromised again before the first user logs back in.

• ! Forgetting the foundation

  Runbooks for the finance system and the CRM, and nothing for identity, DNS, the firewall or the backup platform itself. Nothing else can be restored until those are, and they are the systems least often written down.

• ! Recovery objectives nobody outside IT agreed

  RTOs and RPOs chosen because the current backup schedule already meets them. The plan then passes its own tests and fails the business, because the numbers were never checked against what the business actually needs back and how fast.

• ! Assuming the cloud provider has it

  No backup of software-as-a-service data or cloud configuration, on the belief that the provider keeps one. Providers typically protect their own infrastructure; deleted or encrypted customer data and misconfiguration are often left to the customer. Read the contract and back up what it does not cover.

• ! The plan lives on the systems it recovers

  Runbooks on the wiki, contact lists in the directory, the plan itself on the file server. When those are down the recovery team starts from memory. Keep a current copy, including contacts, somewhere that does not depend on your own infrastructure.

PolicyMint writes this as an ICT Continuity and Disaster Recovery Plan. It comes back with your own critical systems listed in recovery-priority order with an RTO, an RPO and their dependencies beside each, a recovery team table with a named alternate for every role, the activation decision and recovery sequence drawn as diagrams, and a section on keeping security controls in force during recovery - written against the systems, suppliers and roles you told us you run, with the square brackets resolved rather than left for you to fill. The cover in the hero and the body page below are this document generated for an example company, in that company's branding, shown exactly as PolicyMint renders it.

Where the guide says [role] or [system], the document says yours; where PolicyMint cannot know a fact, it asks rather than guesses.

Guided review Actual product

The one fact this document could not know stays highlighted in the document and the export. The review explains what is needed and writes your answer in. Nothing is invented. Fictional demo data.

Both columns end with the same document in your hands. The difference is who settles the decisions inside it, and what is left over for you to maintain afterward.