The Google Cloud outage in London on 20 October 2026 began with an isolated power supply incident. Whether it would affect your organisation had been decided much earlier.
At 06:08 UTC on Tuesday 20 October 2026, a power supply incident in a Google Cloud availability zone in London triggered a chain reaction. Within hours, Google had recorded 38 affected products in the europe-west2 region.
According to reports, banking apps stopped responding, while parcel delivery, retail and public-facing services were also affected. Technology providers that rely on Google Cloud passed the impact on to their own customers. Problems were even reported with tools Google itself provides to help security teams operate in the region.
The cause was seemingly ordinary. The consequences were not. Some may dismiss it as simply a “provider failure” and move on. But that would be wrong, and increasingly costly.
A recurring pattern
The London outage was not an isolated or unusual incident. It added to a series of failures that have shaken organisations which believed they were well protected. In July 2024, a faulty CrowdStrike update disabled about 8.5 million Windows devices. Delta Air Lines alone cancelled about 7,000 flights and put its losses at more than $500 million.
In October 2025, a DNS failure in the AWS region in Northern Virginia and two Azure Front Door outages disrupted services around the world.
Although the causes differ, these incidents reveal the same weakness: when shared infrastructure goes down, organisations that appear to be independent are affected at the same time.
Provider reliability and resilience
Cloud providers offer exceptionally high levels of reliability. Yet a provider can meet all its technical targets while your organisation is unable to process scheduled payments, breaches a regulatory deadline or leaves customers unable to access their accounts. The service level it provides is not the same as your own resilience.
No organisation can prevent a cloud provider from failing. But it can control the extent to which a failure affects its operations, its customers and its ability to meet its obligations.
During Tuesday’s outage, Google advised customers to move their workloads to another zone or region “if possible”. That option was available only to those who had already planned the move, allocated the necessary resources and tested the process. For everyone else, it was too late.
This explains why the same incident can have such different consequences. For a prepared organisation, the loss of a zone remains a manageable operational incident. For an unprepared one, it can escalate into a crisis affecting business operations, regulatory compliance and reputation.
Management remains accountable
Regulators have made their position clear. Under the European Union’s DORA regulation, the management body of a financial entity bears ultimate responsibility for information and communication technology (ICT) risk.
NIS2 requires management bodies to approve cybersecurity measures and oversee their implementation, while their members can be held liable for breaches.
Non-compliance can result in significant penalties, with fines for essential entities reaching €10 million or 2% of total worldwide annual turnover.
After this week’s events, no board can credibly argue that the loss of a cloud zone was unforeseeable. When a risk has materialised repeatedly in incidents that have become public, leaving it unaddressed is a decision by management.
Limiting exposure to risk
Resilient organisations know what their operations depend on, including the suppliers of their suppliers. They invest in recovery capabilities that remain available even if identity management services, management consoles or network connections stop working.
Their preparations include practical tests of how to handle failures, not just tabletop exercises. This gives their boards evidence that critical services will continue to operate within the approved limits.
Others rely on their provider and on luck. Neither is a strategy that management can defend to regulators, shareholders or customers.
Five questions for the board
1. If the main cloud zone we use lost power tomorrow at 7am, which of our services would stop working?
2. Who decides when to fail over to backup infrastructure, and how long would recovery actually take?
3. What shared dependencies could bring down both our primary and backup infrastructure?
4. When did we last test recovery in practice, and what did not work?
5. Is acceptance of the residual risk, together with the rationale for it, recorded in the minutes?
The answers to these questions show how ready an organisation is to continue operating when its provider encounters a problem.
Management cannot guarantee that the cloud will always be available. But it is its responsibility to know what an outage would mean for the organisation and to have made timely provision to deal with it.
* Eleftherios Antoniadis is Founder & CTO of Odyssey Cybersecurity