Data sovereignty for Australian businesses

Data sovereignty used to be a policy conversation. It's now an operational one. Regulators are tightening the rules, clients are asking sharper questions about where their data ends up, and the cost of getting it wrong has stopped being theoretical.

This post walks through what sovereignty means in practice, which industries feel it most, and what compliant infrastructure looks like without being over-engineered.

What data sovereignty actually means#

Sovereignty means your data is subject to the laws of wherever it lives, and of whoever holds it. If the provider storing your data is a US company, US law can reach it. That includes the CLOUD Act, which lets US law enforcement compel US-based providers, by warrant or subpoena, to hand over data on any server they own and operate. The server being in Texas or Tasmania makes no difference.

For plenty of workloads, none of this matters. For healthcare, finance, legal, and government, it can matter a great deal.

Residency is the narrower question: where is the data physically stored? Australian residency means the bytes don't cross the border. You can have residency without sovereignty. Data sitting in a Sydney data centre that gets processed through systems subject to foreign law fails the sovereignty test even if it passes the residency one.

The regulatory context#

A handful of frameworks drive Australian sovereignty requirements.

The Privacy Act and the Australian Privacy Principles govern how you handle personal information. APP 8 is the cross-border one. Its rule is tighter than "check the recipient has good privacy protections." Before you send personal information overseas, you must take reasonable steps to ensure the overseas recipient won't breach the APPs, and if they do, your organisation is generally held accountable for that breach. A developer who pipes personal data into an offshore AI API without thinking about this has just landed that accountability on their employer.

The My Health Records Act goes further. Section 77 prohibits holding, taking, or processing My Health Record data outside Australia, with civil penalties of up to 1,500 penalty units for breaches. That covers originals, copies, backups, and access.

IRAP (the Infosec Registered Assessors Program, run by the Australian Signals Directorate) applies if you're building for federal or state government. Data residency is almost always a hard requirement once IRAP enters the picture.

APRA-regulated entities like banks, insurers, and super funds operate under prudential standards that cover data management, outsourcing, and offshore processing. ASIC-regulated entities have their own obligations. Outside explicit regulation, most serious clients will now ask where their data lives before they'll sign anything.

Where this becomes a practical problem#

For most teams, the real problem sits with data in motion, not data at rest.

A modern application leaks data to twenty or thirty third parties without anyone properly clocking it: analytics, CRMs, support tools, AI APIs, error trackers. Each of those is a potential residency violation if nobody has checked what it sends and where it sends it.

AI sharpens the edge. The use cases that justify investing in AI, like reading patient notes, reviewing contracts, or summarising customer support tickets, are the ones regulators care about most. An engineer who sticks api.openai.com in front of patient data has quietly created an APP 8 problem. In our experience, engineers aren't usually thinking about this while they're shipping features.

Building compliant infrastructure#

The infrastructure side has three layers.

Data at rest. Use AWS's Australian regions: ap-southeast-2 in Sydney and ap-southeast-4 in Melbourne. Lock down S3, RDS, and DynamoDB so nothing replicates outside Australia. Encrypt at rest with KMS, and use customer-managed keys where the sensitivity warrants it.

Data in transit. TLS on everything. Use PrivateLink or VPC endpoints for AWS services so traffic doesn't traverse the public internet. Service-mesh mTLS for inter-service traffic if the data classification calls for it.

Data in processing. This is the awkward one. Any compute that touches sensitive data has to run in-region. For AI, that means Australian-hosted models, not calls to an offshore API. For analytics, the warehouse and pipeline stay here too.

# Verify your S3 bucket is in the correct region
aws s3api get-bucket-location \
  --bucket patient-records-au

# Verify an RDS instance is in ap-southeast-2
aws rds describe-db-instances \
  --db-instance-identifier production-primary \
  --query 'DBInstances[0].AvailabilityZone' \
  --region ap-southeast-2

What to document#

Compliance isn't only about being right. It's about being able to show your work. If you're in a regulated industry, keep this set of documents current:

• A data flow diagram covering every system that receives personal or sensitive information
• A list of third-party services that receive data, with their data processing agreements attached
• Evidence of encryption config for storage and transit
• Access logs for sensitive systems (who, when, what)
• A breach response plan with notification timelines

That's the file you pull out for auditors, hand to procurement, or reach for at 2am when something has gone sideways.

AI services and data sovereignty#

AI creates a specific risk surface. Teams ship AI features fast, and the sensitivity conversation often happens after the fact.

Our approach with clients is to set the policy before the architecture. Which data classifications can go offshore? Which cannot? Put technical controls in place to enforce those lines, not just a wiki page that people skim once.

For workloads that can't leave Australia, we deploy private LLM infrastructure on Australian compute. For workloads that can go offshore, we make sure the third-party agreements are in place and that data minimisation is enforced: don't send more than the task actually requires.

Running private AI infrastructure has got noticeably cheaper and simpler over the last 18 months. It's no longer an option only large enterprises can pull off.

Getting started#

If you haven't done a data flow audit recently, start there. Map where sensitive data actually goes, not where you think it goes. The gaps are almost always in integrations that got added quickly and never got a second look.

After that, it's prioritisation. Which flows carry the most risk, and what's the right control for each.

Our AI Services engagement covers the AI-specific side, including private LLM deployment for use cases that can't touch offshore services. Platform Engineering addresses the broader infrastructure and access-control work.