Data residency in Australia: 6 steps to get it right

TL;DR: Australia has no blanket law forcing all data onshore. Only some records, like those held for the My Health Record system, must stay here. For everything else, APP 8 makes you check any overseas recipient, and in most cases you wear their mistakes. Hosting in Sydney gives you residency, not sovereignty. So classify your data, audit where vendors keep it and who can reach it, then lock that into contracts and controls.

Australia has no law that says all data must stay onshore. A few types of data do. The rest runs on the Privacy Act, your sector's rules and your contracts.

So where do you start? Two things. Work out which of your data is sensitive or regulated. Then check where your vendors really keep it, and who can get to it.

Get that wrong and it's rarely a storage problem. It's a contract problem.

Residency, sovereignty and localisation: what's the difference?

Vendors use these three words like they mean the same thing. They don't. Mix them up and you sign a contract that promises less than you think.

• Data residency is where your data sits. A data centre in Sydney, say. It tells you where the bytes live. Nothing more.
• Data localisation is a legal rule that some data must stay in the country. It's not a choice. You can't opt out.
• Data sovereignty is the big one. Which country's laws apply, who owns the provider, and who can get into the systems.

This breakdown of data sovereignty in Australia splits it into three layers: jurisdiction, where data is stored and processed, and who has hands-on control. Residency only covers one of them.

Here's how that plays out:

• An online store keeps its order data in a Sydney cloud region. That's residency, full stop.
• Records held for the My Health Record system must stay in Australia by law. That's localisation. More on it below.
• A finance firm uses a Sydney data centre run by a US-owned provider. The data is here. But a US court can still order the provider to hand it over. That's a sovereignty gap.

Sort these out at the start of a build. It saves months of rework when a regulator or a big customer asks you to prove which one you deliver.

Which Australian laws apply

The Privacy Act 1988 is the base layer. Two of its principles do most of the work.

• APP 8 covers sending personal information overseas. Before you do, you must take reasonable steps to make sure the overseas recipient follows the Australian Privacy Principles. The OAIC's APP 8 guidelines set out the test. In most cases, if the overseas recipient gets it wrong, you're still on the hook.
• APP 11 covers security. You must take reasonable steps to protect personal information from misuse, loss and unauthorised access. The APP 11 guidelines apply wherever the data is stored.

The OAIC also runs the Notifiable Data Breaches scheme. If a breach is likely to cause serious harm, you must tell the people affected and the OAIC. That can still apply when the breach happens at an overseas vendor you sent the data to. Which is why APP 8 checks on offshore vendors matter so much.

Then the sector rules stack on top.

• My Health Records Act 2012. Section 77 of the My Health Records Act is one of the few true "must stay onshore" rules. The System Operator, registered repository and portal operators, and their contracted service providers can't hold or process My Health Record records outside Australia. If your software does that job, it applies to you.
• APRA CPS 230 and CPS 234. Banks, insurers and super funds must manage operational risk, including the risk from their service providers. CPS 234 sets the bar for information security, and that reaches the cloud and third-party services they use.
• Security of Critical Infrastructure Act 2018. The SOCI Act puts risk and reporting duties on critical infrastructure operators, in sectors like energy, water, communications and data storage.
• Hosting Certification Framework. Under the Hosting Certification Framework, sensitive government data, whole-of-government systems and PROTECTED systems must be hosted on certified services. Heads up: the framework is being reformed, and new certifications have been paused since 3 November 2025.

State governments run their own data and cloud policies too. Their tender contracts can ask for more than the law does: named data locations, no offshore admin access, limits on sub-processors.

One problem though. Plenty of mid-sized businesses sit under more than one of these. Say you run a health arm or hold a government contract. Your obligation is all of them added together, not just the loudest one.

Why hosting in Australia doesn't guarantee sovereignty

This is the gap that catches careful IT teams. Picking a Sydney region feels like ticking the sovereignty box. Often it isn't.

The clearest example is the US CLOUD Act. It lets US authorities compel US-based tech companies to hand over data they control, even when that data is stored outside the US. So if your "Australian region" is run by a US-owned provider, residency alone doesn't shield you.

The second risk is quieter. Your data might sit in Australia while the systems that manage it don't. Admin consoles, backups, monitoring and support desks often run from offshore teams.

Walk through these with your own vendors:

• A support engineer overseas can log in to your Sydney database to fix a fault. Your data never moves. But it can be viewed from outside Australia.
• Backups copy to an overseas region for disaster recovery. That quietly breaks an "Australia only" promise nobody checked at signing.
• Logs, metadata and telemetry flow to a global monitoring tool based offshore. They often get missed in data mapping.

Pro tip: ask every vendor one question in writing. "If a foreign government asked your parent company for our data, what happens next, and who signs off?" A vague answer tells you they haven't mapped it themselves.

None of this makes Australian hosting worthless. You need residency to get sovereignty. It just isn't enough on its own. If you're weighing up hosting options, our guide to cloud deployment models walks through the trade-offs.

Six steps to get data residency right

Here's a sequence a team can run. It works for an audit, a tender questionnaire, or just sleeping at night.

