Business Continuity and Disaster Recovery
This domain tests whether you can separate business continuity from disaster recovery, derive recovery objectives from a business impact analysis, and select, document, test and maintain recovery strategies. EDRP questions here are scenario-heavy: they give you an outage, a metric or a plan gap and ask what should happen next.
Two disciplines, one lifecycle
- Business continuity (BC) keeps critical business functions delivering through disruption; disaster recovery (DR) restores technology, data and infrastructure. The BCP is the umbrella; the DRP is a supporting plan focused on IT.
- Lifecycle: risk assessment → BIA → strategy selection → plan development → testing and exercising → maintenance. The BIA precedes strategy: any answer that picks a hot site before quantifying impact is out of order.
Metrics that answer different questions
- MTD: longest outage the business tolerates before unacceptable harm.
- RTO: target time to restore the function or technology after disruption.
- WRT: time to verify, catch up and return to normal operations once systems are restored.
- RPO: acceptable data loss, expressed as time since the last recoverable copy.
- Relationship: RTO + WRT ≤ MTD. Tighter RPO costs more: synchronous mirroring is more expensive than hourly replication, which is more expensive than nightly backup.
Strategies and validation
- Site options: hot (near-instant, expensive), warm (partial capability, hours), cold (space and power, days), mobile, and mirrored or cloud-based.
- Data options: backups, snapshots, replication (synchronous versus asynchronous), and journaling.
- Also plan manual workarounds, alternate suppliers, crisis communications, declaration authority and succession.
- Test types in increasing realism: checklist review, walkthrough or tabletop, simulation, parallel test, full cutover. Testing should be planned, risk-managed and documented, with corrective actions tracked.
Worked example
Payroll must run every 24 hours. The BIA sets MTD = 24 h. Restoring the payroll application takes 8 h, and verification plus catch-up (WRT) takes 4 h, so RTO must be ≤ 20 h. Payroll can tolerate losing one day of input, so RPO = 24 h. A warm site with a 12 h RTO and nightly offsite backup (24 h RPO) meets both objectives at lower cost than active-active mirroring, which would be over-engineering. If the business later demands RPO = 1 h, the design must change to hourly replication.
Traps that cost marks
- Swapping RTO and RPO: RTO is downtime, RPO is data loss.
- Treating MTD as equal to RTO and forgetting WRT.
- Choosing a recovery strategy before completing the BIA.
- Calling a backup a DR plan; a backup without restore testing and procedures is not recovery.
- Equating a tabletop exercise with a full failover test.
- Forgetting dependencies: DNS, identity, third parties, cloud shared responsibility, staff and call trees.
- Leaving the plan static; triggers for review include technology, application, personnel, vendor and regulatory changes.
- Having no authority to declare a disaster, so response stalls.