This guide is for the active disruption: a SaaS platform is unavailable, a cloud region is impaired, the provider control plane cannot be used, or a shared identity/DNS dependency prevents access. Its purpose is to help the incident team decide when to invoke continuity, what to recover first, and how to prove that the business service—not just the infrastructure—has returned.
1. Confirm impact using independent evidence
Do not wait for a provider status page to become the sole source of truth. Correlate user reports, synthetic monitoring, transaction failures, network telemetry, identity events and provider communications. Record the first known business impact time because recovery performance should be measured from disruption or authorized invocation, not from when a technical team starts work.
2. Classify the failure domain
| Failure | Immediate challenge | Decision |
|---|---|---|
| Single workload/service | Local dependency or deployment? | Recover locally or invoke continuity. |
| Region/availability domain | Are replicas and dependencies truly independent? | Fail over only when prerequisites and capacity are proven. |
| Control plane | Can administrators change routing, scale or recover? | Use pre-authorized runbooks and break-glass access. |
| Identity/DNS/network | Healthy workloads may still be unusable. | Invoke dependency-specific fallback before moving workloads. |
| SaaS provider | Customer cannot repair platform internals. | Activate business workaround and supplier escalation. |
3. Invoke against explicit thresholds
Use the approved disruption tolerance, current demand, estimated provider restoration time, workaround capacity and risk of failover. Name the authority who can invoke a degraded mode or technical recovery. If evidence is uncertain, record the assumption and next decision time in the crisis decision log rather than allowing an undocumented wait-and-see posture.
4. Protect access and shared dependencies
Before failover, verify identity, privileged access, DNS, certificates/keys, network paths, secrets, data replication and critical third parties. A secondary environment that relies on the failed identity tenant or control plane is not independent. Test break-glass access under controlled conditions before incidents.
5. Recover in business-service stages
Use explicit stages such as minimum service → stabilized service → normal service. For each stage define required components, data currency, transaction integrity, throughput, security controls, interfaces and business acceptance. Do not declare recovery merely because servers are healthy.
6. Validate with business transactions
Business representatives should execute agreed transactions and confirm outputs, integrations and data. Measure backlog and failed/queued messages. If recovery creates duplicate or missing transactions, keep the service in a controlled state until reconciliation rules are applied.
Worked outage decision
A regional failure makes the primary application unreachable. The alternate environment is technically ready in 40 minutes, but identity federation remains dependent on the affected region. The incident commander does not declare recovery. Break-glass access is enabled for a limited operations group, the business moves to its 35% minimum-service mode, and customer-impacting transactions are prioritized. Full service is declared only after identity, integrations and reconciliation checks pass. The measured recovery time therefore reflects the business outcome, not the first healthy server.
7. Return to normal deliberately
Define who authorizes failback, how data divergence is reconciled, what queued transactions are replayed, how DNS/routing changes are reversed and what monitoring period is required. Preserve timestamps and decisions for the post-incident review. A hurried return can create a second outage.
Evidence to retain
- Impact timeline and independent detection evidence.
- Invocation decision, authority and assumptions.
- Actual failover/workaround timings and capacity.
- Business transaction validation and reconciliation results.
- Provider communications and dependency findings.
- Lessons, owners and due dates for capability gaps.
Prepare before the incident
For shared-responsibility analysis, SaaS/PaaS continuity design, data portability, concentration risk and minimum operating modes before an outage occurs, use Cloud Service Continuity.
Separate provider recovery from customer recovery
A provider status page can return to green while the customer service remains unavailable because identity, private connectivity, integrations, caches, queues or tenant-specific configuration has not recovered. Track two timelines: provider restoration and your own end-to-end business restoration. Use the latter for RTO evidence and incident closure. This prevents optimistic recovery reporting based on infrastructure signals that users cannot yet consume.
Predefine cloud outage decision thresholds
Specify when the team waits for provider restoration, activates a degraded mode, fails to another region, invokes an alternate SaaS process or suspends transactions to protect integrity. Thresholds should consider elapsed outage time, provider confidence, data replication lag, recovery complexity, customer consequence and the remaining time before business tolerance is breached. Assign decision authority before the incident so teams do not improvise high-risk failover choices under pressure.
Exercise identity and control-plane failure
Many cloud designs assume the application region fails while global identity and administration remain available. Test the opposite. Remove normal federated sign-in or privileged control-plane access and verify emergency identities, credential custody, approval, logging and revocation. Confirm that responders can reach the alternate environment through an independent path and that break-glass access does not become a permanent uncontrolled bypass.
Validate data protection before traffic moves
Before failover, determine the latest consistent recovery point and the business consequence of missing or duplicated transactions. After failover, reconcile high-value records across systems of record, queues and external partners. If replication is asynchronous, measure actual data loss against RPO rather than assuming configured replication equals achieved protection. Define who can accept residual loss and when customer or regulatory notification is required.
Prove capacity and sustained operation
A standby environment that starts successfully may still fail under real demand. Test representative transaction volume, integration throughput, batch workload, observability and operational staffing for the expected outage duration. Include backlog growth and catch-up after restoration. Acceptance should cover minimum business capacity for long enough to demonstrate stability, not merely a short technical smoke test.
Revalidate after cloud change
Trigger targeted continuity review after region expansion, identity redesign, network changes, managed-service upgrades, new SaaS dependencies, major data architecture changes or provider contract changes. Link each change to affected runbooks, diagrams, recovery evidence and assumptions. Cloud resilience is a maintained capability; a successful test from a previous architecture should not be treated as current evidence.
Related BCM.Center resources: Cloud Service Continuity: SaaS, PaaS and Shared-Responsibility Planning.
Practical scenario: if a primary cloud region becomes unavailable during a critical processing window, the continuity owner should compare the approved recovery objective with the latest dependency evidence, confirm which services can fail over independently, and record the decision to invoke, defer, or use a manual workaround. A useful exercise is to test identity, DNS, secrets, integration queues and data-reconciliation steps rather than assuming that a compute failover alone proves continuity.