Walk into any Australian procurement conversation about cloud and you'll hear "data sovereignty" and "data residency" used as if they were synonyms. They aren't. The difference doesn't matter on a good day. On a bad day — when a foreign court order, a parent-company subpoena, or a vendor outage shows up — it's the entire conversation.

This piece is the version we wished existed when we started building tasmanian.cloud: a plain-English explainer of what each term means under Australian law, where the gap between them comes from, and how to evaluate a vendor claim of "sovereign" without taking their word for it.

The two-line definition

Data residency answers the question where do the bytes physically live? If your object storage bucket is in ap-southeast-2, that's an Australian residency claim about a single region.

Data sovereignty answers a different question: whose laws can reach those bytes, and whose courts can compel disclosure? A dataset can sit physically in Sydney and still be subject to a US legal order if the operator is a US-incorporated entity.

The short version: residency is a geographic property of the data; sovereignty is a legal property of the operator and the supply chain. Residency is necessary for sovereignty. It is not sufficient.

Why the gap exists: the CLOUD Act and parent-company reach

The single largest reason these terms diverged is the United States Clarifying Lawful Overseas Use of Data Act (CLOUD Act), passed in 2018. Its core effect is that a US-based service provider can be compelled by US authorities to produce data in its "possession, custody, or control" — regardless of where the data is physically stored.

That "regardless of where" clause is the whole problem. A hyperscaler region in Sydney is operated by a subsidiary of a US-headquartered company. Local incorporation of an Australian arm (e.g., an "AWS Australia" or "Microsoft Australia" entity) generally does not break the chain of custody for CLOUD Act purposes, because the parent retains operational control of the underlying systems.

The same shape of problem exists in the other direction with other jurisdictions. China's 2017 National Intelligence Law obliges Chinese organisations to assist state intelligence work. The UK's Investigatory Powers Act has its own extraterritorial provisions. The point isn't to single out one jurisdiction; it's that the legal nationality of the operator matters as much as the postcode of the disk.

What Australian law actually says

The Privacy Act 1988 and the APPs

The headline Australian regime is the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs) it carries. APP 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access. APP 8 governs cross-border disclosure: before disclosing personal information to an overseas recipient, the entity must take reasonable steps to ensure the recipient does not breach the APPs.

Two things are worth pulling out of APP 8. First, the obligation attaches to disclosure, which the OAIC has interpreted broadly enough to cover routing personal information through infrastructure operated by an overseas provider in many circumstances. Second, the entity remains accountable for what the recipient does with the data — you don't outsource the compliance, only the processing.

Sectoral overlays that add real teeth

On top of the Privacy Act, several sectoral regimes treat sovereignty as a hard requirement rather than a procurement preference:

  • Hosting Certification Framework (HCF) — administered by the Department of Home Affairs, the HCF certifies cloud and data centre providers used by Commonwealth agencies. The "Certified Strategic" tier requires Australian sovereignty over ownership and control, not just data location.
  • IRAP and the ISM — the Information Security Manual and the IRAP assessment process determine whether a system is suitable for protected-classification workloads. Sovereignty considerations sit on top of technical controls.
  • APRA CPS 230 and CPS 234 — for regulated financial entities, operational risk and information security standards require explicit attention to where critical operations and material service providers sit, including cross-border arrangements.
  • My Health Records Act 2012 — section 77 prohibits holding or processing My Health Record data outside Australia, with limited exceptions.
  • State health and government records legislation — states like Victoria, NSW, and Queensland have their own restrictions on transferring health and identifiable government records offshore.

None of these regimes use the words "data sovereignty" uniformly, but together they describe the operating constraint: Australian organisations dealing with regulated data classes are accountable for both where the data lives and who can compel its disclosure.

Three claims you'll see, and what they actually mean

Vendor claimWhat it really guaranteesWhat it doesn't
"Hosted in Australia"The primary storage region is in an Australian state.Says nothing about backups, support access, parent-company control, or whether a foreign court order can compel disclosure.
"Australian data residency"Customer data, at rest, lives in Australian-located facilities.Doesn't cover metadata, telemetry, or support/admin pathways. Doesn't address the operator's legal nationality.
"Sovereign Australian cloud"Should imply Australian-owned, Australian-operated, Australian-jurisdiction-only — but the term is unregulated.Without a specific framework attached (HCF Certified Strategic, a contractual sovereignty schedule), this is marketing language. Ask for the chain of ownership and the support model.

The questions to ask a vendor

The cheapest way to test a sovereignty claim is to ask questions that force the vendor to be specific. We recommend the following list, adapted from how we evaluate our own supply chain:

  1. Who owns and controls the operating entity? Walk the share register up to ultimate beneficial ownership. A locally incorporated subsidiary of an offshore parent is a different risk profile from an Australian-owned company.
  2. Where, exactly, does the data live — including backups? A primary region in Sydney with replicated backups to Singapore is not Australian-resident data.
  3. Where do support and operations staff sit? If tier-3 support runs out of a US or India operations centre, those staff have access pathways into your data, and they sit under different laws.
  4. What happens to telemetry, logs, and metadata? These often flow to centralised observability stacks in the parent company's home region. Object names, IP addresses, and access patterns are themselves sensitive.
  5. What is the warrant-handling policy? A sovereign provider should be able to tell you, in writing, which jurisdictions it accepts compulsory legal process from and how it notifies customers when it can.
  6. Is there a customer-controlled key? Customer-managed keys (with the key material held outside the provider's control plane) materially change the conversation, because a court order to the provider doesn't produce plaintext.

When residency is enough — and when it isn't

For a great many workloads, Australian residency is the right level of control. Marketing analytics, public-facing content, internal tooling that handles no regulated personal information — for these, the cost and friction of a fully sovereign stack isn't justified by the risk.

The picture inverts when any of the following are true:

  • The dataset includes health records, government records, or sensitive personal information of Australians.
  • The workload sits within an APRA-regulated financial entity's critical operations.
  • The customer base or regulator has an explicit contractual sovereignty requirement.
  • The threat model includes a foreign government or foreign-headquartered competitor.
  • The data has long-term confidentiality requirements (e.g., intellectual property or research data) where future legal regimes in 10–20 years are part of the risk picture.

In those cases, "our region is in Sydney" isn't the answer. The right answer is a stack where every operating entity in the supply chain is Australian, every jurisdictional pathway is documented, and you can name the human in Australia who would receive a foreign legal request and refuse it.

How tasmanian.cloud answers these questions

We built tasmanian.cloud as a deliberately small, deliberately local alternative for organisations that need real sovereignty rather than residency. The shape of the answer is:

  • Operator: TWN Group Pty Ltd, an Australian-owned company headquartered in Launceston, Tasmania.
  • Infrastructure: Compute and storage entirely within Tasmania (TAS-1 in Launceston, with TAS-2 in Hobart on the roadmap), on Australian-owned hardware.
  • Data path: Customer data, backups, telemetry, and support all stay within Australian jurisdiction.
  • Storage: S3-compatible object storage on RustFS, with post-quantum cryptography and zero AU egress fees.
  • Legal posture: We accept compulsory process only from Australian courts. There is no parent company in another jurisdiction to compel disclosure through.

That doesn't make us right for every workload — it explicitly isn't. We don't compete on hyperscale economics, we don't offer GPUs, and we don't pretend to. What we do offer is an answer to the sovereignty question that holds up when someone actually reads the supply chain.

Further reading