The Google Cloud outage in London: why your vendors' resilience is now a regulatory matter

On 20 October 2026, a power failure in the europe-west2-b zone of Google Cloud in London took platforms including Revolut, Lloyds, and HSBC out of service for almost eight hours. The failure was in a single zone, not a whole region, and it still had broad impact. UK and EU regulators asked Google for information. The important part: what changed isn't an obligation for providers to guarantee redundancy — it's that critical providers are now under direct supervision. Responsibility for service continuity still sits with whoever offers it to the customer.

It's the kind of event we already know from the Azure outage story we covered before, but now it arrives with a difference: EU and UK regulators are starting to confront concentration risk in cloud providers head-on. This article connects the incident to what actually changes in regulation — and to what is genuinely in your hands: your redundancy plan.

What happened at Google Cloud on 20 October?

According to Google's official incident log, a power event interrupted services in the europe-west2-b zone in London and caused errors and intermittent network failures across parts of the region. The incident lasted seven hours and 52 minutes. Infrastructure products including Compute Engine, Kubernetes Engine, and Cloud Storage were affected. Revolut reported failures in logins, card payments, transfers, and withdrawals. Lloyds and HSBC also reported problems, and there was impact outside the financial sector.

Google has not yet published its root cause analysis. Until it does, the technical details should be treated as preliminary.

What the regulation says — and what it doesn't

The regulatory conversation is real, but it shouldn't be overstated. In the UK, on 10 July 2026, HM Treasury designated AWS, Google Cloud, Microsoft, and Oracle as critical third parties to the financial sector, effective 13 July. The Bank of England, the PRA, and the FCA can now set direct rules, require scenario testing, and mandate incident reporting. In the EU, in November 2025, authorities published under DORA the first list of 19 critical ICT providers, subject to direct supervision.

What it doesn't say: no rule obliges a cloud provider to guarantee redundancy. What exists is supervision, testing, and reporting. And financial institutions remain responsible for their services even when the failure originates with their provider.

The practical reading: your provider may be supervised, but it is not your continuity plan.

What should a redundancy plan look like?

If the regulator supervises the provider but responsibility to the customer is still yours, the redundancy plan is your half of the job. Six questions to review it:

1. Do you distinguish zone, region, and provider? A zone is not a region, and a region is not a plan. Your provider having several zones doesn't mean your architecture uses them well.

2. Have you mapped your dependencies? The broader failures usually come from dependencies nobody drew: a shared service, a database, an identity service.

3. Have you tested failover? A documented plan that has never been executed is a hypothesis. The test reveals how long recovery actually takes and what breaks along the way.

4. Have you defined recovery objectives? How long you can be down and how much data you can lose, per service — not a single number for the whole platform.

5. Do you have a communication plan? Who speaks to the customer, how often, and with what content — defined before the incident.

6. Does every outage end in a change? An honest RCA that ends in a new control, not just a document.

How does this connect to ISO 27001 and SOC 2?

No new rule requires it: the SOC 2 criteria are still the ones published in 2017 (with points of focus revised in 2022), and ISO 27001 has no revision underway. But the controls that already exist cover exactly this risk:

ISO 27001:2022, A.5.30 — ICT readiness for business continuity. ISO 27001:2022, A.8.14 — redundancy of information processing facilities. The supplier relationship controls in the same Annex A, which require managing third-party risk. And in SOC 2, the availability category: evidence that availability commitments are met and tested.

An auditor reviewing your system in 2027 will likely ask whether your failover tests and your communication plan for a provider outage have been tested, not just documented.

Frequently asked questions

Was the Google Cloud outage a whole region? No. According to Google's log, the event was in one zone (europe-west2-b) and caused errors across parts of the region.

Are cloud providers now required to have redundancy? No. What changed is direct supervision of critical providers in the UK and the EU.

Does this apply to companies in Mexico and LATAM? Equivalent regulation doesn't exist in Mexico or the rest of LATAM yet. Even so, your financial clients can require evidence of continuity by contract or by audit.

What should I review first? Who speaks to the customer during an outage, whether your failover tests have actually run, and whether your RCA would survive the reading of a demanding client.

The lesson I take away

Every time a cloud provider fails, the industry rediscovers that responsibility cannot be outsourced. Redundancy protects us from the next outage; timely communication and an honest RCA protect the relationship. And today, on top of that, EU and UK regulators are starting to look at the same problem.

Sources consulted

Google Cloud official incident log (20 October 2026). FinanceFeeds — Revolut's Google Cloud outage exposes shared risk across UK banks (21 Oct 2026). Mondaq — HM Treasury designates four critical third parties to the UK financial system. HSF Kramer — HM Treasury makes first designations under UK CTP regime. EIOPA — ESAs designate critical ICT third-party providers under DORA (18 Nov 2025). Morgan Lewis — DORA: EU regulators announce list of critical ICT third-party providers. Konfirmity — SOC 2: what changed in 2026.

This article is informative and does not constitute legal or regulatory advice. The incident details come from public reporting and may change once Google publishes its root cause analysis. Last updated: October 2026.