Disaster Recovery Guide

Module 1 — What is disaster recovery?

Disaster recovery (DR) is the capability to restore ICT systems, data and services after a disruptive event to the level and within the time the business requires. ICT readiness for business continuity (IRBC) is ISO/IEC 27031's broader term: the readiness of the organization's ICT to support business continuity, whether by preventing a disruption, absorbing it or recovering from it. ICT continuity is the state of ICT services continuing at an acceptable level; DR is what restores that state when it is lost.

Where DR sits: it supports business continuity. The BCMS decides which products and services matter, how long they can be down and how much data they can lose. IRBC and DR then make sure the ICT behind those services can meet what was decided. Disaster recovery is one continuity strategy among several — but the one most organizations are most likely to need on a bad day.

The distinction with business continuity is worth restating because the two are so often conflated. Continuity is business-owned and covers people, facilities, suppliers and communications as well as technology. Recovery is technology-owned and covers systems, data, identity, networks and cloud. We cover continuity in the separate Business Continuity Planning Guide.

Module 2 — ISO/IEC 27031:2025 in context

ISO/IEC 27031:2025 replaced the 2011 edition and is the current published guidance for ICT readiness for business continuity. The 2011 edition should not be treated as the baseline: the 2025 edition realigns IRBC with the ISO 22301 business continuity lifecycle, addresses ICT that is delivered by cloud and outsourced providers, treats cyber-driven disruption (ransomware in particular) as a first-class recovery scenario, and puts far more emphasis on proving that recovery capability meets the requirements the business set rather than asserting that a plan exists.

The standard is guidance, not a certifiable requirement set, so the platform's framework library carries its subclauses as guidance rows and uses them for evidence mapping and finding attribution rather than for pass/fail certification claims.

Module 3 — Recovery requirements: RTO and RPO

Two figures drive every DR design decision, and both are derived from the business impact analysis, never invented by IT:

• Recovery time objective (RTO) — the target time to restore the system or service, always inside the business's maximum tolerable period of disruption.
• Recovery point objective (RPO) — the maximum tolerable data loss, measured back in time from the point of disruption; it dictates backup and replication frequency.

Alongside them: the maximum tolerable period of disruption from the BIA, service tiers that group systems by how fast they must return, and the recovery sequence that respects dependencies. Recovery requirements come from business continuity requirements and are then validated against technical capability. Where capability falls short of the requirement, the organization has a continuity-to-technology recovery gap, and that gap is a finding — a real one, with an owner and a date.

Evidence: approved RTO/RPO register, service tier definitions, recovery sequence, sign-off from the business owners of the prioritised activities.

Module 4 — System dependency mapping

Recovery fails on unmapped dependencies. Map the applications, infrastructure, data stores, integrations, identity services, network services, cloud services, SaaS platforms, third-party services and the physical dependencies (power, connectivity, facilities) for each critical service. The map answers the questions that matter during recovery: what must come back first, what cannot be recovered without something else, and where a single point of failure would stall everything. Identity and DNS are the dependencies most often left off the map and most often the reason a recovery sequence stalls.

Evidence: dependency maps, application inventory with criticality, recovery sequence diagrams, single-point-of-failure register.

Module 5 — Recovery architecture and strategy

Match the design to the requirement. Options include high availability, redundancy, active-active and active-passive configurations, warm and cold sites, cloud recovery, cross-region replication, backup and restore, and alternate processing sites. A four-hour RTO with a fifteen-minute RPO needs replication and an automated failover path; a seventy-two-hour RTO with a twenty-four-hour RPO can be met by tested nightly backups and rebuild procedures. Over-engineering everything is unaffordable; under-engineering the top tier is a finding. Strategy selection should be documented per tier, with the cost and residual gap understood by the business owners who set the requirement.

Module 6 — Backup and restore capability

Backups are the last line of recovery and the most commonly untested one. A defensible programme covers backup scope, backup frequency aligned to RPO, retention, immutability, offline and isolated copies, encryption, integrity verification, restore testing and restore performance measured against RTO. A backup that has never been restored is an assumption. A backup the attacker can delete is not a backup.

Evidence: backup policy, backup coverage report, restore test results with measured restore time, immutability configuration, retention settings, offline or isolated copy design.

Module 7 — Identity and access recovery

Recovery often fails because identity systems cannot be restored first. Cover directory services recovery, identity provider recovery, privileged access recovery, break-glass accounts, MFA recovery, certificate and secrets recovery, and the order in which identity must return before anything that authenticates against it can. If your recovery plan's first step needs an administrator to sign in to a system that is not yet recovered, you do not have a first step.

Evidence: identity recovery procedure, break-glass account register with test dates, secrets and certificate inventory, MFA recovery process.

Module 8 — Cloud and third-party recovery

Cloud does not remove recovery responsibility; it redistributes it. For each cloud and third-party service, understand the shared responsibility model, the provider's own resilience and what it actually guarantees, cross-region and cross-tenant recovery options, SaaS data export and restore, the provider's actual RTO and RPO commitments, and the contract's continuity requirements. Then verify. "The provider handles it" is a finding until the provider's commitment and your recovery test say otherwise.

Module 9 — Cyber-resilient recovery

