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 one thing that never stopped mattering, though, is ownership. As soon as a regulator, an enterprise customer or your own board asks "whose laws govern this data, and who owns the company that holds it?", 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 ownership matters more than the region dropdown, and how to run in the cloud on infrastructure you know is locally owned.
The core idea
- The cloud abstracts away location; sovereignty is a question about ownership and jurisdiction.
- Residency (where data sits) and sovereignty (whose law governs 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 decides whose laws apply.
- A locally owned 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 governed by the laws of the jurisdiction that controls it, and, as a goal, the practice of keeping your data under a jurisdiction you choose. 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 separated three things that used to travel together, where the data physically sits, who operates the infrastructure, and which country's law governs the operator. Ownership is what pulls them back into line.
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 govern it, and who owns it? | Provider ownership & jurisdiction |
You can satisfy residency and even localisation, the bytes are in-country, and still have sovereignty sit elsewhere, because the company holding the data is based overseas. Residency is a checkbox; sovereignty is an ownership question.
Picking a local region changes where your data rests. It does not change who owns and governs it. Only the provider's ownership does that.
Why provider ownership matters more than the region
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 keeps its home jurisdiction wherever it goes. As a point of background, the US CLOUD Act (2018) illustrates the principle: a company's home-country law can apply to the data it holds, regardless of where in the world that data is stored. It isn't unique to the US, either, which is exactly why the EU developed concepts such as "sovereign cloud" and worked through cross-border transfer rules after decisions like Schrems II.
The takeaway is simple and positive: a local region gives you residency, and local ownership gives you sovereignty. When the company that owns, operates, supports and profits from the stack is in the same country as the data, the ownership question has one clean answer. That is the difference between a Sydney region and an Australian company.
The "sovereign cloud" and what actually makes it local
"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 ultimate owner is still overseas. Genuine sovereignty is stricter and simpler to state: the whole chain is locally owned. Every company in the stack, parent, operator, processor and sub-processor, answers to the same local law. When ownership runs all the way down, you have one clear jurisdiction and one clear supplier to point to.
How to achieve an Australian-owned 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.
- Local ownership all the way down. Is every company in the chain, including the underlying infrastructure provider, domestically owned? Trace every layer.
- Domestic data, including backups. Are primary storage and backups all held in-country? Backups are where sovereignty quietly slips.
- 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 locally owned 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 keep ownership local.
An Australian-owned cloud, in practice
For Australian organisations this abstract question has a concrete answer. A genuinely local cloud means an Australian-owned provider running on Australian-owned infrastructure, so the whole chain, ownership, operation and support, is Australian, and Australian law is the law that governs the data. That's the bar WattleDB is built to clear: a wholly 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 one outside WattleDB and our Australian hosting and data-centre providers has access to your database or its backups. You get the cloud experience, a managed database, an API, backups, point-in-time recovery, with one Australian company behind it and a team you can actually reach. For the Australia-specific legal detail, see Data sovereignty in Australia.