1. Classify your data. Split it into personal information, regulated data (health, finance), Indigenous data and commercial secrets. Do this before you touch a single contract. It decides everything after it. If you're starting from zero, this AI data governance plan is a good way in.
2. Audit every vendor and sub-processor. Ask for named data centre locations, not "APAC". A vendor who can't name where its sub-processors run hasn't done its homework. That's a red flag.
3. Lock it into the contract. Add clauses for named data locations, limits on offshore admin access, audit rights and notice of new sub-processors. Put them in every vendor contract, not just the obvious ones. This vendor security and procurement guide shows the kind of security terms worth writing into supplier agreements.
4. Add technical controls. Encrypt data in transit and at rest. Hold your own keys, ideally in an Australian hardware security module, so the provider can't read what it can't decrypt. Lock down who can see what with role-based access control.
5. Log everything and plan for incidents. When something goes wrong, you need proof ready for the OAIC: who accessed what, when, and under whose authority. Stripping personal data before it leaves your systems helps too. Our guide to PII redaction shows how.
6. Tier your data. Not every workload needs sovereign hosting. Keep sensitive and regulated data on certified Australian infrastructure. Let low-risk workloads run on cheaper global regions. Write the split down as policy, so it isn't left to whoever builds the next feature.

A build partner can turn this list into architecture. But every step needs a named owner inside your business. Not a vendor.

How to check a vendor for real sovereignty

Sales decks rarely offer up the details that matter. You have to ask, and know what a good answer looks like.

Start with ownership. Where is the vendor incorporated? Who owns the parent company? Has that changed lately? An acquisition can shift your exposure overnight.

Then ask about control. Where are the admin consoles hosted? Where are the support and engineering staff who can reach production?

Ask for these before you sign:

• data-flow diagrams that show every system your data touches, not just the main database
• SOC 2 or ISO 27001 reports for the environment your data will sit in, not a company-wide badge
• Hosting Certification Framework evidence, if they claim they can host government work
• a full sub-processor list, with a written promise to tell you about changes
• audit rights, so you can check their claims yourself

Pro tip: if a vendor can't send a data-flow diagram within a week, nobody there has mapped it. That's a bigger problem than any answer they could give.

Sometimes full sovereignty just isn't on offer, and for many global SaaS tools it isn't. You can still close part of the gap. Hold your own keys. Keep the most sensitive fields on your side with an on-premises connector. Or encrypt fields before they ever leave your systems. None of these is a perfect fix. They're a fair middle ground.

Plan for the day a vendor goes dark, too. Here's how to stop one AI vendor taking your product down. And if your data lives in rented tools, you may not own it the way you think.

Indigenous data sovereignty

This one deserves its own line, not a footnote. The Maiam nayri Wingara Indigenous Data Sovereignty Collective set out principles on how data about Aboriginal and Torres Strait Islander people is accessed and handled. The core idea: communities have a say over data about them.

The NIAA turned that into practical guidance for the Australian Public Service. Its Framework for Governance of Indigenous Data was published in May 2024 and co-designed with Aboriginal and Torres Strait Islander partners. It asks agencies to:

• know what Indigenous data they hold
• publish catalogues so communities can see what data exists
• work with Aboriginal and Torres Strait Islander people on data decisions
• use metadata labels so the data can be found and handled properly

It's written for government. But if you build platforms for health, education or community services, expect the same questions in a partnership review or tender.

Where Devwiz fits

Most sovereignty problems don't start with a bad vendor. They start with an early build decision, long before anyone asks a compliance question.

So we map where each type of data lives, and who can touch it, before the first sprint. Hosting region, key management and access rules go into the design. Data-flow diagrams and access logs are build deliverables, not paperwork bolted on before a review.

Who builds it matters too. Our take on onshore vs offshore for AI builds covers why. And if your platform uses AI, check where your prompts get processed. Our guide to AI regulation in Australia covers what APP 8 means for AI tools, and data governance for AI covers who owns the data.

Picking a Sydney region is the easy bit. The hard bit is knowing who can reach your data, from where, and under whose law. Answer that before you build and the audit is a formality. Answer it after and it's a rebuild.

*James*

Devwiz has shipped 200+ apps, including work for NSW Government (Justice and Corrective Services), Briometrix, Vivid and Huskee.

Planning a platform that has to pass APP 8 checks or a government tender? Start with AI app development or web app development. Worth a chat.

*This is general information, not legal advice. Talk to a qualified lawyer about your own situation.*

Frequently asked questions

What are the data residency requirements in Australia?

There's no blanket rule that all data must stay onshore. The Privacy Act's APP 8 says you must take reasonable steps before sending personal information overseas. A few laws go further, like the My Health Records Act, which keeps My Health Record system records in Australia.

Does Australia have a GDPR equivalent?

The closest is the Privacy Act 1988 and its Australian Privacy Principles, enforced by the OAIC. Its Notifiable Data Breaches scheme means you must tell affected people and the OAIC when a breach is likely to cause serious harm. It's built differently from GDPR, so don't assume a GDPR checklist covers you.

What does data residency mean?

Data residency is where your data is physically stored, like a data centre in Sydney. Data sovereignty is broader: which laws apply and who controls the systems. Data localisation is a legal rule that some data must stay onshore.

Does hosting data in an Australian cloud region guarantee compliance?

No. An Australian region gives you residency. Sovereignty depends on who owns the provider, where admin access and backups sit, and whether a foreign law like the US CLOUD Act can reach the provider. Customer-held keys and onshore admin access close much of that gap.