Business continuity and disaster recovery

A single service outage is an incident. A cloud region loss, a destructive ransomware attack, or a critical vendor failure is bigger than one incident - it threatens the estate's ability to keep operating at all. That is what business-continuity/ covers, and it runs on the same discipline as incident response, one level up.

The chain, in one line

The BC/DR README states the program in one line: BIA decides what matters -> tiers fix RTO/RPO -> backups and DR strategy meet them -> exercises prove it -> evidence goes to WORM. The Business Impact Analysis (BIA) scores each service's impact and derives its MTPD (Maximum Tolerable Period of Disruption); service tiers then assign the smallest tier band whose RTO is always less than MTPD.

Service tiers: RTO/RPO and DR strategy

Four tiers fix how fast a service must return (RTO) and how much data loss is tolerable (RPO), each paired with an AWS Well-Architected DR strategy: tier-0 (mission-critical, RTO <= 1 h, warm standby/multi-site), tier-1 (critical, RTO <= 4 h, pilot light -> warm standby), tier-2 (important, RTO <= 24 h, backup & restore), and tier-3 (standard, RTO <= 72 h, backup & restore/redeploy-from-IaC). The technical design that meets each tier

cross-region replication, PITR, the paired DR region - is the DR plan; the backup mechanics (3-2-1-1-0, immutable/WORM copies, verified restores) are the backup strategy.

Activation: when this stops being a routine incident

The Business Continuity Plan (BCP) is explicit that it does not replace incident response - it escalates from it. A routine incident is handled under incident-response/; the Incident Commander declares BC/DR activation when a tier-0/1 service will breach its RTO, data loss may exceed RPO, a destructive or security event is confirmed, a primary region is lost, or an exercise inject calls for it. As in incident response, the rule when uncertain is to declare: under-declaring costs recovery time.

Recovery order and failback

NOTE

Recovery proceeds in dependency order, not tier-number order alone: the DR plan sequences identity first, then secrets/PKI, then the API/MCP gateway and Core, then observability, then tier-1 products - because nothing else is operable without the layers beneath it.

Recovery is not finished at failover. The BCP requires failback: validate data consistency, drain traffic back to the primary region in a controlled window, confirm SLOs and backups are healthy, then stand down. The test-and-exercise program

tabletops, restore drills, failover drills, and an annual game-day - is what turns every RTO/RPO from a claim into something measured, and every activation, exercise, and restore test is retained as evidence per the retention schedule.