Google Cloud’s June outage moved bank cloud diligence from uptime to change safety

The week

On June 12, 2025, Google Cloud suffered a multi-hour outage that disrupted many of its services and a wide range of customer applications. Google’s incident report traced it to Service Control, the component that checks API requests against policies and quotas. Code for a new quota policy check had been rolled out in late May, but the path that would run it had never been exercised. On June 12, a policy change containing blank fields was replicated globally within seconds. The new code hit a null pointer error and crashed in every region. Google said the feature had not been protected by a feature flag. Cloudflare, some of whose services depended on Google Cloud, also suffered failures, spreading the effect to many more sites and applications.

Cloud outages are usually discussed as a concentration problem: too many institutions depending on too few providers. That framing is accurate and well covered. The June 2025 Google Cloud outage supports a narrower and more practical argument for banks, credit unions and broker-dealers. The incident began with no hardware fault, attack or disaster. It began with a routine change. Most third-party risk programs ask providers for uptime figures and audit reports, and very few ask how changes are released. We break that question into four parts: how new code is activated, how configuration reaches production, how far a failure can travel, and what evidence the bank gets afterward.

How new code is activated

Large providers release code continuously. The usual safeguard is staged rollout, region by region, with new features held behind flags until they are deliberately switched on. In Google’s account, the new code had already been deployed everywhere. Its path simply had not run, because the policy that would trigger it did not yet exist. Staged deployment therefore offered no protection. The risk moved to the moment of activation, which happened globally and at once.

A bank cannot inspect a hyperscaler’s pipeline, but it can ask specific questions in its due diligence questionnaire and annual review. Are new features in critical control-plane services protected by flags? Is activation staged as carefully as deployment? Are dormant code paths tested with realistic inputs, including malformed ones? Providers may answer at a general level. The value lies partly in the answers and partly in the record. If a later incident contradicts a written answer, the bank has a documented basis for escalation, and its board has evidence that management asked.

How configuration reaches production

The trigger on June 12 was a policy record. Configuration and policy data often move faster, and through fewer gates, than software, because teams treat them as data. Yet a malformed entry can do as much damage as a bad build. Here it replicated worldwide within seconds.

Banks know this pattern from their own estates. Many internal outages start with a firewall rule, an expired certificate or a routing change. Their change advisory boards often govern application releases more tightly than these updates. The same scrutiny belongs in provider oversight. Third-party risk teams can ask whether configuration and policy changes are validated against a schema before release, staged across regions, and reversible within minutes. They can ask whether global replication can be paused, and who holds that authority. A provider with a crisp answer is telling the bank something about its engineering culture. So is a provider without one.

How far a failure can travel

The failure spread across regions because Service Control is a global component. Recovery in one large region was then slowed as tasks restarted together and overloaded a shared database. The knock-on effect at Cloudflare showed a further layer: a provider’s outage becomes the outage of every provider built on it.

Banks cannot redesign a provider’s architecture, but they can design their own with it in mind. The first step is a dependency map that separates regional services, such as compute and storage, from global control-plane services, such as identity, API management and policy enforcement. A bank running in two regions of one cloud may still share a single global dependency, so its multi-region design protects against less than its architecture diagram suggests. The second step is a fourth-party view. If a bank’s payment processor, fraud scoring vendor and contact center platform all run on the same provider, it holds a concentration that sits in no single contract. Recording those links lets the business continuity team plan for a scenario in which several vendors fail together.

There is a cost trade-off. True independence from a provider’s global control plane usually means a second provider for the most critical services, with duplicated skills and tooling. Few banks will do that broadly. Many can justify it for a short list of services where a few hours of downtime would breach a regulatory or customer commitment.

What evidence the bank gets afterward

Google published a detailed incident report within days, naming the component, the missing flag and the remediation. That transparency is valuable, and banks should not leave it to goodwill. Contracts for critical services can require a written root cause analysis within a set period, notice of remediation commitments, and a later confirmation that those commitments were met.

Supervisors support this line of inquiry. The 2023 U.S. interagency guidance on third-party risk management expects banks to understand how critical providers manage operational risk. In the European Union, the Digital Operational Resilience Act has applied since January 2025. It requires financial entities to manage ICT third-party risk and sets up direct oversight of critical ICT providers. Post-incident reports then become diligence evidence in their own right. A risk team that reads them, records the provider’s commitments and checks delivery at the next review is assessing change safety on evidence.

With hindsight

Google’s remediation commitments included modularizing Service Control, requiring feature flags for critical changes and changing how global policy data is replicated. Later incidents followed the same pattern. In October 2025, a long AWS outage in its US-EAST-1 region began with a fault in automated DNS management. Later that month, Microsoft attributed an Azure Front Door outage to a configuration change that its safeguards failed to block. In November 2025, a malformed Bot Management feature file pushed across Cloudflare’s network caused a global disruption. Each started with a change or configuration path.

In November 2025, the European Supervisory Authorities designated their first list of critical ICT third-party providers under DORA, including Google Cloud, AWS and Microsoft. By this point in 2026, asking how a provider stages code activation and configuration has a firm footing in both incident history and supervisory practice.