Somewhere today, someone stood at a supermarket till while their card was declined. They had the money. The shop had the stock. Neither had done anything wrong.
That is what makes an outage like today's Google Cloud incident so hard to see coming. The people who feel it most are often several steps away from the failure. Readers told the BBC about refused cards, a house move stuck waiting for a mortgage payment, and a small business that could not book its parcels. The chain from their problem back to a power event in a London data centre is long, and almost none of them could have named a single link in it.
What we know, and what we do not
Google says a power event hit its London data centres, first showing on its status dashboard around 07:00 BST. By mid-afternoon it reported most customers mitigated and a very small number still affected, and it has promised an analysis once its investigation is complete. Banks, a delivery firm, court video links and part of the NHS app all felt it.
What we do not yet know is why the power event could not be absorbed, so I will not guess. Google's own reports on earlier incidents describe a familiar pattern: backup power that did not carry the load, cooling that did not restart, a failover that needed a person. We will learn more when this report lands.
Follow the chain
Every service has a chain behind it. A payment depends on a banking app. The app depends on a cloud region. The region depends on a data centre, and the data centre depends on power and cooling that someone else owns. Four or five links down, almost nobody in the business has ever seen it written down.
Recent events show different links giving way:
- The shared platform. A year ago today, an AWS outage in its us-east-1 region lasted over 14 hours and hit thousands of sites and apps. Some AWS services depend on that region themselves, so customers who thought they were spread out found a common thread.
- The supplier's supplier. M&S was reportedly breached through a third-party contractor, and its online orders were off from April to June.
- The facility. Heathrow closed for about 18 hours, and more than 1,300 flights were cancelled after a substation fire, caused by a fault flagged almost seven years earlier.
The diagram shows the shape. Responsibility and visibility thin out as you go down the chain, while the customer at the top feels every link.
Why chains break
Across these cases, three things arise repeatedly.
Redundancy that has never been proven. Google's reports on earlier incidents describe backup power that did not carry the load, a server row that failed to switch to its second power feed, and cooling pumps that did not restart. Redundancy only counts once it has been tested under real failure.
Known risks left open. The Heathrow investigation found a moisture reading in the substation's oil samples in 2018, a decision in 2022 to defer basic maintenance, and a 2024 fire risk assessment saying a transformer fire would not be suitably suppressed. That action was still open when the fire came.
Recovery time is the real cost. M&S's online orders were out for about two months, and the direct cost came to around £136m, with about £100m covered by insurance. JLR stopped production for nearly six weeks, and the Cyber Monitoring Centre estimated the cost to the UK economy at about £1.9 billion across more than 5,000 organisations.
Regulators are paying attention. Since 13 July, the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority have overseen AWS, Google Cloud, Microsoft and Oracle as the UK's first critical third parties. Regulated firms still own their own outsourcing due diligence and contingency planning.
What mapping the chain does for maturity and compliance
Mapping the chain lifts several capabilities at once. On the cloud capability map I use, it moves:
- Service Catalogue and Service Level Management: you know what you deliver and how it should perform.
- Vendor and Contract Management: you know who you depend on and what was agreed.
- Disaster Recovery, IT Continuity Plan and Technology Risk Management: you know how you will recover and what it would cost.
- Business Architecture: the layer that ties business processes to the technology carrying them.
The same evidence answers to the frameworks you may already face:
- NIS2: Article 21 lists business continuity, including backup management, disaster recovery and crisis management, and supply chain security among its required measures. It speaks of direct suppliers, so a fourth party view goes beyond the text and is good practice. Article 20 puts approval and oversight with the management body.
- NIST CSF 2.0: the Govern function includes a supply chain risk management category and the recover function covers the plans you will lean on.
- DORA: for EU financial entities, applying since 17 January 2025, with a register of ICT third-party arrangements and tested exit strategies.
- NCSC Cyber Assessment Framework: principle A4 covers supply chain, and Objective D covers minimising the impact of incidents.
- UK Cyber Security and Resilience Bill: introduced in November 2025, it would bring data centres and managed service providers into scope and let regulators designate critical suppliers.
Standards such as ISO 27001 and ISO 22301 give you an audit route for the same material. One map, one body of evidence, several frameworks.
Three questions to ask first
- Which services would hurt most if they stopped, and for how long could you tolerate it?
- Which suppliers does each one depend on, and which suppliers do they depend on in turn?
- When did you last rehearse losing one, and what evidence did it leave?
If a structured start would help, Epitechnic offers two bounded engagements: a Critical Supplier Cyber Risk Review and a Cyber Resilience Executive Exercise.
What is the furthest link down your own chain that you can name today?