A disaster recovery plan is the documented procedure for restoring technology services after a failure, covering which systems come back in what order, how long each should take, how much data loss is acceptable and who performs the work. It is the technical layer of continuity planning. Where a continuity plan keeps the business running by whatever means, a recovery plan is specifically about getting the systems themselves back.
- A prioritised system list, inherited from the business analysis rather than invented by IT.
- A recovery target and an acceptable data loss figure for each system.
- Runbooks detailed enough for someone other than the usual person to follow.
- The dependency order, because systems restored in the wrong sequence fail to come up.
- A test record, since an untested recovery procedure is a hypothesis.
What is a disaster recovery plan?
A disaster recovery plan sets out how technology services are restored after an event that takes them down: hardware failure, data centre loss, a failed change, a cloud region outage, ransomware. It answers three questions for every system in scope. How quickly must it be back, how much recent data can we afford to lose, and what exactly does somebody do to bring it up.
The word disaster is misleading. Most invocations are not dramatic. A corrupted database, a botched migration or an expired certificate on a critical service will send you to the same plan as a flood. Writing the plan only for catastrophic scenarios leaves you improvising through the far more common ones.
Recovery planning is one part of the wider capability described under business continuity, which is where the priorities and recovery timeframes come from. If the technology view has been built without those, the plan is protecting systems in an order nobody has validated against the business.
How do you choose a recovery approach?
The recovery target dictates the architecture, and the architecture dictates the cost. This is the trade-off that determines everything else in the plan, and it is worth making explicitly rather than inheriting whatever the infrastructure happens to support. Three broad options exist, and the vocabulary around them is unhelpfully technical for what are fairly simple ideas.
| Backup restore | Warm standby | Active-active | |
|---|---|---|---|
| What it is | Rebuild the service from the last backup after a failure | A second copy kept running but idle, switched to when needed | Two live copies sharing the work, so there is nothing to switch on |
| Data loss window | Since the last backup | Minutes of data | Near zero |
| Time to restore | Hours to days | Minutes to hours | Near zero |
| Protects against | Bad or encrypted data | Infrastructure loss | Site or region loss |
| Standing cost | Storage only | Part of a second estate | Two live estates |
| Suited to | Services that can tolerate an outage | Most critical services | Services that cannot stop |
Few organisations need the same approach everywhere. The useful pattern is to tier: a small number of services that genuinely cannot stop get expensive protection, the majority get something proportionate, and the long tail is restored from backup. Applying one approach uniformly either overspends on activities that could tolerate a day, or leaves the critical few with a recovery time the business has already rejected.
Two failure modes recur. The first is a recovery target chosen without pricing the architecture that delivers it, so the plan commits to something the infrastructure cannot do. The second is buying replication and assuming it is recovery, when a corrupted or encrypted dataset replicates just as faithfully as a good one. Replication protects against infrastructure loss. Backups protect against bad data, and the two are not substitutes.
What should a disaster recovery plan contain?
Per system, not per organisation. A single narrative document describing the approach in general is not usable at three in the morning by whoever is on call.
- Recovery targets: the time objective and acceptable data loss for that system, traced back to the business analysis that set them.
- Dependency order: what has to be running first. Authentication, networking, DNS and databases generally precede the applications that need them.
- The runbook: the actual steps, written so a competent engineer who does not own the system can execute them.
- Access and credentials: how privileged access is obtained during an incident, held somewhere that survives the failure.
- Data restoration: where backups are, how to verify integrity, and how long a restore genuinely takes at real data volumes.
- Verification: how you confirm the service is actually working rather than merely running.
- Roles and escalation: who decides to invoke, who performs, who communicates and who authorises a fallback.
Of those, the dependency order repays the most attention, because getting it wrong produces failures that look like a broken system rather than a sequencing mistake. An application restored before the database it reads, or before the identity service it authenticates against, will not start, and the team loses time diagnosing the wrong problem. The general shape holds across most estates.
The detail that most often turns out to be missing is how long a restore really takes. A backup that completes overnight may take considerably longer to restore at production volume, and if nobody has measured it the recovery target is a guess.
One boundary is worth drawing. A recovery plan restores the systems. The workaround the business uses while that happens, for one specific named risk, belongs in a contingency plan instead. Organisations that keep only the technology plan tend to discover that nobody agreed how the work would continue in the meantime.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
How do you test a disaster recovery plan?
Testing is where recovery plans earn their credibility, and there is a progression. Each level costs more and proves more, and a programme that never leaves the first level has not established very much.
| Test type | What it proves | What it costs |
|---|---|---|
| Walkthrough | That the documentation is complete and comprehensible to someone who did not write it. | A few hours. No systems touched. |
| Tabletop exercise | That people know their roles and that decision making and escalation work under pressure. | Half a day of the right people’s time. |
| Component restore | That backups are actually restorable and that the real restore duration is known. | Moderate. Needs an isolated environment. |
| Partial failover | That a single service can run from its recovery position, dependencies included. | Significant planning. Some service risk. |
| Full failover | That the whole environment can run from recovery, at load, with the business working on it. | High. Usually needs a planned window. |
Record what failed. A test log showing problems found and fixed is stronger evidence of a working capability than a series of clean passes, which mainly suggests the tests were not demanding enough. Findings with owners and dates are what turn testing into improvement rather than reassurance.
Which standards cover disaster recovery?
No standard is dedicated solely to disaster recovery, so the requirements are distributed across several, which is one reason recovery planning often ends up disconnected from everything else.
- ISO 22301: the certifiable management system for business continuity. It sets the analysis and the recovery priorities that a technology plan should inherit.
- ISO/IEC 27031: guidance specifically on ICT readiness for business continuity, which is the closest fit to disaster recovery as a discipline.
- ISO 27001: Annex A includes controls on information security during disruption, ICT readiness for continuity and information backup, so recovery capability is examined during an audit.
- Sector rules: regulated organisations face additional expectations, for example the continuity and recovery requirements under NIS 2 implementing guidance.
Working to ISO 22301 and ISO 27001 together produces most of the evidence these regimes ask for, in a form that has already been independently audited.
Start your free trial
Want to explore?
Sign up for your free trial today and get hands on with all the compliance features that ISMS.online has to offer
How does disaster recovery connect to resilience?
Disaster recovery restores systems. Resilience is the broader capability to absorb disruption of any kind, including the events no runbook anticipates. The link between them is that recovery depends entirely on controls that sit outside the recovery plan: whether backups are immutable, whether privileged access still works when the identity provider is down, whether the supplier hosting the recovery environment has been assessed, whether the incident response process functions.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system, with recovery as a further lens over the same controls. Ransomware makes the point plainly. It is simultaneously a security incident, potentially a personal data breach and a recovery event, and an organisation running those three as separate programmes responds to it three times. The structure that avoids that is set out in the business resilience framework.
How do you prove disaster recovery works?
Nobody credible accepts the existence of a plan as evidence. What stands up is the plan itself with current recovery targets, test records showing dates and participants, the failures those tests exposed, the remediation that followed, and confirmation that the plan still matches the estate it describes.
Generated while the work happens, that evidence is always available. Assembled before an audit or a customer’s due diligence, it tends to reveal how far the documented estate has drifted from the real one. The approach is set out in how to evidence resilience, and the Resilience Score gives you a baseline to work from.
Why choose ISMS.online for disaster recovery planning?
Recovery plans fail on currency far more often than on content. ISMS.online is built to keep them aligned with the estate.
- Plans tied to the systems they cover: each entry connects to the asset, its owner and the controls it relies on, so drift is visible.
- Recovery targets inherited, not invented: the objectives set by the business analysis carry through to the technology plan.
- Test schedules and findings together: plan exercises, record what failed and track corrective actions in the same place as the plan.
- One control set, every framework: backup, access and supplier controls mapped once and reused across ISO 22301, ISO 27031, ISO 27001, ISO 27701 and ISO 42001.
- Supplier dependencies assessed: the third parties your recovery quietly depends on are managed in the same system.
- Informed by deep expertise: guided implementation from specialists who have run recovery programmes in regulated environments.
- Built for UK and regulated markets: designed for organisations that have to prove recovery capability to auditors and customers.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between a disaster recovery plan and a business continuity plan?
A disaster recovery plan restores technology services. A business continuity plan keeps the business operating through disruption by any available means, which may include working manually while systems are down. Recovery is a component of continuity rather than an alternative to it, and the recovery targets in the technology plan should come from the business analysis that the continuity plan is built on.
What should the RTO and RPO be?
Both come from the business impact analysis rather than from what the infrastructure can currently deliver. The recovery time objective is derived from the point at which disruption to the activity becomes unacceptable, set with margin inside that limit. The recovery point objective follows from how much recent data the business could reconstruct or afford to lose. Setting either from current technical capability produces targets that are always met and prove nothing.
What is the difference between warm standby and active-active?
Warm standby keeps a second copy of the service running but idle. It is not serving anyone until you fail over to it, so recovery involves a deliberate switch, and that switch takes time and can go wrong. Active-active means two live copies are both handling real work at the same time, so losing one leaves the other already serving and there is nothing to switch on. Active-active removes the failover step and is correspondingly more expensive, because you are running and licensing two production environments rather than one and a spare.
How often should a disaster recovery plan be tested?
At least annually for a meaningful test, with lighter walkthroughs more frequently and a review whenever the estate changes materially. Frequency matters less than progression: an organisation that runs the same tabletop every year knows its people understand their roles but still has no evidence that a restore works at production volume. Alternate the test type so different assumptions get examined.
Does cloud hosting remove the need for a disaster recovery plan?
No. Cloud platforms provide the building blocks for resilient architecture, but availability zones and managed services are configuration choices rather than defaults, and regional outages do occur. Cloud also does nothing about deleted or encrypted data, misconfiguration or a compromised account. The plan changes shape in the cloud, becoming more about configuration, immutable backups and account recovery than about hardware, but it does not disappear.
Is ransomware a disaster recovery scenario?
It is that and more. Ransomware is a security incident, frequently a personal data breach and a recovery event at the same time, and it invalidates assumptions ordinary recovery planning makes. Backups may be encrypted or deleted, so immutability and offline copies matter, and the environment may need to be rebuilt rather than restored in place because restoring into a compromised estate simply reinfects it.
