Data residency vs data sovereignty in Australia: what's the difference?

What is data residency?

Data residency is the physical location where your data is stored and processed. In Australia that usually means choosing an Australian cloud region for every service that holds or handles the data. If your database runs in the AWS Asia Pacific (Sydney) region, your data resides in Australia. Residency is a technical and contractual fact you can verify: you choose the region, and the provider commits to keeping the data there unless you move it.

The three hyperscale clouds all run Australian regions:

Provider	Australian regions
Amazon Web Services	Asia Pacific (Sydney) ap-southeast-2, Asia Pacific (Melbourne) ap-southeast-4
Microsoft Azure	Australia East (New South Wales), Australia Southeast (Victoria), Australia Central 1 and 2 (Canberra)
Google Cloud	australia-southeast1 (Sydney), australia-southeast2 (Melbourne)

Residency also covers processing, not just storage. A database in Sydney that sends every record to an analytics service in the United States doesn’t have Australian residency for that processing step.

What is data sovereignty?

Data sovereignty is the principle that data is subject to the laws of the country with jurisdiction over it. In simple terms, the question is: which governments and courts can compel someone to hand your data over? In cloud computing, that means looking past the region to the company that runs it.

That depends on two things. The first is where the data sits, which is residency. The second is who controls it. A US-headquartered provider can be compelled under US law, most notably the Clarifying Lawful Overseas Use of Data Act (CLOUD Act) of 2018, to produce data it controls even when that data is stored outside the US. So data can be resident in Sydney and still be reachable by a foreign legal process.

Australia and the United States have a bilateral agreement under the CLOUD Act framework, the AUS-US Data Access Agreement, signed on 15 December 2021 and in force since 30 January 2024. It governs how each country’s agencies can obtain orders for data held by communications providers in the other for serious crime and national security purposes, with safeguards: US authorities can’t intentionally target Australian citizens, permanent residents or people in Australia under it. It narrows the practical risk for many workloads but doesn’t make a US provider a purely Australian one.

What’s the difference between data residency and data sovereignty?

Residency answers “where is the data?” and sovereignty answers “whose laws can reach it?” A third term, data localisation, describes a rule that data must stay in a country, which forces residency but doesn’t settle sovereignty.

	Data residency	Data sovereignty
The question it answers	Where is the data?	Whose laws can reach it?
Determined by	Region and data centre location	Location plus the provider’s nationality and control
How you achieve it	Pick an Australian region, block replication elsewhere	Residency plus provider choice, key control, access control and contracts
Can you verify it yourself?	Yes, through configuration and audit logs	Partly: it also depends on law and the provider’s obligations

What are the data residency requirements in Australia?

Australian law generally doesn’t require data to stay in Australia, but some data and some contracts do. There is no single data sovereignty law in Australia; the requirements come from privacy law, sector rules and contracts. The Privacy Act 1988 doesn’t ban sending personal information overseas. Under APP 8, before disclosing personal information to an overseas recipient you must take reasonable steps to make sure it’s handled consistently with the APPs, and you’re usually accountable for the recipient’s mistakes.

Specific regimes are stricter. My Health Record data can’t be held or processed outside Australia under the My Health Records Act 2012. Australian Government agencies hosting sensitive government data, whole-of-government systems or systems classified at PROTECTED use providers certified under the Hosting Certification Framework, now administered by the Department of Home Affairs (at the time of writing the framework is under reform, and new certification registrations have been paused since 3 November 2025). Many state government, health and financial services contracts write onshore storage into their terms, and APRA-regulated entities must manage the risks of offshore arrangements under their prudential standards.

Is Indigenous data sovereignty the same thing?

No. Indigenous data sovereignty is a separate and broader idea: the right of Indigenous peoples to govern data about them, their communities and their lands. Many searches for “data sovereignty Australia” are about this meaning rather than cloud hosting.

In Australia, the Maiam nayri Wingara Indigenous Data Sovereignty Collective published the principles agreed at the 2018 Indigenous Data Sovereignty Summit. They assert that Aboriginal and Torres Strait Islander peoples have the right to exercise control of the data ecosystem, including creation, stewardship, analysis, dissemination and infrastructure, and to data structures that are accountable to Indigenous peoples and First Nations.

For a software or AI project, the practical point is that cloud residency doesn’t address these rights. If a system collects or analyses data about Aboriginal and Torres Strait Islander people or communities, governance, consent and who controls the data need to be designed with those communities, not settled by picking a Sydney region.

Why this matters more for AI projects

For AI, data sovereignty depends on where the model runs, not only where the database lives. AI systems move data in ways traditional apps don’t. When a chatbot or RAG system answers a question, the user’s prompt, the retrieved documents and the model’s response all travel to wherever the model runs. A system with a Sydney database but a model endpoint in the US has Australian residency for storage and US processing for every question asked.

Check these points before choosing a model provider:

1. Inference location. Is the specific model you want available in an Australian region? Availability differs by model and changes frequently.
2. Logging and retention. Does the provider store prompts and outputs, where, and for how long? Is it used for training?
3. Abuse monitoring. Some services keep flagged prompts and outputs for human review, and the reviewers may sit outside Australia, unless you’re approved for an exemption.
4. Embeddings and vector stores. Embeddings are derived from your documents. Treat them with the same residency rules as the source data.
5. Sub-processors. Which third parties touch the data, and where are they?

Which models can actually run onshore, on AWS Bedrock, Azure OpenAI, Google Cloud and the direct APIs, is covered in our guide to AI data sovereignty in Australia. For the region-by-region view of the three clouds, see Bedrock vs Azure OpenAI vs Vertex AI in Australia.

How we handle it at All Webbed Labs

We default to Australian regions for databases, storage, vector indexes and, where the model you need is available onshore, inference. Where a requirement can only be met offshore, we document exactly what leaves Australia and why, so it can go into your privacy impact assessment and APP 8 analysis. We also design for key control: encryption with keys held in your own cloud account, so access requires your permission as well as the provider’s.

If your project has strict sovereignty requirements, that decision is made during discovery, before architecture, because it shapes the choice of cloud, model and vendors. See our cloud infrastructure and LLM integration services, or read how we approach trust and security.