8.2 Business Continuity & Disaster Recovery (Domain 3.5)

Business Continuity and Disaster Recovery

Domain 3.5 requires you to plan Business Continuity (BC) and Disaster Recovery (DR) in cloud contexts. Domain 1.4 introduced BC/DR as a secure-design principle grounded in Business Impact Analysis (BIA). Domain 3.5 deepens the operational planning: strategy, business requirements (RTO, RPO, recovery service level), and creation, implementation, and testing of the plan—expressed with cloud building blocks such as multi-AZ/region deployment, backups, and failover.

BC vs DR (Exam Clarity)

HA reduces the chance that a single disk or AZ failure becomes a “disaster.” BC/DR plans address scenarios HA alone cannot: full region loss, ransomware encrypting production and online backups, prolonged identity-provider outage, or supply-chain failure of a critical SaaS dependency. CCSP wants you to choose the right layer for the failure mode in the stem.

BC/DR Strategy

A strategy is the high-level approach linking business priorities to technical patterns and investment. Strategy is not a vendor feature checklist.

Strategy inputs:

1. Business Impact Analysis (BIA) — process criticality, financial/safety/regulatory impact over time, dependency maps.
2. Risk scenarios — regional outage, cyber attack, insider sabotage, data corruption, CSP control-plane event, network partition, pandemic staffing loss, third-party SaaS failure.
3. Constraints — budget, skill, data residency, contractual SLAs with your customers, recovery site jurisdictions.
4. Service model mix — IaaS rebuild flexibility vs SaaS reliance on vendor recovery commitments.

Strategy principles for cloud:

• Design for failure domains (disk → host → rack → AZ → region → global services).
• Prefer automation and infrastructure-as-code so recovery is repeatable under stress.
• Include people and process: who declares a disaster, who talks to customers/regulators, how you communicate when email is down.
• Address dependencies outside your VPC: DNS, identity, certificate authorities, payment gateways, package registries, observability SaaS.
• Plan failback, not only failover—how and when production returns to the primary environment.
• Align strategy with contracts and SLAs you sell to your customers; your internal RTO cannot be weaker than external commitments without risk acceptance.

Exam trap: Selecting active-active global design for a low-criticality internal wiki because “cloud makes it easy,” ignoring cost and complexity. Strategy is proportionate to BIA.

Business Requirements: RTO, RPO, and Recovery Service Level

These three requirements translate business pain into engineering targets. Memorize definitions and relationships.

Worked Relationships

• A trading API with RTO = 15 minutes and RPO = 0–1 minute cannot rely on nightly backups alone; it needs continuous replication or synchronous patterns and automated failover.
• A monthly reporting warehouse with RTO = 72 hours and RPO = 24 hours may use daily backups and rebuild automation—multi-region active-active is usually waste.
• Recovery service level at 50% capacity within RTO may allow a smaller warm standby that scales out after failover, reducing steady-state cost.

Related Terms (Useful Distinctions)

Setting Requirements

1. Inventory critical processes and supporting applications/data stores.
2. Quantify impact curves (hourly loss, regulatory clocks, safety).
3. Assign RTO/RPO/recovery service level per process, not one global number for the entire enterprise.
4. Map technical dependencies—if identity RTO is 4 hours but the app RTO is 15 minutes, the identity tier is misaligned.
5. Document assumptions (for example, “DNS TTLs are 60 seconds”; “CSP regional API is available”).
6. Obtain business owner acceptance; security/engineering cannot invent RTOs in isolation.

Cloud-specific requirement pitfalls:

• Counting only compute restore time while ignoring DNS propagation, certificate rebinding, secret retrieval, and cold-start data rehydration.
• Setting RPO of zero without accepting the cost and latency of synchronous multi-region writes.
• Assuming multi-AZ deployment meets a multi-region RTO requirement—AZs share regional fate for some failure classes.
• Ignoring logical corruption and ransomware: replication can faithfully replicate bad states; RPO for clean data may require versioned or immutable recovery points older than the last replication.

Recovery service level examples:

