Google Cloud Was Designated In July. The Liability Stayed With You.

At 06:08 UTC on Tuesday 20 October 2026 Google Cloud's London region began returning errors across a long list of services. Google later attributed the cause to a power event in a single availability zone, europe-west2-b, one of three in the region, and recovery ran through the early afternoon. Revolut confirmed its own disruption. Down Detector reports ran through Lloyds, HSBC, Royal Mail, Rightmove, DPD, BT and Screwfix. Nothing published points to an attack. The detail that should hold a board's attention is a date: on 13 July 2026, Google Cloud EMEA Limited became one of the first four companies HM Treasury designated as a Critical Third Party to the UK financial system. Its interim self-assessment to the regulators was due within three months of that. Roughly a week after that window closed, a power fault in one zone took region-level services down for most of a working morning. The regime is not what failed here. What the regime never did was move the liability.

Outage coverage follows a predictable arc. It leads on the household names, settles into a status-page timeline, and concludes with a sentence about the risks of putting all your eggs in one basket. That arc has been run often enough that it has stopped carrying information. What was genuinely new on 20 October is the regulatory position underneath it, because, so far as we can establish, this was the first material disruption to UK financial services at a designated Critical Third Party since designation took effect. For three months the question of what designation is worth to a regulated firm had been theoretical. That morning it stopped being theoretical, and the answer is less comfortable than most briefing notes have assumed.

What happened

Google's own Service Health record is the primary source for the mechanics, and the one to prefer wherever accounts differ. Incident Xs2XTHzAVC9YnafnPyzj records multiple services experiencing issues in europe-west2, Google's London region, beginning at 06:08 UTC on Tuesday 20 October 2026. Google's prose gives the same instant as 23:08 PDT on Monday 19 October, which is worth noting because the two renderings have already produced conflicting start times in secondary coverage.

The symptom description is brief and has not changed: "Multiple Google Cloud services are experiencing elevated errors and intermittent network failures in europe-west2 region." No cause has been offered. The first published workaround was "None for now". It was later revised to the suggestion that "the impacted customer may try to migrate their workload impacted to another available location (zone or region)". For most of the morning the record carried no end timestamp, no estimated time of recovery, and a severity rating of medium. Google's status page later reported that full recovery was tentatively completed by 13:00 UTC, and at 14:03 UTC that the issue was mostly mitigated and normal service had resumed for most customers. Google said it would publish an analysis once its internal investigation was complete.

The breadth is the part that secondary coverage has understated. The Register, reporting mid-morning, listed seven affected services. Google's own feed lists 38, and the roster is not peripheral: Compute Engine, Kubernetes Engine, Cloud SQL, Cloud Spanner, AlloyDB, Cloud Storage, Persistent Disk, Cloud Load Balancing, Cloud NAT, Virtual Private Cloud, Private Service Connect, Apigee, VMware Engine, BigQuery, Dataflow, Pub/Sub, Firestore, Bigtable, Memorystore and Cloud Run among them. That is not a feature degradation. It is compute, storage, database, networking and the API gateway in the same region at the same time.

• 1 January 2025The FCA's Critical Third Parties sourcebook and the PRA's Critical Third Parties rules take effect, published the previous November as FCA PS24/16 and PRA PS16/24. They bind a provider on designation, not before.
• 31 March 2025The FCA's deadline for firms to have completed mapping and testing and made the investments needed to remain within their impact tolerances for each important business service.
• 8 July 2026The Critical Third Parties (Designation) Regulations 2026, SI 2026/777, are made under section 312L of the Financial Services and Markets Act 2000.
• 13 July 2026Designation takes effect for Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited. Joint oversight by the Bank of England, PRA and FCA begins.
• By around 13 October 2026The window for the interim self-assessment to the regulators, due within three months of designation under CTPS 6.1.1R.
• 06:08 UTC, 20 October 2026The europe-west2 incident begins.
• 08:35 and 09:24 UTCGoogle's two status updates. The second withdraws "None for now" in favour of migrating workloads elsewhere.
• 10:49 UTCThe incident is open, uncaused and unresolved, and the first version of this briefing was written at this point.
• 13:00 UTCGoogle's status page reports that full recovery is tentatively completed.
• 14:03 UTCGoogle reports the issue mostly mitigated and normal service resumed for most customers, and attributes the cause to a power event in the europe-west2-b zone.

