Disaster recovery plan template: the parts that decide whether you recover
Most of what circulates as a disaster recovery plan template is an inventory with a cover page: a list of servers, a list of contacts, a paragraph about management commitment. It documents what you have. It does not tell anyone what to do at three in the morning when the primary environment is gone and the person who built it has left the company.
A disaster recovery plan is a runbook. Its only real test is whether a competent engineer who did not write it can restore service by following it, under pressure, without improvising. Everything else in the document — the scope statements, the policy language, the approval page — exists to support that one property, and most templates get the proportions backwards.
This article sets out what belongs in the plan, in the order you would build it, and it is deliberately technical. The organisational half — degraded operation, crisis communication, holding statements — sits in the business continuity plan, and the two documents work together without duplicating each other.
Short on time? The NIS-2 Compliance Suite contains the continuity and disaster recovery procedure written out, with the plan template, the restore test report and the exercise record alongside it. €590 excl. VAT. If you would rather see where you stand first, the free gap assessment takes ten minutes.
Disaster recovery and business continuity are not the same document
The distinction matters because it decides what goes where, and plans that blur it end up doing neither job.
Business continuity answers the question of how the organisation keeps operating while a service is unavailable — what work moves to paper, which customers get served first, who tells them, when the disruption becomes a crisis. It is written for management.
Disaster recovery answers the question of how the technology comes back — in what order, from which copy, using which credentials, within what time. It is written for the people doing the restoring.
Keeping them in one file is acceptable for a small organisation, provided both halves genuinely exist. What is not acceptable is the common outcome: a long continuity document with a technical annex that names the backup product and stops there. The annex is the part someone will be reading during the incident.
Recovery objectives come before recovery architecture
Each tier buys recovery time with standing cost. The choice is per service, not per organisation.
Before choosing how to recover, you need the two numbers that constrain everything: how long the service can be down, and how much data you can afford to lose. The recovery time objective and the recovery point objective come out of the impact analysis, and if you have not done one, the continuity article covers how those numbers are derived.
What matters here is that they are the input to an architectural choice, and there are essentially four answers.
Backup and restore is the cheapest and slowest: you keep copies and rebuild when needed. Recovery is measured in days for anything substantial, because rebuilding infrastructure, restoring data, and re-establishing configuration are three separate jobs and only the second is what people picture.
Pilot light keeps the core — databases replicating, core network defined, images maintained — running small, with the rest built on demand. Recovery is measured in hours, and it is where most mid-sized organisations land for their two or three critical services.
Warm standby keeps a scaled-down but complete copy of the environment running, ready to take traffic. Recovery is measured in minutes to an hour, and the standing cost is real.
Active-active runs the service in two places at once with traffic split between them. Recovery approaches zero because there is nothing to recover, only capacity to lose. It is expensive, it constrains application design, and it is unnecessary for most systems.
The important discipline is that the tier is chosen per service, from the objectives, and written down with the reason. An organisation that has decided its order system is warm standby and its reporting stack is backup-and-restore has a defensible plan. An organisation with a uniform “four-hour RTO” across forty systems has an aspiration.
One trap worth naming. Cloud platform replication is not disaster recovery. It replicates faithfully, which means it replicates deletion, corruption and encryption faithfully too. Redundancy protects against infrastructure failure; only an independent copy protects against everything else.
The recovery sequence is dictated by dependencies
Recovery order follows dependencies, not business priority. The most important system is rarely the first one you can start.
Ask an organisation what it would restore first and the answer is usually the most important system. Ask again after a real incident and the answer is different, because the most important system cannot start until the things underneath it are running.
Restoration order follows the dependency graph. Network and name resolution come first, because nothing is reachable otherwise. Identity follows, because almost every modern system authenticates against it — and if your identity provider is itself the thing that was compromised, that dependency is the whole plan. Then data platforms, then the applications on top of them, then the integrations that connect them to the outside world, then reporting and everything else that can wait.
Write the sequence with the dependency stated next to each step, because the dependency is what stops someone helpfully reordering the list during the incident. Mark the steps that can proceed in parallel, since parallelism is where you recover the time the plan assumes. And record an expected duration per step, so that during the event you know whether you are on schedule or already past your RTO — which changes what you tell people.
Two dependencies are chronically missing from otherwise good plans. The first is external: the payment provider, the logistics platform, the supplier API that has to be reconnected and, in some cases, re-authorised at their end during business hours. The second is licensing — software that will not start in a new environment without a license server, an activation, or a vendor call. Both are discovered at the worst possible time by organisations that have never done a full test.
Access during recovery, and the credential problem
The most common single point of failure in disaster recovery is not technical. It is that the credentials needed to perform the recovery live inside the environment being recovered.
The password vault authenticates against the identity provider that is down. The multi-factor prompts go to a system that is unavailable. The recovery documentation is on the intranet. The person with the break-glass account is on a flight.
The plan has to name where the emergency credentials are held, who can obtain them, under what authorisation, and how their use is logged afterwards. Break-glass accounts need to exist, be excluded from the dependencies they are meant to bypass, be monitored so that use is noticed, and be rotated after every use and on a schedule regardless. Store the details somewhere physically separate — a sealed envelope in a safe remains a defensible control — and check quarterly that they still work, because credentials that have silently expired are functionally identical to credentials you do not have.
The same applies to the plan itself. If it is only in the wiki, and the wiki is behind the identity provider, the plan does not exist in the scenario it was written for.
Writing this from scratch takes longer than most people budget for. The continuity and disaster recovery procedure in the NIS-2 Compliance Suite covers impact analysis, recovery objectives, backup and redundancy, the recovery runbook and exercising in one document — with the restore test report and the exercise record alongside it, which is what an inspection actually asks to see.
Ransomware breaks the ordinary restore path
After a compromise, restoring into the original environment reinfects it. The clean path costs time you have to plan for.
Almost every disaster recovery plan assumes something broke. Ransomware is different in three ways, and a plan that has not accounted for them will be abandoned in the first hour.
The environment you would restore into is compromised. Restoring the data without rebuilding the platform puts the same systems back with the same foothold — and if the attacker was present for weeks, your backups may contain the persistence mechanism as well. Clean recovery means building a known-good environment, restoring into it, and validating before reconnecting.
The recovery point is not the incident. Encryption is the last step of an intrusion that started earlier, so the most recent backup is often already contaminated. You need retention long enough to reach a clean point, and a way to determine where that point is — which means logs that survive the compromise.
And recovery competes with investigation. Rebuilding destroys evidence that the forensic work, the insurer and the regulator all need. Preserve first — images, memory captures, log exports — then recover. In practice this means the plan should name who authorises the switch from evidence preservation to restoration, because during the event two teams will want opposite things and someone has to decide.
Backups themselves need the same scepticism. At least one copy must be beyond the reach of the credentials that administer production: offline, immutable, or in a separate tenant with independent authentication. Attackers look for the backup infrastructure first, and they find it through the administrative account that manages everything else.
Write it so a stranger can execute it
A runbook is not prose. The parts of the plan that get used during an incident should read like a procedure, and the test of every step is whether a competent engineer unfamiliar with the system could follow it without asking a question.
That means exact commands and console paths rather than descriptions of them. Named systems rather than categories. Expected output, so the person knows whether the step worked. Named people with deputies and actual phone numbers, because a role title does not answer a call at four in the morning. And a decision point stated as a decision, not a principle: if this check fails, do that.
Keep the runbook separate from the policy sections. The document a regulator reads and the document an engineer executes have different readers and different rhythms, and merging them produces something that serves neither. A short plan with a good annex beats a long plan with a vague one.
Finally, date every step against the last time it was verified. A runbook written for an environment that has since been migrated is worse than nothing, because someone will trust it.
Testing is the only thing that turns the plan into a fact
An untested plan states an intention. The distance between the intention and the capability is usually large and always uncomfortable, which is exactly why it should be measured while it is cheap.
Test at three levels, on a schedule you actually keep. A restore test takes a real backup, restores it somewhere isolated, and confirms the data is complete and usable — quarterly for critical systems, and more often after significant change. A tabletop puts the team in a room with a scenario and no access to their systems, and reliably surfaces the mundane failures: the contact list only exists online, nobody can authorise emergency spend, the one person who knows the restore procedure left in March. A full failover exercise moves a service to the recovery environment and runs it there, which is the only test that proves the plan rather than the parts.
Whatever the level, record three numbers: what you restored, how long it took, and whether it worked completely. Partial restores are the interesting result — the database came back but not the configuration, the application started but could not reach the payment provider — and they are the ones a backup job report will never show you.
When the measured time exceeds the objective, you have not failed the test. You have produced the finding the test existed to produce. Either the objective moves or the capability does, and the plan records which was chosen and by whom.
What NIS-2 requires, and what an inspector asks to see
Under NIS-2 the plan is not the evidence. The test records are.
If your organisation is in scope for NIS-2, disaster recovery moves from good practice to legal obligation. Article 21(2)(c) of Directive (EU) 2022/2555 requires business continuity, including backup management and disaster recovery, and crisis management. The directive text is short and outcome-based; it names the objective and leaves the method to you.
The specifics sit in Commission Implementing Regulation (EU) 2024/2690, which applies directly and identically across the Union to entities in the digital infrastructure and digital provider sectors. Point 4 of its Annex covers the business continuity and disaster recovery plan, backup and redundancy management, and crisis management. It requires the plan to be based on a business impact analysis, and it requires the plan and the recovery of backup copies to be tested at planned intervals and after significant incidents or significant changes — with the lessons learnt fed back into the plan. Where the Implementing Regulation does not apply directly, it remains the clearest available statement of what a supervisory authority considers appropriate and proportionate.
Three practical consequences follow.
The evidence is the test record, not the document. What gets examined is the impact analysis with real numbers, restore test reports with dates and durations, exercise records with actions tracked to closure, and the approval by the management body. A well-written plan with no test history is treated as a plan that has never been tested, because that is what it is.
Recovery does not pause the reporting clock. A significant incident triggers the Article 23 duties — early warning within 24 hours, notification within 72, final report within a month — running from awareness, not from resolution. Assign notification to someone who is not doing technical recovery, or it will be late. Our guide to the incident response plan and the 24-hour clock covers that side in full.
And effectiveness has to be assessed. Article 21(2)(f) requires policies to assess whether the risk-management measures work, and it applies to this one: an untested recovery plan is not an effective control, whatever the cover page says. For how continuity fits with the other nine measures, see the ten Article 21 measures.
Financial entities have a stricter parallel regime. Regulation (EU) 2022/2554 — DORA — requires an ICT business continuity policy with response and recovery plans, and requires restoration to use ICT systems that are segregated from the production systems, along with regular testing. If you are in scope for both, build one set of documents and map it twice.
The plan, section by section
Adapt the wording; keep the structure. Sections one to six are the plan; seven to twelve are the runbook; the rest is what makes it maintainable.
- Scope — which services and systems this plan covers, and explicitly which it does not.
- Recovery objectives — RTO and RPO per service, with the tier chosen and the reason.
- Recovery architecture — where the recovery environment is, what runs there permanently, what is built on demand.
- Backup design — scope, frequency against the RPO, retention, encryption, geographic separation, and which copy is isolated.
- Roles — named people with deputies, contact details, and who authorises invocation.
- Invocation criteria — what triggers the plan, who declares it, and how the team is convened on a channel that survives the outage.
- Dependency map — the order the environment has to come back in, and what forces that order.
- Recovery runbook — step by step, per service, with commands, expected output and expected duration.
- Access during recovery — emergency credentials, where they are held, who obtains them, how use is logged.
- Data validation — how you confirm the restored data is complete and correct before anyone uses it.
- Clean recovery — the variant path when the cause is compromise: build clean, restore, validate, reconnect.
- Failback — how you return to primary, when, and how you reconcile the data written during recovery.
- External dependencies — suppliers, cloud tenants, licensing and the reconnections that need someone else’s business hours.
- Testing — the schedule, what each level tests, and where the reports are kept.
- Version control — owner, approval, date, and the date of the last successful test.
Failback deserves the emphasis it rarely gets. Organisations plan the move to the recovery environment and improvise the return, then discover that the data written during three days of recovery has to be reconciled with a primary environment that has moved on, and that the reconciliation is harder than the failover was. Write it before you need it.
Four things to do this week
If writing the full plan is more than you can take on now, these give the most back for the least effort.
Find out the date and duration of your last real restore. If the answer is “we have backups” rather than a date and a number, that is your finding, and booking a test is the fix.
Check whether one backup copy is genuinely outside the reach of your production administrative credentials. If an admin account can delete it, so can whoever compromises that account.
Write down where the emergency credentials are and verify that they still work. Then check that the plan itself is readable without logging into the environment it describes.
Pick your most critical service and write the first ten steps of its restore, with commands. The gaps you hit in the first hour of writing are the plan’s real weaknesses.
Frequently asked questions
What is the difference between a disaster recovery plan and a business continuity plan? Disaster recovery restores the technology; business continuity keeps the organisation operating while it is down, including by non-technical means. Disaster recovery is a component of continuity, and the two are usually separate documents with different readers — technical staff for one, management for the other.
What should a disaster recovery plan template contain? Scope, recovery objectives per service, the recovery architecture and backup design, named roles and invocation criteria, the dependency-ordered recovery sequence, the step-by-step runbook, emergency access, data validation, the clean-recovery variant for compromise, failback, external dependencies, the testing schedule and version control.
How often should a disaster recovery plan be tested? Restore tests quarterly for critical systems, a tabletop at least annually, and a full failover exercise annually where the organisation can bear it. Also test after any significant change to systems, suppliers or the team — and record duration and completeness every time.
Is a disaster recovery plan mandatory under NIS-2? Article 21(2)(c) of Directive (EU) 2022/2555 requires business continuity including backup management and disaster recovery. No format is prescribed, but for entities covered by Implementing Regulation (EU) 2024/2690 the plan must be based on a business impact analysis and tested at planned intervals, with the results documented.
How do RTO and RPO differ? RTO is how long the service may be unavailable before you commit to having it back. RPO is how much data, expressed in time, you accept losing — which sets your backup frequency. RTO looks forward from the incident; RPO looks backward.
Is cloud replication enough for disaster recovery? No. Replication protects against infrastructure failure and copies corruption, deletion and encryption exactly as faithfully as it copies good data. It complements an independent, isolated backup copy; it does not replace one.
Where to go next
Disaster recovery is one part of one of the ten NIS-2 risk-management measures, and organisations that have it in good shape are often weakest somewhere they have not looked.
The free NIS-2 gap assessment asks twelve questions, one per obligation, and scores you measure by measure. Ten minutes, and it tells you what you could evidence today if someone asked.
If you would rather start from a written set, the NIS-2 Compliance Suite contains the continuity and disaster recovery procedure described here — impact analysis, recovery objectives, backup and redundancy, recovery and exercising in one document rather than a folder of overlapping files — plus the plan template, the restore test report and the exercise record. €590 excl. VAT.
You may also want to read the companion piece on what makes a business continuity plan work, which covers the organisational half, and an incident response plan that survives the 24-hour clock for the reporting duties that run in parallel with recovery.
Sources
Directive (EU) 2022/2555 and Commission Implementing Regulation (EU) 2024/2690 are available on EUR-Lex.