The CTO saw it first in the weekly dashboard: median inference latency had drifted from 1.4 to 2.8 seconds over three weeks. No alerts. No incident. The provider's status page was green. But two days later, the internal eval suite came back. Contract extraction quality had
Executive summary Introduction Introduction: Why now ? The benefits of digital preparedness How this guide is meant to be used The threats you are preparing for Choosing your posture Operational runbooks 1. Communication when everything is down 2. Identity and access survival 3. Define Minimum Survivable Service (MSS) 4. Vendor, supply
Why now ? 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. * In 2024, multiple undersea internet cables were sabotaged in the Baltic
Digital preparedness starts from a pragmatic assumption: serious digital disruptions are possible, even if they never materialize. The value of preparedness therefore exists in two very different futures: one where a disruption happens, and one where it does not. And both futures generate tangible benefits. When a disruption happens If
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
Not all disruptions are the same. Companies that prepare for "cloud going down" as a single scenario are preparing for the wrong thing. Disruptions differ in speed (how fast they hit), warning (whether you see them coming), duration (hours vs. months), reversibility (whether the situation resolves itself), and
The Shock started with a strange silence. No alarms. No obvious outage. The corporate chat was unusually quiet. Messages were typed, sent, and stayed there. Emails piled up in outboxes, unsent. People assumed a minor network issue. A local disruption. Something transient. After all, a handful of websites were still
The Shock happened four hours ago - and nothing works. Not because systems are down, but because access is gone. Nearly everything sits behind the company’s single sign-on. The corporate email is unreachable. The internal messaging system does not open. Desktop phones across the office are silent - because
When every alarm goes off in the cockpit, a pilot doesn’t try to fix everything. They do one thing: keep the aircraft flying.
Sixteen hours after the Shock, recovery has ground to a halt. At first, progress was real. A few internal services responded again. Some systems that had gone dark now answer health checks. The IT team thought the worst was behind them. Then recovery stalled. The nightly database snapshots had completed
The IT team has not gone home. They worked through the night, sleeping in turns, living on bad coffee and adrenaline. By morning, the situation looks finally better. Many systems respond again. Then people start opening applications. The ERP loads, no error. But it’s impossible not to notice it’
Twenty-four hours after the Shock, the mood briefly shifts. Against all odds, the IT team had made real progress. A regional provider was identified. Accounts were opened. Networks recreated. Containers pulled. One by one, core services start responding again. It is slower than before, rougher, missing pieces - but alive.