On who was affected, precision matters more than the list does. Only Revolut has confirmed its own disruption, saying it was "experiencing a service disruption affecting multiple services" and that customer money and data are safe. Every other name in circulation, Lloyds, HSBC, Royal Mail, Rightmove, DPD, BT and Screwfix among them, comes from Down Detector reports relayed through news coverage rather than from the companies themselves. Those reports are evidence that users could not reach a service. They are not confirmation of the cause, and no UK bank has published an attribution.

Neither obligation here is new. The firm-side deadline passed on 31 March 2025, and the rules binding the provider have been in force since 1 January 2025, biting on designation in July. What is new is that the two have now met in a live incident.

Why this one is different

Three things separate this incident from the ordinary cloud outage, and none of them is the fault itself.

The first is that no attacker has been identified and nothing published points to one, which means there is no security control to buy. An organisation with excellent detection, a tested incident response plan, segmented networks and a full set of certifications had much the same exposure that morning as one with none of it, because none of those controls addresses the availability of the underlying region. Boards that have spent a decade being asked to fund protection against attackers have rarely been asked the adjacent question, which is what happens when nobody attacks anybody and the service is still gone.

The second is that the provider's own remedy was to move. Google's revised advice was that affected customers might migrate their workloads to another zone or region. That is the right advice, and for many organisations it is also an invitation to discover something about themselves. Multi-region failover is routinely attested to in questionnaires and assumed in continuity plans, and the engineering cost is a standing reason it goes untested. An instruction to fail over is a test of whether failover exists.

The third is the one that makes this a governance story rather than an engineering one. Since 13 July, Google Cloud EMEA Limited has not been an ordinary supplier to UK financial services. It is a designated Critical Third Party, overseen jointly by the Bank of England, the PRA and the FCA, subject to six Fundamental Rules and, for the services that qualify as systemic, eight operational risk and resilience requirements covering governance, supply chain, technology and cyber resilience, change management, mapping, incident management and termination. The hyperscalers are inside the regulatory perimeter. A good deal of commentary over the summer read that as a transfer of risk. It was not one.

The central finding. Bringing a provider inside the regulatory perimeter changed who supervises it. It did not change who answers for the service the customer could not reach.

What designation does, and what it does not

The clearest statement of the limit comes from the FCA itself, in the announcement of the designations on 10 July 2026. Two lines from it do most of the work. The first: "Designation under this regime is not the same as authorisation by the regulators." The second, and the one worth reading to a board verbatim, is that the regime complements but does not replace existing outsourcing and operational resilience rules, and that regulated firms remain responsible for managing their own third-party arrangements including due diligence, risk management and contingency planning.

Read plainly, that is a statement that the regulatory perimeter moved and the accountability did not. HM Treasury designates, under section 312L of FSMA 2000 as inserted by the Financial Services and Markets Act 2023, after consulting the three regulators. The regulators then supervise the resilience of the systemic services the provider supplies to the sector. None of that discharges a firm whose important business service was unavailable that morning. The question a supervisor can ask next is not whether Google was designated. It is whether the firm stayed within the impact tolerance it set for the service, and whether it had done the mapping and testing it was required to complete by 31 March 2025.

There is, however, one thing designation produced that most firms have not collected, and the detail of it repays care. Under CTPS 7.1.1R, a designated provider owes a duty of information to "a firm to which it provides any systemic third party services". Note the qualifier: the entitlement runs to firms receiving systemic third party services, not to every customer of a designated provider. CTPS 7.1.2R sets out what that information includes: the results of testing and exercising carried out under CTPS 5, together with any action taken in light of them; the annual self-assessment prepared under CTPS 6.1.1R(2), redacted as appropriate; and "the appropriate maximum tolerable level of disruption set by the critical third party" for each systemic third party service provided to the firm.

Two points of precision matter here, because getting either wrong would send a board asking for the wrong document. The self-assessment within the information duty is the annual one. The submission due around 13 October was the interim self-assessment required within three months of designation under CTPS 6.1.1R, and that goes to the regulators rather than to firms. And the maximum tolerable level of disruption is not a forecast. It is a tolerance the provider itself sets, the same species of thing as a firm's own impact tolerance, which is precisely what makes it useful: it is the number against which a firm's impact tolerance should be reconciled.

