BCM-002 Disaster Recovery Plan
Description
A documented Disaster Recovery Plan defines the procedures for recovering IT systems and services after a significant disruptive event. The plan specifies recovery sequences, responsible roles and technical procedures for restoring from backups or failover infrastructure. For transaction-based systems, the procedures return the system to a transactionally consistent state using the journal or write-ahead log rather than the last full backup alone, and the point of consistency reached is recorded. The plan is reviewed and updated at least annually.
Rationale
The continuity plan covers the business response to disruption and this plan covers the technical restoration of systems; both are required and serve distinct purposes. Transaction recovery is the case a backup-only procedure gets wrong quietly: restoring the last snapshot brings a system back running while leaving in-flight transactions half applied, so the service is available and the data is wrong. Recording the point of consistency lets the business decide what has to be reprocessed.
Applicability (9 profiles)
Framework Mappings (13)
| BCR-09 | Disaster Response Plan | full |
| BCR-09 | Disaster Response Plan | full |
| GDPR-Art.32.1 | Technical and Organisational Security Measures | partial |
| HIPAA-164.308.a.7.i | Contingency Plan | full |
| HIPAA-164.308.a.7.ii.B | Disaster Recovery Plan | full |
| HIPAA-164.310.a.2.i | Contingency Operations | informative |
| HIPAA-164.312.a.2.ii | Emergency Access Procedure | informative |
| 5.30 | ICT readiness for business continuity | informative |
| NIS2-Art.21.2.c | Business Continuity and Crisis Management | informative |
| NIS2-CIR-4.1 | Business Continuity and Disaster Recovery Plan | informative |
| CP-10 | System Recovery and Reconstitution | full |
| CP-10(2) | System Recovery and Reconstitution | Transaction Recovery | full |
| A1.2 | Environmental Protections, Software, Data Back-Up Processes, and Recovery Infrastructure | partial |
Evidence (3)
Documented Disaster Recovery Plan defining recovery sequences, responsible roles, and technical restoration procedures for critical IT systems and services.
Example: Disaster Recovery Plan document (version-controlled, approved within last 12 months) including system recovery runbooks, failover procedures, and backup restoration steps for each critical service
Test: Request the current DRP. Verify: (1) recovery procedures are defined for each critical system; (2) roles and responsibilities are named with current contact information; (3) the plan references technical restoration procedures (backup locations, failover targets, recovery commands); (4) the document has been reviewed and approved within the last 12 months.
DRP review record showing the plan was formally updated following the last DR test or annual review cycle.
Example: DRP version history or change log showing last update date, reason for update, and approver sign-off, particularly confirming updates made after the most recent DR test
Test: Request the DRP version history and most recent review record. Verify: (1) the DRP was reviewed within the last 12 months; (2) lessons from the most recent DR test are reflected in the current version; (3) a named approver signed off the current version.
Recovery test record for a transaction-based system showing the point of consistency reached and the transactions replayed or rolled back.
Example: DR test report, billing service restore, 2026-04-18
Test: Request the most recent recovery test record for a transaction-based system. Verify: (1) the test restored a transaction-based system rather than a stateless one, (2) the record states the recovery point achieved and compares it with the recovery point objective, (3) transactions in flight at the failure point are shown as replayed or rolled back with none left partially applied, (4) a consistency check was run against the recovered data and its result recorded, (5) the procedure used the journal or write-ahead log rather than the last full backup alone.
Questions (2)
Does your organisation have a documented disaster recovery plan?
The DRP is distinct from the BCP: it should contain specific technical runbooks for recovering each critical system from backup or failover infrastructure.
What does the Disaster Recovery Plan include?
Options run from the most commonly present to the least. A plan carrying only high-level guidance is not usable under pressure. Transaction recovery is the element most often absent: restoring the last snapshot brings a system back running while leaving in-flight transactions half applied, so the service is available and the data is wrong.