• E-commerce: checkout and payments at 100% within RTO; recommendations engine degraded.
• Healthcare scheduling: read of appointments within RTO; new analytics jobs deferred.
• Manufacturing MES: production line control first; historical reporting later.

Write these priorities into the plan so responders do not waste the RTO window restoring low-value services first.

Creation, Implementation, and Testing of the Plan

Creation

A usable BC/DR plan is a controlled document set, not a slide deck. Typical contents:

Cloud plan creation extras: account/subscription IDs, regions, infrastructure-as-code repositories, image pipelines, key-management recovery (who can unlock CMKs if the primary region identity path fails), and break-glass procedures that still preserve auditability.

Implementation

Implementation turns the document into deployed capability:

• Provision DR accounts/regions, networking, and identity trust before a crisis.
• Configure backup jobs, replication, and retention aligned to RPO—including backup immutability or offline copies for cyber scenarios.
• Automate recovery with infrastructure-as-code, golden images, and tested pipelines.
• Pre-stage secrets and certificates or define secure retrieval that works during outage.
• Train staff; ensure more than one person can execute each critical runbook.
• Align monitoring and alerting so declaration criteria are observable (health checks, synthetic transactions, RPO lag alarms).

Implementation anti-patterns: DR region never receives configuration updates (config drift); backups succeed but restore is never practiced; multi-region database is configured with replication lag exceeding RPO without alarms; runbooks live only on the primary file share that is unavailable during the outage.

Testing

Untested plans are hypotheses. Testing maturity ladder:

Testing governance: schedule tests on a calendar tied to risk; document results, gaps, and remediation; retest after major architecture changes; include third-party dependencies when contracts allow. Measure actual time-to-recover and data-loss window against RTO/RPO—do not pass a test that “mostly worked” without metrics.

Exam keywords: if a stem says backups exist but the organization has never restored them, the correct improvement is testing/restore validation, not buying a third region by default.

Cloud-Specific Patterns: Multi-AZ/Region, Backups, and Failover

Multi-AZ and Multi-Region

Design notes:

• Place redundant instances and data stores across AZs for production tiers that need HA.
• Use health checks and load balancers so failed nodes leave the pool automatically.
• For multi-region, decide data consistency model early (async replication implies nonzero RPO).
• Remember global services (some identity, DNS, or CDN control planes) may have different failure modes than regional compute.
• Data residency rules may forbid certain multi-region placements—strategy must respect law and contract.

Backups and Replication

3-2-1 style thinking still applies in cloud: multiple copies, multiple locations/media classes, and at least one copy insulated from production credentials. Replication alone is not backup if ransomware or bad admin deletes or encrypts all replicas through the same identity.

Failover

Failover is the act of shifting traffic and processing to a surviving environment.

Automation vs human control: Highly practiced AZ failover is often automated. Full-region or cyber DR may keep a human in the loop to avoid catastrophic split-brain or premature declaration. Document both paths.

Integrated Scenario

A payments platform BIA sets RTO 30 minutes, RPO 5 minutes, recovery service level 100% authorization path / 50% reporting. Strategy: multi-AZ active in primary region, warm standby in a second region with continuous async replication (lag alarmed at 3 minutes), immutable daily backups in a separate account for cyber recovery, automated AZ failover, and semi-automated regional failover with executive declaration. Quarterly restore tests measure actual RTO; tabletop exercises cover ransomware declaring primary and online replicas unsafe. That design maps strategy → requirements → implementation → testing without blindly enabling every product feature.

Exam Approach and Common Traps

1. Extract RTO, RPO, and recovery service level (or infer from business impact).
2. Match pattern heat (backup/rebuild vs warm vs hot) to those numbers and cost.
3. Ask whether the failure is AZ, region, cyber, or dependency—pattern must fit.
4. Prefer answers that include testing when capability is claimed but unproven.
5. Include identity, DNS, and backups isolation in multi-region thinking.

Common traps:

• Equating multi-AZ with multi-region disaster survival.
• Treating CSP SLA credits as a BC plan.
• Replicating ransomware to the DR site with no immutable recovery point.
• Writing plans that only restore IT but ignore recovery service level and business validation (WRT).
• Never testing restores because “the backup job shows green.”