How this guide is meant to be used (read this first)

For more than a decade, companies have built on the assumption that major cloud providers are effectively permanent utilities: always available, globally reachable, and politically neutral.

In the past months, each of those assumptions has been challenged. On November 18th 2025, Cloudflare suffered a global outage that briefly broke a huge slice of the internet. Some estimates suggested that roughly one in five webpages were affected at the height of the incident. On November 19th, six judges and three prosecutors at the International Criminal Court were sanctioned by the Trump administration, locking them out of numerous digital services (Paypal, Apple Pay, Amazon…). The European Union is rumored to be preparing sanctions against major American technology companies, banks and financial institutions if the United States refuses to withdraw its renewed claims over Greenland.

This guide exists because the operating environment is changing. Digital infrastructure is no longer just a technical dependency. It is a strategic risk surface shaped by technology, law, economics, and geopolitics. 

The goal of this guide is not to predict the next crisis. It is to help you ensure that when something unexpected but plausible happens, your company retains:

• the capacity to communicate,
• control over its data,
• the ability to operate in degraded mode,
• and the freedom to make deliberate decisions instead of emergency guesses.

Digital preparedness is no longer an advanced concern for regulated industries or critical infrastructure providers. It is becoming a baseline operational discipline for any company that expects to exist in a world where access to cloud services can no longer be taken for granted.

This is a tactical guide

This document is intentionally practical. It focuses on:

• decisions you must make before a disruption,
• actions you must take during a disruption,
• and capabilities you must retain after a disruption.

You will not find generic advice about “being resilient” or “embracing multi-cloud”. Instead, each chapter is designed to produce explicit deliverables: documents, checklists, configurations, or runbooks that materially improve your ability to operate under constraint.

If a section does not result in something you can point to (a table, a plan, a tested procedure) then it has not been applied correctly.

This guide is deliberately narrow in scope. It is not:

• a theoretical discussion of cloud architecture,
• a compliance or certification framework,
• a business continuity plan written for auditors,
• or a manifesto against hyperscalers.

It does not assume that you want to leave the cloud, run everything on-premise, or build a perfectly redundant system. It assumes the opposite: that you are using major cloud providers today, and that you will continue to do so. The goal is not perfection. The goal is survivability.

The core assumption

This guide starts from a simple but uncomfortable assumption: At some point, you may durably lose access to the main cloud providers, and undergo a cascading failure of cloud-dependent SaaS tools. This guide helps you prepare for that moment.

Digital preparedness does not mean that everything keeps working. It means that enough works. Throughout this guide, you will be asked to define your Minimum Survivable Service : the smallest version of your product and organization that must continue operating to avoid irreversible damage.

That may mean degraded performance, reduced functionality, manual processes or delayed recovery. But a degraded service that preserves customer trust, data access, and decision-making capacity is vastly preferable to a complete shutdown.

How is this different from ISO-27001 or SOC2 ?

A lot of companies are now following the ISO-27001 or SOC2 best practices. There is an overlap with digital preparedness, but there is a core difference in the threat model. 

ISO27001 aims to protect information against accidental, malicious, or internal failures while assuming the continued availability of the global cloud ecosystem. It answers questions like:

• Are systems hardened and access controlled?
• Can we prevent or detect breaches?
• Are changes, incidents, and risks managed in a disciplined way?

It’s about risk reduction inside a stable operating environment that can be quickly restored.

Digital preparedness aims to ensure business continuity and sovereignty in case a systemic, external, and political disruption occurs. It answers questions like:

• What if AWS, Azure, GCP become legally, technically, or commercially unavailable overnight?
• What if access is restricted due to sanctions, export controls, or diplomatic escalation?
• What if US-based providers are forced to suspend services to EU customers?

This is about survivability when the environment itself durably collapses or fractures.

Many organizations believe they are “safe” because they are, ISO 27001 certified, SOC 2 compliant or hosted in EU regions of US clouds

In a geopolitical shock scenario, certifications do not grant access, SLAs do not override sanctions and contracts do not stop executive orders. Preparedness is about what remains true when paperwork stops working.

How to read and apply this guide

This guide is structured to be applied incrementally. Founders and CTOs can read it end-to-end to understand the full risk surface. Leadership teams can assign chapters as concrete work items. 

Each chapter contains:

• a clear objective,
• a description of the risk being addressed,
• and one or more explicit deliverables.

You should measure progress by completed deliverables, not by theoretical understanding. You should pause after each chapter and ask one question: “Do we already have this, documented and tested?”. If the answer is no, stop reading and create it.

Digital preparedness is not something you finish in a week. It is something you build progressively, validate periodically, and maintain deliberately. Individual sections should be revisited as the company grows.

A final word on tone and intent

This guide is not alarmist. It does not assume catastrophic collapse, nor does it predict the end of the cloud.

It is written from the perspective of operators who understand that complex systems fail in unexpected ways, dependencies accumulate silently,and recovery is always harder than planned. Preparedness is not about fear. It is about retaining agency when constraints appear.

If this guide helps you make one better decision before a crisis, it will have done its job.