What happened when Google Cloud deleted UniSuper's private cloud?

What happened in the UniSuper Google Cloud incident?

Google Cloud accidentally deleted the private cloud subscription that ran UniSuper's core systems. It wasn't a cyberattack. It was a provider-side configuration error, and it removed the whole environment at once.

UniSuper is one of Australia's largest pension funds. According to the joint statement from UniSuper and Google Cloud of 8 May 2024, the fund invests "over $135 billion on behalf of more than 647,000 members". The statement, issued with Google Cloud CEO Thomas Kurian, said "an inadvertent misconfiguration during provisioning of UniSuper's Private Cloud services ultimately resulted in the deletion of UniSuper's Private Cloud subscription". The statement calls it an isolated, "one-of-a-kind occurrence" that had never happened to any other Google Cloud client.

The incident matters well beyond Australia. It's the clearest public example of why we treat cloud workloads as part of a backup as a service strategy, rather than assuming the provider's resilience covers your data. If you run on any hyperscaler, the same failure mode exists, however rare.

Why did Google Cloud delete UniSuper's private cloud?

Because one input field in an internal Google tool was left blank. The system then applied a default fixed term to the subscription and deleted it when that term ended.

In its post-incident explanation, Details of Google Cloud GCVE incident, Google wrote that "one input parameter was left blank when using an internal tool to provision the customer's Private Cloud". The blank parameter caused the system to assign "a then unknown default fixed 1 year term". When the year ended, the private cloud was deleted. No customer notification was sent, because the deletion was triggered by Google operators using the tool, not by a customer request.

Google says it has since deprecated the internal tool, reviewed every GCVE private cloud for the same risk, and corrected the deletion behaviour. That's a sound response. It also confirms the risk was invisible to the customer until the day it happened.

Why didn't geographic redundancy protect UniSuper?

Because redundancy copies a single environment to more places. When the environment itself is deleted at the subscription level, every replica goes with it.

The joint statement is explicit: UniSuper "had duplication in two geographies as a protection against outages and loss", but the deletion of the subscription "caused deletion across both of these geographies". Google's later post describes the impact as "one customer in one cloud region". The two accounts frame the scope differently, but agree on the key point: the replicated environment was gone.

That's the core difference between redundancy and backup. Redundancy protects against hardware or site failure. It doesn't protect against a deleted subscription, a compromised admin account or a wrong command, because the replica obeys the same control plane. Google's own shared responsibility guidance puts data and access policies on the customer side for exactly this reason. We explore the same trap in why multicloud is not a backup strategy.

What role did third-party backups play in UniSuper's recovery?

A decisive one. Both UniSuper and Google credit backups that the deletion didn't touch, including copies outside Google's environment, with making the restoration possible.

The joint statement says: "UniSuper had backups in place with an additional service provider. These backups have minimised data loss, and significantly improved the ability of UniSuper and Google Cloud to complete the restoration." Google's post adds that backups in Google Cloud Storage in the same region weren't affected by the deletion and, "along with third party backup software, were instrumental in aiding the rapid restoration".

Even so, recovery was not quick. InformationWeek's analysis of the outage dates the start to 2 May 2024, with members regaining access around 9 May. DatacenterDynamics reported that by 13 May members could log in and view balances again. Teams worked around the clock to rebuild networking, security configuration, hundreds of virtual machines and databases. Having the data was necessary; rebuilding the environment around it took the time.

What are the lessons for European organisations?

Keep a copy your provider can't delete, and make sure you can turn it back into a working environment quickly. Five lessons stand out.

1. Provider error is a real risk, even if rare. Shared responsibility doesn't mean the provider never makes mistakes; it means your recovery can't depend on it not making them.
2. The subscription is a single failure domain. Regions, zones and replicas inside one account or contract can all disappear together.
3. Backups outside the failure domain decide the outcome. Ideally with a different operator, different credentials and immutable storage.
4. Data isn't the same as service. Restoring a full environment takes days unless standby infrastructure and runbooks are ready. See our recovery timeline guide for what drives the duration.
5. You won't always get a warning. UniSuper received no notification before the deletion. Monitor your own estate and backups.

For organisations in scope of NIS2, these lessons map directly onto Article 21(2)(c) of Directive (EU) 2022/2555, "business continuity, such as backup management and disaster recovery", and Article 21(2)(d), supply chain security. Our article on NIS2 supply chain security covers how to assess cloud providers as suppliers.

How do you apply the UniSuper lessons to your own cloud?

Treat your cloud subscription as something that can disappear, and plan backwards from that. Five steps turn the lesson into practice.

1. Map your provider dependencies. List which systems would stop if one cloud account or subscription disappeared.
2. Add an external, immutable copy. Follow the 3-2-1-1-0 rule, with at least one copy outside your primary provider.
3. Cover SaaS too. Microsoft 365 and Google Workspace have the same dependency; see what happens when a SaaS provider goes down.
4. Plan where you'll restore to. If the primary environment is gone, you need somewhere else to run.
5. Test a full-loss scenario. Not one file, but a whole application stack, at least once a year.

Our Google Cloud backup keeps that external copy in our own Tier III data centres in the Netherlands and Germany, independent of US hyperscalers, immutable with Object Lock plus an air-gapped copy. With disaster recovery added, you get standby infrastructure, instant VM boot in an isolated recovery environment on a separate, clean network, and critical workloads restored on a 4-hour SLA. A certified engineer validates the first test failover, typically within 10 days, and automated DR tests run every quarter with evidence for auditors.

What to do next

UniSuper did many things right: it had redundancy and, crucially, backups outside the environment that was deleted. That's why it recovered. The incident shows that your provider's resilience protects its platform, not your account, and that only an independent copy plus a rehearsed recovery covers the rare day when the provider is the cause.

Ask one question this week: if your main cloud subscription vanished tonight, where would you restore from, and to where? If the answer is unclear, start with your backup as a service foundations and our guide to Google Cloud shared responsibility.

Book a free 15-minute demo to see an isolated recovery from an off-platform copy.

This article is information, not legal advice.