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.
Two days after the Shock, the CTO declared the infrastructure stabilized. Core services were limping along on a regional provider. Customer data had been restored from offline backups. For the first time, the leadership team exhaled. But the panic was still real in the finance departement. Six months earlier, the
The Shock happened thirty-six hours ago. The infrastructure team has stabilized the core systems. A few services are responding again. Leadership exhales. Then the CFO calls. Payroll is due in two days. The finance team has moved to a backup system and can technically process payments. But the bank is
For companies
The CEO of the medtech company had always been proud of the IP portfolio. Fourteen patents were defending its revolutionary medical device set to launch this year. Four years of R&D, protected and documented. But eight days after the Shock, the CEO discovered how little of it was
Four days after the shock, the leadership team felt something close to relief. Core systems were back online, and most customer data was intact. The crisis, it seemed, was becoming a recovery. But on the same day, India announced it was aligning with the US sanctions framework. Why did it
For companies
The Shock happened on a Friday. Over the weekend, the leadership team focused on infrastructure, data, and communication. By Sunday evening, the CTO had sent an update through the emergency channel: core systems were being stabilized, and the team should plan to be in the office Monday morning for coordinated
Book
The preceding chapters of this guide each produce concrete deliverables: contact lists, dependency maps, authority packs, compliance calendars, exit playbooks, employee registries. Each is valuable on its own. Together, they represent the raw material of recovery. But in a crisis, the gap between “we have this documented somewhere” and “we
For companies
As geopolitical tensions, sanctions, and legal extraterritoriality increasingly affect digital infrastructure, the concept of software sovereignty has moved from theory to operational necessity. Organizations are no longer asking only whether a tool is secure or compliant, but whether they will retain access and control under all circumstances. This questionnaire proposes