What Data Sovereignty Actually Means
Data sovereignty refers to the principle that data is subject to the laws and governance structures of the country where it is physically located. When Australian businesses store personal information about their customers in cloud systems, the question of where that data physically resides – and what legal regime governs it – has direct consequences for Privacy Act compliance.
This isn't a theoretical concern. There are real scenarios where data held offshore becomes inaccessible, subject to foreign government requests, or exposed to regulatory regimes that don't align with Australian law. The concern is proportionate to the sensitivity of the data and the nature of your business, but every Australian business handling personal information needs to understand the basics before they sign a cloud services agreement.
The good news is that data sovereignty compliance is achievable for most businesses. The major cloud providers have made significant investments in Australian infrastructure, and most compliance requirements can be met with the right configuration and contractual protections. The issue is that many businesses never check those settings or ask those questions.
The Legal Framework: What the Privacy Act Actually Requires
The Privacy Act 1988 (Cth) governs how Australian businesses handle personal information. The Australian Privacy Principles (APPs) set out the rules, and the one most directly relevant to data sovereignty is APP 8: cross-border disclosure of personal information.
APP 8 requires that before an Australian Privacy Act-covered entity discloses personal information to an overseas recipient, it must take reasonable steps to ensure the recipient will handle that information in accordance with the APPs. This obligation sits with the Australian business, not the overseas cloud provider. You can't discharge your responsibility simply by pointing to the cloud provider's privacy policy.
There are mechanisms to satisfy APP 8 without keeping all data in Australia. These include:
- Contractual protections – Binding contractual clauses requiring the overseas recipient to comply with the APPs. Most enterprise cloud providers offer Data Processing Agreements (DPAs) that include these commitments. The obligation is on you to have them in place and to review them.
- Adequacy assessment – You have a reasonable belief the overseas recipient's country has privacy laws substantially similar to the APPs. Note that the OAIC does not publish a formal adequacy list for Australia the way the EU does, so this relies on your own assessment.
- Consent – The individual has consented to the cross-border disclosure, having been informed about the risks. This is workable in some contexts but impractical as a blanket solution.
The Notifiable Data Breaches (NDB) scheme, which operates under Part IIIC of the Privacy Act, adds further obligation: if personal data held offshore is involved in a qualifying data breach, your notification obligations to the OAIC and affected individuals apply in the same way as they would for a domestic breach. You need to know that data exists, where it is, and have incident response processes that cover it.
Businesses with annual turnover above $3 million are covered by the Privacy Act, as are smaller businesses in certain sectors (health service providers, credit reporting, tax file number recipients, and others). The 2024 Privacy Act reform proposals, which are progressing through Parliament, will likely extend coverage to smaller businesses and increase penalties significantly. Now is the right time to get your house in order.
Where Your Data Actually Lives in Major Cloud Platforms
The default configuration of many cloud platforms does not guarantee Australian data residency, even when you choose an Australian region at sign-up. This catches businesses out regularly.
Microsoft 365 / Azure: Microsoft operates Azure Australia East (Sydney) and Australia Southeast (Melbourne). For Microsoft 365, core customer data – Exchange Online mailbox content, SharePoint and OneDrive files, Teams messages – is stored in the nominated region when you specify Australia. However, Azure Australia Southeast is the designated paired region for Australia East, meaning geo-redundant storage by default replicates data to Melbourne. That's still within Australia. The complication arises with certain Microsoft 365 features and services that route data through global infrastructure, and with newer AI features (Copilot, for instance) that may process data outside the region. Microsoft has published a Data Residency documentation set that covers exactly which services store data in which locations – it's worth working through for your specific subscription.
AWS: AWS has operated the Asia Pacific (Sydney) region since 2012. By default, data stored in S3, RDS, and other services in ap-southeast-2 stays in Sydney unless you explicitly configure cross-region replication. Most AWS services support region locking, but CloudFront (CDN), IAM (identity and access management), and certain global services operate outside any single region by design. AWS's documentation on region-specific service availability is detailed and accurate.
Google Workspace / Google Cloud: Google operates data centres in Sydney and Melbourne. Google Workspace offers a Data Regions feature that lets administrators pin covered data to a specific region or region group. This is not enabled by default – you have to configure it. Google Cloud Platform gives you explicit region selection for most services, but some global services (Cloud CDN, Cloud Armor, global load balancers) operate at the edge, not in a specific region.
Salesforce: Salesforce operates in Australia (instance cluster ANZ) with primary data stored in Sydney. Backup data and some metadata replicate. If you're on a Salesforce instance that isn't the ANZ cluster – which is possible if your organisation was onboarded before Australian data centres were established – your data may be stored in the US or EMEA. Check your instance URL and contact Salesforce if you're unsure.
SaaS applications generally: The majority of SaaS applications used by Australian businesses – project management tools, HR platforms, marketing tools, communication platforms – store data in the US by default. Many do not offer Australian or even APAC data residency options. For lower-sensitivity data, this is manageable with proper contractual protections. For data containing sensitive personal information under the Privacy Act (health information, financial information, identity documents), the risk profile is higher.
Practical Steps to Achieve and Maintain Compliance
Achieving data sovereignty compliance is a combination of configuration, contractual protections, and ongoing governance. These are the practical steps that cover most Australian businesses adequately:
- Complete a data inventory. You cannot manage data you don't know exists. Map what personal information your business holds, what systems it sits in, and where those systems are hosted. A spreadsheet is fine for a starting point. Many businesses are surprised by how many systems they're using once they do this exercise properly.
- Configure data residency settings in your major platforms. For Microsoft 365, review the Data Location settings in the Microsoft 365 admin centre. For Google Workspace, configure Data Regions. For AWS, confirm your default region and review any cross-region replication settings. For Salesforce, confirm your instance cluster with Salesforce support.
- Review and execute Data Processing Agreements. For every cloud provider handling personal information, ensure you have a current DPA in place that includes APP 8-compliant protections. Most major providers make these available through their online portals. Smaller SaaS providers may require a direct negotiation. If a vendor won't provide a DPA, that's a material risk to document and assess.
- Document your cross-border disclosure register. If you're disclosing personal information to overseas recipients – either cloud platforms or service providers – maintain a record of what data, to whom, under what protections. This is required to demonstrate compliance if the OAIC ever asks.
- Include data residency questions in your procurement process. Add a standard checklist item when evaluating any new cloud or SaaS platform: where is data stored, is Australian data residency available, what DPA is offered. Making this a routine step is far cheaper than retrospectively moving data or renegotiating contracts.
Sector-Specific Considerations
Some sectors face additional obligations on top of the Privacy Act that affect data sovereignty decisions.
Healthcare: The My Health Records Act 2012 and various state health records legislation impose stricter requirements on health information. The Australian Digital Health Agency's guidance on cloud storage of health data is specific and prescriptive. Healthcare providers should treat all patient data as requiring Australian data residency unless there is explicit regulatory clearance for specific offshore storage.
Financial services: APRA-regulated entities (banks, insurers, superannuation funds) are subject to CPS 234 (Information Security) and CPS 230 (Operational Risk Management), which include requirements about data management and third-party risk that effectively impose data residency and audit access requirements on cloud providers. APRA's expectations on cloud are documented in CPG 234.
Government and government contractors: The Australian Government's Protective Security Policy Framework (PSPF) and the Information Security Manual (ISM) impose strict requirements on where government data can be stored. If you're handling government data as a contractor, your cloud infrastructure choices need to align with these frameworks, and in many cases that means Australian-region cloud and ASD-certified cloud services (the IRAP assessment framework).
Legal and professional services: Legal professional privilege and confidentiality obligations interact with data residency when client data is stored in offshore cloud systems. Law societies in several states have issued guidance on cloud storage that practitioners should review.
Questions to Ask Your Cloud Provider
When evaluating a cloud provider or reviewing an existing relationship, these questions cut through the marketing and get to what you need to know:
- Where exactly is our data stored, at rest and in transit? Which specific regions or data centres?
- Is there any replication or backup to regions outside Australia? Can that be restricted?
- Do any of your sub-processors or feature providers store or process our data outside Australia?
- What Data Processing Agreement do you offer, and does it include APP 8 cross-border disclosure protections?
- If a foreign government issues a lawful request for our data, what is your process and do you notify us?
- Do you have independent certification (SOC 2 Type II, ISO 27001, IRAP) for the Australian region specifically?
- How would we extract our data if we ended the relationship? What format, what timeframe, and are there fees?
A reputable provider will answer these questions clearly and in writing. Evasive or marketing-heavy answers to specific technical and contractual questions are a warning sign that the provider hasn't thought carefully about these obligations.
CX Direct assists Australian businesses with cloud platform selection, data sovereignty assessments, and DPA review as part of our managed services and technology advisory work. If you're about to move to the cloud, or want to review your current position, get in touch.