November 12, 2026
Last week, Google Cloud London had a wobble and, like clockwork, a lot of businesses were reminded of an awkward truth: renting world-class infrastructure does not magically make your business resilient.
That is the cloud fantasy some teams still cling to. Stick it on a big-name platform, tick the 'business continuity' box, and off we go. Lovely story. Completely false.
The Google Cloud London outage, covered by Computer Weekly, is a useful wake-up call for IT leaders, founders and operational heads who may have quietly mistaken platform resilience for organisational resilience. They are not the same thing. Not even close.
If your systems can survive but your people do not know what to do, your suppliers are tangled, your communications stall and every big decision needs three layers of approval, you do not have resilience. You have expensive optimism.
This is the big one.
Cloud providers are very good at selling the idea of robustness. Multiple zones, redundancy, failover, high availability, all the lovely phrases that make boards nod approvingly. And to be fair, much of that engineering is genuinely impressive.
But a business does not fail only when servers go down.
A business fails operationally when:
The outage is just the spark. The real fire is usually hiding in your dependency map, your escalation process, and that dusty continuity plan no one has looked at since someone last said 'post-Covid hybrid transformation' with a straight face.
Most organisations think they understand their critical dependencies.
Most organisations are wrong.
What they usually have is a partial map of technology dependencies, scattered across architecture diagrams, tribal knowledge and one very stressed infrastructure lead's brain. That is not a continuity strategy. That is a liability with a SharePoint folder.
If one cloud region goes down, can you answer these questions in under ten minutes?
If the answer is 'we would need to investigate', then your business continuity posture is not mature. It is hopeful.
And hope, while lovely in a children’s book, is not a recovery plan.
Here is where many continuity strategies get weirdly polite.
Organisations spend months designing technical failover pathways, but almost no time deciding who actually has the authority to trigger them when the pressure is on.
That matters more than people think.
Because in a real outage, technical clarity is only half the battle. Decision clarity is the bit that saves you.
I have seen situations where teams knew the backup path, knew the risk, knew the customer impact, and still sat in limbo because nobody wanted to make the call without senior sign-off. Meanwhile, the clock kept ticking, Slack kept melting, and customers were getting twitchy.
You need pre-agreed authority.
Not vague consensus. Not a committee. Not 'let us just wait five more minutes'.
You need a named person, a backup named person, and a clear threshold for action.
Ask yourself:
If those answers are fuzzy, your failover plan is basically a screenplay. Looks brilliant until someone tries to perform it live.
This one deserves to be said plainly.
If your continuity plan has never been pressure-tested in a realistic scenario, then you do not know if it works.
You merely know it exists.
And plenty of bad plans exist very neatly in PDFs.
The outage lesson from Google Cloud London is not simply 'have backups'. It is 'rehearse the mess'.
Run simulations. Throw in ambiguity. Remove the obvious leader from the scenario. Assume key channels are unavailable. Force teams to communicate like adults under pressure, not like idealised boxes on a flowchart.
Good testing reveals things people would rather not discover:
That is good news, by the way. Embarrassing in the room, yes. Expensive during a real outage, much more so.
Too often, business continuity gets delegated downward and isolated inside IT. That is a mistake.
An outage is not just a technical event. It is an operational, commercial and reputational event.
If customer success cannot respond, finance cannot process, legal cannot advise, marketing cannot communicate and leadership cannot prioritise, then the problem is bigger than infrastructure.
This is why the best continuity planning is cross-functional.
It brings together:
Because the question is not simply 'can the system recover?'
The real question is 'can the business continue making sensible decisions while the system is degraded?'
That is leadership. Full stop.
If you want a practical way to tighten your response, start here. I call it the MAP test:
Map the dependencies behind every critical business service. Not just infrastructure, but people, vendors, workflows and communications.
Assign clear authority for incident declaration, failover, customer comms and operational prioritisation.
Practise realistic scenarios regularly. Not performative tabletop sessions where everyone already knows the answer. Proper drills with friction.
It is not glamorous. Nobody is posting a selfie with a dependency matrix. But this is the boring stuff that keeps businesses upright when the lights flicker.
If this outage has prompted a mild sense of dread, good. Use it.
Here are five actions worth taking now:
None of this requires panic. It requires honesty.
Because the companies that handle outages best are rarely the ones with the slickest architecture diagrams. They are the ones that have done the grown-up work of deciding what matters, who decides, and how the business behaves when technology stops being cooperative.
The Google Cloud London outage, reported by Computer Weekly, is not a scandal. Outages happen. The real issue is what they expose.
They expose businesses that have outsourced too much thinking to their platforms. They expose continuity plans that are more decorative than operational. And they expose leaders who still treat resilience like a technical feature instead of a business discipline.
Cloud can give you excellent infrastructure resilience. It cannot give you business resilience by osmosis.
That bit is still your job.
Source: Computer Weekly, 'Google Cloud London outage: Continuity lessons for IT leaders' https://www.computerweekly.com/news/366654732/Google-Cloud-London-outage-Continuity-lessons-for-IT-leaders