Data Sovereignty Isn't the Same as Data Residency

Data residency is not the same as data sovereignty. Following last week's prompt, a practical sovereignty assessment asks where data sits, who can reach it, and which jurisdictions apply across the whole lifecycle.

Is our data in Australia?

It's a reasonable question to ask about any AI service. Last week I traced one AI prompt from the question to the answer and back out through the logs. This week I want to stay with that same prompt and ask two narrower things: where did it sit along the way, and who could reach it?

Microsoft documents regional data residency commitments for eligible Microsoft 365 Copilot offerings, subject to the product terms and how the service is configured.

But data residency is not the same as data sovereignty.

Residency describes where data is stored, or processed, under a particular service commitment. Sovereignty is broader. It takes in legal jurisdiction, ownership and control, administrative access, support arrangements, subcontractors and whether another jurisdiction can compel access to the data.

The two terms often get used as if they mean the same thing. The Australian Government's Hosting Certification Framework treats them separately. It splits privacy, sovereignty and security into distinct considerations and addresses sovereignty directly as a procurement question.

That split matters in practice. An organisation can hold strong Australian data residency and still need to assess offshore support, global administration or third-party model processing.

Go back to last week's prompt, "Summarise the key risks across our major projects". For the AI service that answered it, I think a practical sovereignty assessment should answer at least six questions:

Where is our data stored at rest?

Where is it processed?

Which paths does it travel between those points?

Where can support staff and privileged administrators access it from?

Which subprocessors receive it?

Who owns and controls the service and the data, and which jurisdictions can apply?

And one that runs across all six: what changes when the provider introduces a new model or a new subprocessor?

To answer those properly, we should be asking for evidence rather than a region on a map: product-specific residency documentation instead of a general cloud-region statement, processing and support locations, subprocessor information, cross-border transfer mechanisms, contractual commitments, and any exceptions to regional processing.

Where personal information is involved, privacy obligations apply as well. For organisations covered by the Privacy Act, the Australian Privacy Principles guidelines from the Office of the Australian Information Commissioner (OAIC) are the reference point. For government workloads, align with the applicable hosting and security requirements, including cloud assessment and authorisation guidance from the Australian Signals Directorate (ASD). A commercial residency commitment on its own isn't sufficient evidence there.

None of this is a case against using AI. It changes the question. "Is our data in Australia?" becomes "Which parts of our data lifecycle are Australian, which are not, and what legal and contractual controls apply to each part?"

Two weeks ago the question was where our data goes. Last week it was what we can show. This week it's who else can reach it, and under which law.

The organisations that get this right can name every part of that lifecycle that sits offshore, and the control that covers it, before they sign the contract.

Sources / further reading:

• Microsoft Learn, Data Residency for Microsoft 365 Copilot: https://learn.microsoft.com/en-us/microsoft-365/enterprise/m365-dr-service-copilot-offerings

• Australian Government Architecture, Hosting Certification Framework: https://architecture.digital.gov.au/standard/hosting-certification-framework

• Australian Signals Directorate (ASD) / Cyber.gov.au, Cloud assessment and authorisation: https://www.cyber.gov.au/business-government/protecting-devices-systems/cloud-computing/cloud-assessment-and-authorisation

• Office of the Australian Information Commissioner (OAIC), Australian Privacy Principles guidelines: https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines