What is data sovereignty in cloud computing?

Data sovereignty in cloud computing is the principle that data is subject to the laws of the jurisdiction that controls it — and, by extension, the goal of keeping your data under the control of a chosen jurisdiction rather than a foreign one. In the cloud this is complicated because the physical location of a server and the legal nationality of the company operating it can differ. Sovereignty is determined by who can be legally compelled to access the data, which follows the provider's corporate ownership, not just where the data centre sits.

What is the difference between data residency, data localisation and data sovereignty?

Data residency is where data is physically stored. Data localisation is a legal requirement that certain data must be stored (and sometimes processed) within a specific country. Data sovereignty is about which nation's laws and courts can compel access to the data, which is set by the provider's jurisdiction and ownership. You can satisfy residency or localisation — storing data in-country — while still lacking sovereignty, if the provider is foreign-owned and can be compelled under foreign law.

Why does public cloud make data sovereignty harder?

Public cloud is dominated by a small number of large, mostly US-headquartered providers. Even when they operate local regions, the parent company remains subject to its home country's laws — including extraterritorial ones such as the US CLOUD Act, which can compel a US company to produce data regardless of where it is stored. So choosing an in-country region gives you residency but not sovereignty, because a foreign entity still sits in the chain of control.

How do you achieve a sovereign cloud?

You achieve a sovereign cloud by ensuring no foreign entity anywhere in the chain can be compelled to access your data: use a provider incorporated in your own country with no foreign parent, host primary data and backups domestically, keep administrative and support access onshore under local law, and verify these facts through corporate ownership and contracts rather than marketing. In Australia that means an Australian-owned provider running on Australian-owned infrastructure, so that only Australian law governs the data.

Data Sovereignty and the Cloud: What It Means & How to Achieve It

Cloud computing sold us a beautiful abstraction: stop thinking about where the servers are. For a decade that was the whole pitch — infrastructure as a borderless utility you rent by the minute. The problem is that data sovereignty is the one thing that never stopped being about borders. As soon as a regulator, an enterprise customer or your own board asks "whose laws can reach this data?", the abstraction leaks, and the answer depends on facts the cloud was designed to make you forget. This is a plain-English guide to data sovereignty and the cloud: what the term actually means, why the public cloud complicates it, and how to achieve a genuinely sovereign setup.

The core idea

The cloud abstracts away location; sovereignty is a question about location and jurisdiction.
Residency (where data sits) and sovereignty (whose law reaches it) are different things.
A local region from a foreign provider gives you the first, not the second.
Sovereignty follows the provider's ownership, because that's who can be compelled.
A sovereign cloud is achievable — it's an ownership and architecture choice, not a slogan.

What "data sovereignty" means in the cloud

Data sovereignty is the principle that data is subject to the laws of the jurisdiction that controls it — and, as a goal, the practice of keeping your data under a jurisdiction you choose rather than one imposed on you. In a single on-premises server room this was trivial: the data was in your building, in your country, under your country's law. The cloud broke that neat alignment by separating three things that used to travel together — where the data physically sits, who operates the infrastructure, and which nation's law governs the operator.

Three terms people use interchangeably (and shouldn't)

Half the confusion in sovereignty conversations comes from blurring three distinct concepts:

Term	The question it answers	Determined by
Data residency	Where is the data physically stored?	Your region choice
Data localisation	Must this data stay in-country by law?	Local regulation
Data sovereignty	Whose laws and courts can compel access?	Provider ownership & jurisdiction

You can satisfy residency and even localisation — the bytes are in-country — and still fail sovereignty, because the company holding them answers to a foreign government. Residency is a checkbox; sovereignty is a chain-of-custody question.

Picking a local region changes where your data rests. It does not change which government can reach it. Only the provider's ownership does that.

Why the public cloud makes sovereignty hard

The public cloud is concentrated in a handful of hyperscale providers, most headquartered in the United States. They operate excellent local regions all over the world — but the parent company remains a creature of its home jurisdiction. The clearest example is the US CLOUD Act (2018), which lets US authorities compel US-based technology companies to produce data in their "possession, custody, or control" regardless of where in the world it is stored. It was written specifically to reach data held offshore.

The consequence is counterintuitive but firm: a US provider's in-country region gives you residency, not sovereignty. The data is local; the jurisdiction is not. And this isn't unique to the US — extraterritorial data-access laws are a growing global pattern, which is exactly why regions like the EU developed concepts such as "sovereign cloud" and grappled with cross-border transfer rules in the wake of decisions like Schrems II. Wherever your provider's ultimate owner is incorporated, that country's reach travels with your data.

The "sovereign cloud" and what actually makes it sovereign

"Sovereign cloud" has become a popular label, and not all of it is equal. Some offerings are a foreign hyperscaler's service wrapped in local contracts and a local operating partner — better than nothing, but the foreign parent can often still be compelled. Genuine sovereignty is stricter and simpler to state: no foreign entity anywhere in the chain can be legally compelled to access your data. If even one company in the stack — parent, operator, processor or sub-processor — answers to a foreign court, sovereignty is broken. One is enough.

How to achieve a sovereign cloud

Sovereignty in the cloud is achievable; it's an ownership-and-architecture decision, and it's verifiable. Use this as a test for any "sovereign" offering:

Domestic ownership. Is the provider incorporated in your country with no foreign parent? Verify the corporate structure, not the marketing.
No foreign link in the chain. Is there any foreign company — including the underlying infrastructure provider — that could be compelled? Trace every layer.
Domestic data, including backups. Are primary storage and backups all held in-country? Backups are where sovereignty quietly leaks.
Onshore administration. Are the people with production access working locally, under local law?
Contractual commitments. Will the provider state ownership and data handling in a contract or DPA, not just on a webpage?

Pass all five and you have a cloud that's sovereign in fact, not just in name — with the elasticity and managed-service convenience that made the cloud worth adopting in the first place. You don't have to retreat to a server room to regain jurisdictional control.

Sovereignty in the cloud, the Australian case

For Australian organisations this abstract question has a concrete answer. A genuinely sovereign cloud means an Australian-owned provider running on Australian-owned infrastructure, so that only Australian law governs the data and there is no foreign entity to compel. That's the bar WattleDB is built to clear: an Australian-owned Backend-as-a-Service from RR Sols Pty Ltd — a company with no foreign parent — running managed PostgreSQL on Australian infrastructure in Sydney and Melbourne, with backups kept cross-state within Australia and no US entity anywhere in the chain. You get the cloud experience — a managed database, an API, backups, point-in-time recovery — without importing a foreign jurisdiction along with it. For the Australia-specific legal detail, see Data sovereignty in Australia.