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
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.
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’
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
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
When every alarm goes off in the cockpit, a pilot doesn’t try to fix everything. They do one thing: keep the aircraft flying.
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
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
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
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
Introduction: Why now ? The benefits of digital preparedness How this guide is meant to be used 1. Communication when everything is down 2. Identity and access survival 3. Define Minimum Survivable Service (MSS) 4. Vendor, supply chain, and platform dependencies 5. Data preparedness 6. Infrastructure exit strategy 7. Banking, finance,