A large cloud outage would not look like one failure. It would look like many small ones: logins failing, builds that cannot fetch packages, dashboards going blank and support tools going down at the same moment. Prepare by mapping your dependencies, setting recovery goals, planning manual fallbacks and rehearsing them.
What would you actually notice first?
Probably not your main application. Teams usually notice the layers around it. Identity providers may stop issuing tokens, so staff cannot sign in to the tools they need to respond. DNS or certificate services may fail. Continuous integration may stall because it cannot reach a source host or package registry. Monitoring and chat, which you would use to coordinate, may be down too. Customers see errors, and your status page may sit on the same provider as the thing that broke.
None of this predicts when an outage will happen or how long it would last. Nobody can say that, and a plan should not depend on a guess. The point is to decide in advance what you will do.
What does the official guidance say?
NIST SP 800-34, the guide to contingency planning for information systems, is written to help organizations understand the purpose, process and format of contingency planning, and to evaluate systems to determine recovery requirements and priorities. In plain terms: decide which systems matter most, how long you can be without each, and what you will do meanwhile.
The EU's NIS2 directive lists business continuity, with backup management, disaster recovery and crisis management, among the measures in-scope entities must have, and lists supply chain security alongside it. Even if you are not in scope, it is a useful checklist. AWS's Well-Architected reliability guidance, a vendor's own design advice, describes the same underlying idea: avoid single points of failure and have proven recovery processes. Read your own provider's guidance for the services you use.
How do you map your dependencies?
For each critical service, write down what it needs to run and what you need to fix it.
- Compute and data: Which region, which provider, which managed services?
- Identity: Where do staff and customers sign in? Is there a break glass account that does not depend on the provider?
- Network: Who runs DNS? Where do certificates come from?
- Build and release: Where does source live? Which package registries, container registries and artifact stores does a build pull from?
- Operations: Where are monitoring, alerting, logging, paging and chat hosted?
- Third parties: Which SaaS tools do you need during an incident, and which cloud do they run on?
You will find shared fates. Two tools that look independent may run on one provider.
What about the software supply chain?
If you cannot build or deploy during an outage, you cannot ship a fix. Keep a local mirror or cache of the packages and base images you depend on, and know which version of each you ship. A software bill of materials per release tells you what you are running. Safeguard supports SaaS, private VPC, on premises and air-gapped deployment, which matters if your security tooling itself must keep working when external services do not. Check that whatever you use has a documented offline mode.
What to do
- List your five most critical services and agree how long each can be down.
- Map each service's dependencies, including identity, DNS, build and monitoring.
- Create break glass access that does not rely on your main identity provider, and test it.
- Keep an out-of-band way to reach staff and customers, such as a status page on a separate provider and a phone tree.
- Mirror critical packages and images, and record what you ship in an SBOM.
- Back up data to a separate account or provider, and test a restore on a schedule.
- Write manual fallbacks for the top customer journeys, such as taking orders by phone.
- Run a tabletop where one major provider is unavailable, then fix the gaps it reveals.
- Decide in advance who can declare an incident, who speaks to customers and who decides to fail over.
Quick check
Should every company run on two clouds?
Not necessarily. Multi-cloud adds cost and complexity. First remove single points of failure inside your design, test restores, and rehearse. Then decide whether the business case for a second provider is real.
Can we predict when a global outage will happen?
No. Plan for the consequences, such as lost login, builds and monitoring, and not for a date.
Sources
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
- Directive (EU) 2022/2555 (NIS2), Article 21
- AWS Well-Architected Framework: Reliability Pillar
Last reviewed: 18 October 2026.