The commercial exposure for UK organisations

Regulatory. No new obligation arrived on 20 October, and anybody saying otherwise is selling something. The obligations that bite are the ones already in place. UK firms in scope of the FCA's operational resilience rules had to identify their important business services, set impact tolerances for the maximum tolerable disruption to each, and, by no later than 31 March 2025, complete the mapping and testing and make the investments needed to operate consistently within those tolerances. An unexplained multi-hour failure of a single cloud region is the textbook scenario those rules were written for. Whether any individual firm exceeded a tolerance on the day is a question only that firm can answer, and none has said. For groups with EU regulated entities, DORA runs in parallel with its own register of information and its own incident reporting, and an EU entity's position is not covered by the UK analysis.

Financial. The direct cost of the outage is largely not recoverable and largely not the point. Service credits are calculated against a provider's availability commitment and are routinely a small fraction of the commercial loss, and they do not touch the cost of the remediation this prompts. The expensive item is the one that has been deferred: genuine multi-region or multi-provider capability for the services that cannot be down. That spend was always a judgement about a low-probability event, which is exactly the kind of judgement that gets revisited the week after the event occurs, and usually at a worse price under time pressure.

Contractual. Designation did not of itself change any contract. A regulated firm's commitments to its own customers do not lapse because its provider failed, and the asymmetry is uncomfortable when examined: the obligations a firm owes downstream are typically firmer than the ones it holds upstream. Two specific items are worth checking now. Whether the firm has actually exercised its sourcebook entitlement, where it has one, to the provider's testing results, redacted annual self-assessment and maximum tolerable level of disruption. And whether its own customer-facing and counterparty commitments contain a supplier-failure or force majeure provision that a several-hour regional cloud failure would engage, because most do not.

Governance. The decision that mattered on the day was made years ago by somebody comparing the cost of one region against two, and it was made as an engineering and budget decision. It became a board-level resilience position without anybody recording that it had become one. That is the pattern this kind of incident exposes, and it is an organisational design problem rather than a technical one: the architecture choice sits with engineering, the impact tolerance with risk, the regulatory relationship with compliance, and the consequence arrives for all three at once. Concentration risk is now a published, designated, named fact about four companies. After 20 October, treating it as unforeseeable is a considerably harder position to hold.

What leaders should do now

1. Establish which important business services depend on a single region, and whether that was a decision. Not which cloud provider, which region. Many organisations can name their provider without being able to say immediately which of their critical services would survive the loss of one of its regions. Where the answer is single-region, find out whether that was a documented risk acceptance or a default that nobody revisited. The two are treated very differently in a supervisory conversation.

2. If you receive systemic third party services from a designated provider, ask for what the sourcebook already requires it to give you. The testing and exercising results under CTPS 5, the annual self-assessment in redacted form, and the appropriate maximum tolerable level of disruption the provider has set for each service it supplies you. The qualifier matters: this entitlement runs to firms receiving systemic third party services, not to every customer. Where it applies it is an existing requirement rather than a negotiation, and it produces the number you need for action three.

3. Decide whether your impact tolerance held on 20 October, and write the answer down before anybody asks. If an important business service was unavailable that morning, the firm will eventually be asked whether it stayed inside the tolerance it set. The answer is far better arrived at now, with the logs still to hand, than reconstructed in six months under questioning. If the answer is no, the follow-up question is what changes, and having that drafted is the difference between a well-run firm and a surprised one.

4. Price the failover you have already attested to. Go through the continuity plans, the customer questionnaires and the regulatory submissions and find every place the organisation has claimed it can move a workload. Then establish, for each, whether it has ever been done. Google's advice on the day was to migrate. An organisation that cannot is finding that out the hard way.

5. Separate provider resilience from your resilience in board reporting. If the board papers describe third-party risk by listing the provider's certifications, designation status and uptime commitments, they are describing somebody else's control environment. Report the two separately: what the provider is accountable for, and what the firm would do when the provider is unavailable. Only the second is a control the firm owns.

Five decisions, not five tasks. The second is an existing entitlement for the firms that have it. The fourth is the one that tends to reveal whether failover exists or was only ever written down.

