Google Cloud Outage: What It Means for Your Business Continuity Plan

On 20 October 2026, a fault in Google Cloud’s europe-west2 (London) region knocked out multiple services and disrupted operations at household names including Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Cloudflare, Screwfix and Revolut.

This is a developing story. We’ll update this post with further details as Google and affected organisations share more information.

What happened

Downtime began at 06:08 UTC in the europe-west2-b zone, one of three zones that make up Google’s London region. Google’s status page confirmed “elevated errors and intermittent network failures,” with impact spreading across BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, Google App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine and Managed Service for Apache Kafka.

Google’s engineering team began investigating that morning, with no recovery time estimated at the time of writing and no available workaround: “None for now.” Revolut confirmed it had been working on a fix “since it was identified this morning,” while reassuring customers that “all our customers’ money and data are safe.”

Downdetector logged disruption reports at Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Cloudflare, Screwfix and Revolut, with users online describing cascading failures through supply chains where services running in the affected zone had no high-availability configuration.

Why a single zone outage caused this much damage

Cloud zones exist specifically so that a hardware or regional failure in one doesn’t take down everything a business runs. In theory, a well-architected service spreads critical workloads across multiple zones or regions, so a problem in one zone doesn’t become a problem for the whole organisation.

In practice, this cloud outage is the latest reminder that theory and reality often diverge. It follows two other major disruptions in the space of a few weeks: a Microsoft Exchange Admin Center failure traced to a configuration change, and an Azure maintenance issue that disrupted hybrid cloud, VPN and VMware services. Three different providers, three different root causes, the same underlying risk to business continuity: concentration of critical services in infrastructure that isn’t fully under your own control.

What this cloud outage means for your business continuity plan

A cloud provider outage is, from a resilience standpoint, no different to a third-party supplier failure, a data centre fire, or a ransomware incident — it’s a scenario your business continuity and disaster recovery planning should already cover. A few questions worth asking this week:

Do we know which of our critical services run in a single zone or region, with no tested failover? A diagram showing “multi-zone” isn’t the same as a service that has actually failed over successfully in a drill.

Do we have a documented, tested incident response plan for a cloud outage specifically, not just for a breach? Many organisations test for cyber attacks but not for availability incidents caused by a supplier they don’t control.

Have we assessed this as a third-party/supply chain risk? If a core supplier’s outage can stop your business trading, that supplier belongs in your risk register and your due diligence process, reviewed with the same rigour as any other critical vendor.

Cyber Essentials and Cyber Essentials Plus don’t test cloud resilience directly, but the governance habits behind a strong business continuity plan asset awareness, access control, patching discipline, documented incident response are exactly what good certification processes push organisations to build. If this outage prompted a “could that happen to us?” conversation internally, that’s a useful trigger to review your continuity and third-party risk arrangements properly, rather than letting the feeling fade once the status page goes green again.