In May 2024, Australian pension fund UniSuper — managing around $125 billion for over 600,000 members — went dark. Not from ransomware or a cyberattack: a misconfiguration during provisioning caused Google Cloud to delete UniSuper's entire private cloud subscription. The deletion propagated to both geographic regions where the fund had redundantly duplicated its data. The redundancy did exactly nothing, because both copies lived inside the account that ceased to exist.

Recovery took more than a week of round-the-clock work, rebuilding hundreds of virtual machines and databases. The decisive factor, acknowledged in UniSuper's own communications: backups held with a different provider, outside Google's ecosystem. Without that external copy, one of the world's larger pension funds might have permanently lost its members' data to an administrative error.

The misconception this incident buried: "our cloud provider's redundancy protects us." Redundancy protects against the provider's hardware failing. It does not protect against the provider's processes failing — and it never protects data that lives inside the account being deleted.

What Exactly Happened at UniSuper?

During provisioning of UniSuper's Google Cloud VMware Engine private cloud, a configuration error left a parameter that caused the subscription to be treated as temporary. When the term elapsed, Google's systems deleted the private cloud — automatically, without customer notification, and across both regions UniSuper used for redundancy. Google and UniSuper jointly described it as an unprecedented, isolated event, triggered by an internal tooling gap rather than any customer action.

The Timeline That Matters

The deletion took effect in early May 2024; member services went offline immediately. Restoration ran for more than a week, and succeeded because UniSuper could pull from backups stored with an additional, third-party provider. The provider-internal safeguards — geo-redundancy, account protections — were all downstream of the failing account and vanished with it.

Couldn't This Happen to Anyone's Cloud Environment?

Yes — that is the uncomfortable core of the lesson. Every hyperscaler runs automated lifecycle systems that can, under rare failure conditions, act destructively at account scope. And account-scope destruction has more common causes than provider error: compromised admin credentials (an attacker deleting your environment), malicious insiders, billing failures cascading into suspension and purge, or your own automation gone wrong.

The structural point is provider-agnostic. Anything inside the account — snapshots, native backups, replicas, versioning — shares the account's fate. The industry's answer is the 3-2-1 principle, and specifically its most neglected leg: one copy off-site, meaning outside the primary provider's control plane entirely. UniSuper is simply the largest public demonstration of why that leg exists.

The EU Reading: Sovereignty Raises the Stakes

For European organizations, the incident intersects with a second exposure. Data held by US-headquartered hyperscalers remains subject to US jurisdiction — the CLOUD Act reaches the provider regardless of datacenter location — which sits uneasily with GDPR expectations about control over personal data. An independent backup with an EU-owned provider addresses both problems in one architecture: the copy survives account-level failure, and it lives under EEA law.

The regulatory frameworks point the same direction. The NIS2 Directive requires in-scope entities to manage supply chain risk — and your cloud provider is your most concentrated supplier dependency — while ENISA's technical implementation guidance details backup and recovery expectations, including independence and testing. An auditor reading the UniSuper post-mortem will ask you one question: which of your recovery paths survives the deletion of your primary cloud account?

Applying the Lesson: A Five-Step Plan

Redundancy vs. Backup vs. Independence

The first column is what UniSuper had; the last column is what saved them. Most organizations' architectures stop at column two and call it a backup strategy — which is accurate right up until the failure occurs one level higher than the backup lives.

Conclusion

UniSuper did most things right — redundant regions, a major provider, professional operations — and still spent a week offline because every internal safeguard sat inside the account that was deleted. The single decision that turned catastrophe into recovery was made long before the incident: keeping one copy with someone else. That is the whole lesson, and it applies equally to IaaS workloads, Microsoft 365 tenants, and Google Workspace domains. If you'd like to know which parts of your environment would survive the loss of your primary cloud account — and which wouldn't — we're happy to map it with you.

Frequently Asked Questions