Three questions for the board

1. Which of our important business services would survive the loss of one cloud region, and when did we last prove it? The first half is an architecture question and most organisations can eventually answer it. The second half is the one that separates a tested capability from a documented intention.

2. Where we are entitled to it, have we asked our designated providers for the maximum tolerable level of disruption they have set, and does our impact tolerance reconcile with it? If the firm's tolerance for a service is two hours and the provider's own tolerance is longer, the firm's figure is an aspiration rather than a plan, and that gap is visible to a supervisor the moment either number is produced.

3. When the provider is in the regulatory perimeter and we are still accountable, what have we actually gained? There is a real answer, and it is the information entitlement rather than a transfer of risk. A board that believes designation reduced its exposure has mispriced its position.

Strategic takeaway

The durable lesson is about where accountability sits when a dependency becomes regulated, and it generalises well past cloud computing. Bringing a supplier inside a regulatory perimeter changes who supervises that supplier. It does not change who answers for the service the customer could not reach. The FCA said as much in plain terms in July, and a good deal of the industry read it as reassurance rather than as a boundary. 20 October is the first occasion we can identify on which the distinction had consequences, and a firm that found that day uncomfortable is likely to be one that treated designation as somebody else's problem being solved rather than its own problem being documented.

The second lesson is about the character of the risk itself. For most of the past decade the resilience conversation in UK financial services has been conducted in the language of attack: threat actors, intrusion, ransomware, recovery from compromise. That language has shaped budgets, reporting lines and board agendas. It does not describe what happened on 20 October. A power fault in one availability zone took region-level services down, and services that millions of people use were unreachable for hours. Detection would not have caught it, training would not have prevented it, and certification does not cover it. Availability has been the quiet third of the triad for years, and it is the one that reached the front pages that day.

Neither point needs a new budget line to begin. Both need somebody senior to decide that a dependency the organisation did not design, cannot operate and now shares with its competitors is a board-level position rather than an infrastructure detail.

Confidence note

Confirmed, from primary sources. Google Cloud incident Xs2XTHzAVC9YnafnPyzj, as published on Google's own Service Health feed: a start time of 06:08 UTC on 20 October 2026, rendered in Google's prose as 23:08 PDT on 19 October 2026; the affected location recorded as London (europe-west2) and no other; 38 affected products listed; a severity rating of medium; the symptom wording quoted above; the workaround moving from "None for now" to the suggestion to migrate workloads to another zone or region; a note that Looker Studio is not impacted; two status updates, at 08:35 and 09:24 UTC, with the record last modified at 10:01 UTC; and no end timestamp, no cause and no estimated time of recovery as at 10:49 UTC on 20 October 2026, the time of writing. On the regulatory position: that the Critical Third Parties (Designation) Regulations 2026, SI 2026/777, made 8 July 2026, designate Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited with effect from 13 July 2026; that the designation power is section 312L of FSMA 2000, inserted by the Financial Services and Markets Act 2023, exercised by HM Treasury after consulting the FCA, PRA and Bank of England; that the FCA and PRA rules took effect on 1 January 2025 and were published in November 2024 as PS24/16 and PS16/24; and that oversight is joint between the Bank of England, PRA and FCA. From the FCA Handbook directly: that CTPS 6.1.1R requires an interim self-assessment within three months of designation and an annual self-assessment thereafter; that the CTPS 7.1.1R information duty runs to "a firm to which it provides any systemic third party services"; and that CTPS 7.1.2R covers the CTPS 5 testing and exercising results including action taken in light of them, the annual self-assessment under CTPS 6.1.1R(2) redacted as appropriate, and "the appropriate maximum tolerable level of disruption set by the critical third party" for each systemic third party service provided to the firm. On firms' own obligations: that the FCA's operational resilience rules and guidance came into force on 31 March 2022, and that firms had to complete mapping and testing and make the investments needed to operate consistently within their impact tolerances by no later than 31 March 2025.

