Three days for households. Ninety for military bases. And for the organisations in between, usually no number at all.
By Louize Clark
Last Wednesday, websites across Britain started going dark. Council websites. The Metropolitan Police. The Office for Budget Responsibility. They hadn't been attacked. Two critical flaws had been found in PHP, a programming language that sits underneath a large share of the world's websites, and the responsible thing for many organisations running affected versions was to switch their own sites off until they could patch them. The flaw, reportedly, was found by a researcher using AI.
That detail matters more than it first appears. Sometimes disruption doesn't come from an attacker at all. It comes from the sensible security decision to stop using something before an attacker can.
The following day, the UK government launched Be Ready, a three-year campaign asking every household to be able to manage for three days without electricity, water, phones or the internet. Bottled water. Food that doesn't need cooking. Cash, a torch, a wind-up radio. Within days, the government was pointing to that week's outage as proof of the point.
Yesterday, Japan's disaster management minister said households should be ready for at least three days, and ideally a week, ahead of a formal national request on 2 November.
And in the United States, the Pentagon launched FORTRESS America on 30 September, a programme to help its military installations generate their own power and secure their own supplies. Planning documents reported by Fox News on Sunday, which haven't been published, go further. They describe a requirement for every major base in the continental US to be able to operate for ninety days without civilian power, fuel, water or supply lines. That is a reported planning requirement rather than an adopted standard, and it should be read that way. But the Pentagon's chief spokesman, Sean Parnell, didn't play down the reasoning: "Power is combat now."
Three days. A week. Ninety days.
Three governments, three numbers, and one shared assumption sitting quietly underneath all of them: the systems we rely on every day may not always be there.
I want to be careful here, because this is exactly the kind of moment that invites alarm, and alarm isn't what's needed. These campaigns aren't predictions. Japan has asked its households to keep supplies for years. UK ministers have been at pains to say this is about being alert, not alarmed. Planning for the worst case is precisely what responsible institutions are supposed to do, and nothing here argues otherwise.
But I've spent the past week looking at those three numbers, and I think there is a question missing from all of them.
They tell households what to do. They tell the military what to do. Almost nobody is asking what the organisations in between, the businesses, councils, care providers, accountancy practices and logistics firms that actually keep a country running day to day, should be able to do when the technology goes quiet.
I don't mean whether they have a continuity plan. Many do, and some are very good. I mean whether they could still operate: whether their people could keep doing the essential work while the systems they normally rely on are unavailable.
The ninety-day number isn't really about the military
The Pentagon's number is the one I keep coming back to, and not because of its scale.
Read the reporting closely and the central concern isn't troops or weapons. It's the civilian electricity grid. The US military has looked at how much of what it does, its communications, its logistics, the manufacturing it depends on, runs on the same grid as everyone else, and concluded that in a serious conflict it cannot assume that grid will stay up. So it is building its way out: microgrids, large-scale batteries, even small nuclear reactors, so that a base can disconnect and keep running on its own.
It's worth pausing on what that actually means. The best-resourced military in the world has examined its own operational dependency and decided it isn't comfortable with it. Not because the grid is failing. Because it might, and because the moment it matters most is precisely the moment it can least afford to find out.
And notice what the plan protects. It keeps the bases running. It doesn't keep the grid running for everyone else. That isn't a criticism; it's what a defence department is for. But it's a useful reminder of how nations plan for prolonged disruption. Essential functions are protected first. Everyone else is, quite reasonably, asked to keep three days of water in the cupboard.
Now look at where Britain sits
Britain has ambitions to build greater sovereign AI capability, and real strengths to build it on. But much of the technology our organisations already depend upon sits within ecosystems headquartered elsewhere.
The productivity suites most UK organisations run on, the clouds that hold their data, the services that sign their staff in each morning, the AI models now folded into almost all of it: Microsoft, Google, Amazon, OpenAI, Anthropic. Overwhelmingly, these are American companies.
Some of our data sits in UK data centres, and that matters. But where data is stored isn't the same thing as operational independence. Much of what makes a cloud service actually work, the management systems, the sign-in, the software updates, the model behind an AI feature, the engineers who fix it at three in the morning, can be run from, and decided in, somewhere else.
I'm not suggesting those companies are any less resilient for being American, or that a disruption in the United States would switch off British businesses. The Pentagon's planning tells us nothing about that, and it would be overstating something that doesn't need overstating.
What it does is make a more general point visible. British organisations depend on infrastructure, operating decisions and supplier arrangements over which they have limited control, wherever those suppliers happen to be headquartered. Our continuity plans quietly assume someone else's continuity plans. And most of us have never read them.
This is the same thread I pulled at in the sovereign AI paper. Sovereignty isn't only about owning infrastructure. It's about whether you keep the freedom to act. An organisation can own its data, hold contracts with several suppliers and run excellent cyber security, and still be unable to function if the platform it now thinks through goes quiet for a week.
There's a subtler version of this, and it catches out organisations that believe they've already solved it. Imagine a business with two systems capable of doing the same work. On paper, it's resilient: if one supplier fails, there's an alternative.
But if its people have spent years working inside one platform, its processes have been shaped around that platform, and its knowledge is stored in ways that only make sense inside that environment, the alternative may offer very little real independence.
The technology can be replaced. The organisation's ability to use the replacement can't necessarily be restored overnight.
A choice that can't realistically be exercised isn't much of a choice.
Losing access is not the same as losing ability
Think about how ordinary work has changed over the past twenty years.
There was a time when someone in an accounts team understood how an invoice was raised, matched, approved and reconciled, because they physically worked through each step. Today, an invoice arrives, software reads it, matches it to a purchase order, routes it for approval and updates the ledger. Increasingly, AI handles the exceptions as well: it spots the discrepancy, suggests the fix, drafts the email to the supplier.
That's a wonderful development. When it works.
But if that system were unavailable for a week, could the person responsible still do the job? Would they know which checks really mattered, which decisions needed judgement, which figures needed verifying before money moved? Or have we reached the point where people are learning to operate the software without necessarily learning the work the software performs?
It isn't only accounts. Recruitment, logistics, healthcare administration, facilities management, construction. In each, processes that once relied on people understanding a sequence of decisions are increasingly handled through connected systems that make those decisions on their behalf.
There is a difference between losing access to a system and losing the ability to do the work without it. The first is a technology problem: backups, recovery times, failover. Most organisations have at least thought about that. The second is a human problem, and I'm not sure most have.
AI sharpens this in a particular way. Earlier generations of software automated many of the steps and the rules. AI is extending that automation into work that previously depended on interpretation, context and human judgement. And because so much of that capability now arrives inherited rather than chosen, switched on in a routine update to a platform the organisation already trusts, the manual route doesn't disappear in one decision anyone could point to. It thins out, quarter by quarter, until nobody quite remembers it was there.
Recovering the system is not recovering the capability
Most business continuity plans are built to answer one question well: how quickly can we get the system back? Recovery times are measured in hours. Critical applications are ranked. Escalation routes are written down. Quite rightly.
Some organisations, particularly those running critical infrastructure, go further and assess how long their essential services can tolerate disruption. But for many, the number they know is a technical one: how long until the system returns. Not how long their people could keep doing essential work without it.
Now imagine a business whose main operating platform is unavailable for three days. Not hours. Days.
Its IT team may know exactly how to restore it. Its continuity plan may list the affected departments and the expected recovery time. But can the organisation keep delivering its essential services in the meantime? Who knows how to carry out the critical tasks by hand? Who understands the decisions the automated workflow normally makes? Where are the instructions, and can anyone reach them without logging into the very systems that have failed?
There is a difference between having a recovery plan and having the capability to keep operating.
And there's a more uncomfortable possibility still. What if the system comes back, but the people who once understood the underlying process have retired, moved on, or were never trained to do it in the first place?
The organisation has recovered its technology. Has it recovered its capability?
This is really a question about organisational memory. Every organisation has one. Some of it lives in documents and records, but much of it lives in people who understand why things are done a particular way: why a check exists, what went wrong last time, which exception is handled differently and why.
As we automate more of the work, we need to pay attention to whether we're preserving that understanding, or simply preserving the output.
Picture someone joining a business this year. They learn the CRM, the AI assistant, the automated reporting, the workflow that moves work between teams. They become genuinely good at their job. But if nobody teaches them why those processes exist, how the decisions inside them are made, or what to do when the automated route isn't there, what exactly have we trained them to do?
Operate the organisation? Or operate the technology that operates the organisation?
That distinction is going to matter more, not less, as systems become more autonomous.
The organisation's list of phone numbers
There's one item in the household preparedness advice I find quietly brilliant. Keep a written list of important phone numbers. On paper. Because the phone you'd normally look them up on might be flat, or have no signal.
It's a small thing, but it captures the whole idea. Assume the thing you normally rely on won't be there, and keep a version of what matters that doesn't depend on it.
So what's the organisational equivalent?
It isn't filing cabinets. Nobody needs to process every invoice by hand to prove they still can; there's no commercial sense in that. But there is a difference between eliminating unnecessary work and eliminating the capability to perform essential work. Most efficiency decisions are made with only the first in view.
The organisational version of that paper list might start with questions like these:
Which services would we have to keep delivering, even at a reduced level, if our core platforms went quiet for three days? For a week?
Who, by name, still knows how to deliver them without the system, and will they still be here next year?
Where are the instructions, and could anyone reach them offline?
Which decisions does an automated workflow or AI feature currently make for us that a person would have to make instead, and does anyone still know how?
How many of our critical processes ultimately depend on a single provider, and do we understand what sits behind that provider?
Where we would have to stop rather than carry on manually, for safety, security or regulatory reasons, have we decided that in advance, or would we be deciding it in the dark?
For some organisations, the honest answer will be hours. For others, days. Some activities should stop immediately when the systems do, because carrying on manually would create a worse risk than pausing. That's fine, provided those limits are understood and the decisions are made before they're needed.
The concern is discovering them for the first time during a disruption. A backup can restore information. It can't restore experience, judgement or understanding that an organisation has allowed to quietly disappear.
And this doesn't stay inside individual businesses. Supply chains, public services, healthcare and transport all rest on layers of organisations that each depend on further layers of technology. One organisation's inability to operate very quickly becomes somebody else's problem.
How many days could you operate?
As households, we're being asked to prepare for three days without the infrastructure we take for granted. The US military is reportedly planning for ninety. Both numbers are, at heart, an honest admission of operational dependency, and a decision to plan around it rather than hope it's never tested.
Many organisations do have a number of sorts: a recovery time for their systems. Far fewer have the other one. How long their people could keep doing essential work without them.
Not because they're careless. Because nobody has asked them for one, and because the dependency arrived the way it usually does: update by update, feature by feature, one sensible decision at a time, until the technology stopped being something the organisation used and became something it thinks through.
We've spent years asking how much more technology can do for us. As we move into an age of increasingly autonomous systems, perhaps we also need to ask what we're gradually becoming unable to do without it.
So here's the question I'd leave on the table. Not how quickly you could recover your systems. How many days your organisation could actually operate without them.
If the honest answer is "I don't know", that isn't a failure. It's a starting point. But it's a far better one to find on an ordinary morning than in the middle of an outage.
AI Policies UK helps organisations see the AI infrastructure they're already standing on, chosen, inherited and embedded, before decisions like this one have to be made under pressure. Get in touch: Info@aipolicies.uk