Modern DR must address destructive cyber events, not only outages. A fire destroys infrastructure and leaves the data trustworthy. Ransomware leaves the infrastructure standing and makes the data, the backups, the identity platform and the recovery tooling untrustworthy. Cyber-resilient recovery therefore adds: immutable and offline backups, a clean recovery environment separated from the compromised one, identity rebuild, forensic preservation so recovery does not destroy evidence, a malware-free restore validation step, and staged recovery that returns services in dependency order rather than all at once.

This module is the seam between two assessments. The Ransomware Readiness Assessment covers the ransomware scenario end to end — prevention, detection, response and the recovery specifics above, mapped to NIST IR 8374 Rev. 1. The DR assessment covers general recovery capability. They inform each other and are never merged into one score: a strong DR programme with weak ransomware readiness is a real and common posture, and so is the reverse.

Module 10 — DR plans and runbooks

Plans should be executable, not ceremonial. The set comprises the DR plan itself, per-system recovery runbooks, the activation criteria, the escalation path, the recovery sequence, the decision points (declare, fail over, fail back), validation steps, communications, and the return-to-normal procedure. A runbook that only its author can run is a single point of failure in human form.

Evidence: DR plan, recovery runbooks, activation and escalation procedures, decision authority matrix, recovery communications templates.

Module 11 — DR testing and exercising

Test types, roughly in order of cost and confidence: tabletop exercise, technical walkthrough, backup restore test, failover test, application recovery test, full DR test, cyber recovery exercise. Every test measures achieved recovery time and recovery point against the required RTO and RPO. That measurement — not the fact that a test happened — is the evidence. Record failures, corrective actions, owners and retest dates. A test whose RTO miss is not recorded as a finding will miss again.

Evidence: test schedule, test results with measured RTO/RPO versus required, failure log, corrective action register, retest evidence.

Module 12 — Monitoring and continual improvement

DR capability drifts. Backup job failures accumulate quietly; a new application ships without a runbook; a cloud region is added without replication; the identity platform migrates and the break-glass procedure stops working. Continuous readiness monitoring watches the signals: backup success rates, restore test currency, replication health, RTO/RPO breaches in tests, unresolved corrective actions, and the age of the last exercise. Metrics and trend feed management review, and management review feeds the next test cycle.

What good looks like

A mature DR programme demonstrates:

• Business-approved RTO/RPO per critical service
• A current dependency map and recovery sequence
• Tested backups with measured restore times, immutable and isolated copies
• Identity recovery that has been tested, with break-glass access verified
• Cloud and third-party recovery commitments verified, not assumed
• A clean-room recovery path for destructive cyber events
• Executable runbooks that someone other than their author has run
• Regular tests measured against RTO/RPO, with corrective actions closed
• Continuous monitoring of backup, replication and restore health

Evidence checklist

The evidence a readiness review, an auditor or an insurer will expect. In the client portal these map to ISO/IEC 27031:2025 subclauses in the framework library and are reusable across assessments.

• DR Policy · DR Plan · RTO/RPO Register · Dependency Maps · Recovery Sequence
• Backup Policy · Backup Coverage Report · Restore Test Results · Immutable Backup Configuration · Offline or Isolated Copy Design
• Identity Recovery Procedure · Break-Glass Account Register · Secrets and Certificate Inventory
• Cloud Recovery Design · Provider RTO/RPO Commitments · SaaS Export and Restore Evidence
• Clean Recovery Environment Design · Cyber Recovery Exercise Results
• Recovery Runbooks · DR Test Schedule · DR Test Results · Corrective Action Register · Management Review Records

How the assessment and the platform use this guide

The free Disaster Recovery Readiness Assessment scores sixteen domains — DR governance, recovery requirements, dependency mapping, recovery architecture, infrastructure, application, data, backup and restore, identity and access recovery, network recovery, cloud recovery, third-party recovery, cyber-resilient recovery, runbooks and procedures, DR testing and exercising, and monitoring and improvement — with each question mapped to the ISO/IEC 27031:2025 subclause it tests. Critical gaps (no approved RTO/RPO, no dependency map, no immutable backups, no restore test, no identity recovery path, no clean recovery environment, no runbooks, no recent DR test) are called out on their own, and the results page shows the recovery chain: which stage of "declare → identity → data → applications → validate → return" your answers say would break first.

For clients, findings from a full readiness review flow into the same lifecycle as every other programme on the platform: Guide → Assessment → Evidence → Finding → Risk → POA&M → Continuous Monitoring → Executive and Board Reporting. Disaster recovery has its own board section (DR readiness, critical findings, open risks, overdue actions, last exercise, RTO failures, RPO failures), its own monitoring signals (exercise age, RTO and RPO breaches in tests, backup and restore evidence expiry) and its own findings. Business continuity has its own. The only relationship between them is through business requirements, dependencies and risks.

Where to go from here

If the business has never told IT how fast each service must come back, start with the Business Continuity Planning Guide and its BIA — without it, the DR programme is guessing at its own targets. If the targets exist, take the DR assessment and see whether backup, identity and testing would actually meet them. If ransomware is the scenario that keeps leadership up at night, the Ransomware Readiness Assessment is the right complement — a separate assessment, with a separate score.