Disaster recovery plan (DRP)

NIST SP 800-34 Rev. 1 defines the DRP narrowly as an information-system-focused plan for relocating systems to an alternate site after major, usually physical, damage that makes the primary facility unusable, and separates it from the information system contingency plan, which restores a single system in place. In common usage the DRP covers both: the technical procedures, resources and order needed to restore IT services within the recovery time and recovery point objectives set by the business impact analysis. ISO 22301 treats disaster recovery plans as part of the recovery procedures under clause 8.4, and ISO/IEC 27031 gives guidance on ICT readiness for business continuity.

Recovery strategies are chosen by cost against RTO and RPO. Classic site options are cold sites (space and power only), warm sites (pre-installed hardware, data restored on demand) and hot sites or active-active configurations with continuous replication. Cloud providers describe the same spectrum as backup and restore, pilot light, warm standby and multi-site active-active. Synchronous replication can approach an RPO of zero but faithfully replicates corruption and encryption by ransomware, so point-in-time copies such as snapshots, journaled replication or immutable and offline backups are still required.

The core of the plan is a dependency-ordered runbook. Foundational services come first: network, DNS, time synchronisation, identity (typically Active Directory or the cloud identity provider), key management and backup infrastructure, followed by databases, application tiers and finally user-facing services. Each step records the owner, estimated duration, validation check and decision point. Credentials, license keys, vendor contracts and the runbook itself must be available when the directory and document management systems are down. Maersk's 2017 NotPetya recovery famously depended on the one domain controller that had survived because it was offline during a power cut in its Ghana office.

Cyberattacks change DR assumptions. After ransomware, restoring the most recent backup may reintroduce the attacker, because intrusion often precedes encryption by days or weeks, so recovery requires identifying a clean restore point, rebuilding in an isolated recovery environment, scanning restored data, resetting credentials including the krbtgt account, and preserving forensic evidence before wiping systems. Only exercises that measure actual recovery time and point against the objectives show whether a DRP works; untested restores, missing application-consistent backups and bandwidth limits on large data volumes are the usual failures. The DRP gets technology back, whereas the BCP keeps the business operating meanwhile.