Quoted, and load-bearing. From the FCA's statement of 10 July 2026: "Designation under this regime is not the same as authorisation by the regulators." The same statement is the source for the position that the regime complements but does not replace existing outsourcing and operational resilience rules, and that regulated firms remain responsible for managing their own third-party arrangements including due diligence, risk management and contingency planning. From the FCA's operational resilience policy statement page: that firms must have completed mapping and testing and made the necessary investments "by no later than 31 March 2025". From CTPS 7.1.1R and 7.1.2R: the scope of the information duty and the phrase "the appropriate maximum tolerable level of disruption set by the critical third party". From Google's status record: the symptom and workaround wording. From Revolut: "experiencing a service disruption affecting multiple services".

Reported, and not read from a primary source. That Lloyds, HSBC, Royal Mail, Rightmove, DPD, BT and Screwfix were affected. These come from Down Detector reports relayed in news coverage, and none of those companies has published a statement attributing its disruption to this incident. A Cloudflare entry carried in our drafting notes was dropped because it could not be sourced to anything better than aggregated outage reports. Google's words on the cause, "A power event caused an outage within europe-west2-b zone", together with the status page timings of a tentative full recovery by 13:00 UTC and mostly mitigated with normal service resumed for most customers at 14:03 UTC, are quoted as reported by The Register on 20 October 2026 rather than read from Google's record directly. The seven-service figure in The Register's early coverage against the 38 on Google's feed, and the estimate of 38 services down attributed in the same piece to an academic, which we treat as independent corroboration of the order of magnitude rather than of the exact count. The count of six Fundamental Rules and eight operational risk and resilience requirements, and the twelve-month deadlines for initial mapping, scenario testing and an incident management playbook exercise, are taken from published legal analysis of the rules rather than from the sourcebook text itself.

Not established. Whether any attack or malicious act was involved: nothing published points to one, and Google's published cause is a power event rather than a security event. The underlying reason for the power event, which Google had not published as at 7 November 2026 and said it would address in an analysis after its internal investigation. The precise final duration, since the status page records a tentative full recovery and then a mostly mitigated state rather than a single clean end timestamp. Whether any individual UK firm exceeded an impact tolerance, since none has said so and the question is firm-specific. Whether any affected firm has notified the FCA, PRA or Bank of England, or will. Whether the Bank of England, PRA or FCA will say anything about this incident at all, and whether the Critical Third Parties regime will be engaged by it. Whether Google will publish the fuller incident analysis it said it would produce, and what it will attribute the power event to. How many firms have exercised the CTPS 7 information entitlement: we have found no published instance of a firm doing so, and absence of reporting is not evidence of absence. Whether the regulators can impose a financial penalty on a designated Critical Third Party: published legal analysis reads Chapter 3C of FSMA 2000 as providing censure under section 312Q and prohibition or limitation under section 312R but no fining power, while the Bank of England's own CTP page refers to enforcement action without resolving the point, and we have not reconciled the two. By contrast, DORA expressly provides, under Article 35, for a daily periodic penalty payment of up to 1% of a critical ICT third-party service provider's average daily worldwide turnover in the preceding business year, for up to six months, where the provider fails to comply with measures required by its Lead Overseer. That is a compliance lever against non-compliance with oversight measures, not a penalty for an outage, and we note it as a confirmed statutory contrast rather than as an inference about UK powers.

Assessed, and labelled as ours. The reading of this as a governance and accountability story rather than an outage story. The argument that designation moved supervision without moving liability, which is our characterisation of the FCA's published position and not a form of words the FCA has used. The judgement that the information entitlement is the most immediately usable new assurance artefact the regime produced for firms. The observation that an instruction to migrate workloads functions as a test of whether failover exists. The five actions, the three board questions and the framing of availability as the neglected third of the triad. The characterisation of this as the first material disruption to UK financial services at a designated Critical Third Party since designation took effect reflects searches conducted on 20 October 2026; absence of a reported earlier instance is not proof that none occurred. Nothing in this analysis is the stated position of the FCA, the PRA, the Bank of England, HM Treasury, Google or any affected firm, and it should not be read as such. The first version of this briefing was written while the incident was still open, with the facts as at 10:49 UTC on 20 October 2026. It was reviewed and updated for publication on 7 November 2026, by which point Google had attributed the cause to a power event in europe-west2-b and had reported recovery. The resolution and cause, and the correction of the zone question, are the only substantive changes; the regulatory analysis is unchanged.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and Americas.