"Our data is in Australia" is one of the most confidently wrong statements in Australian tech procurement. It's usually true and almost always beside the point, because it answers a question about geography when the real question is about jurisdiction. This guide untangles the two, explains how the US CLOUD Act reaches data physically sitting in Sydney, walks through the 2024 Privacy Act reforms, and gives you a checklist for a stack that is sovereign in fact, not just in marketing.

The core distinction

  • Residency = where the data physically sits (a Sydney data centre).
  • Sovereignty = whose government can compel access (set by who owns the provider).
  • You can have Australian residency without Australian sovereignty.
  • A US-owned provider in Sydney = residency yes, sovereignty no.
  • Sovereignty is verified by corporate ownership, not by a region dropdown.

Residency vs sovereignty, precisely

Data residency is a statement of physical fact: the bytes are stored on servers located in Australia. It's real and it matters for latency and for some localisation laws — but on its own it tells you nothing about who can legally reach the data.

Data sovereignty is a statement about legal reach: which nation's laws and courts can compel the data to be produced. That is determined by the corporate ownership and jurisdiction of the provider, not by where a hard drive spins. A company incorporated in the United States is subject to US law everywhere it operates — including its Australian region.

Choosing an Australian region changes where your data rests. It does not change which government can reach it. Only the provider's ownership does that.

How the US CLOUD Act reaches Sydney

The Clarifying Lawful Overseas Use of Data (CLOUD) Act, passed in the US in 2018, is explicit: it lets US authorities compel US-based technology companies to produce data in their "possession, custody, or control" — regardless of where in the world that data is stored. It was written precisely to reach data held offshore.

The practical consequence for Australian teams: if your provider is a US company, selecting its Sydney region does not put your data beyond US legal reach. A US court order can compel production without an Australian court ever being involved, and often without you being notified. The only structural way to be outside the CLOUD Act's scope is to use a provider with no US corporate presence anywhere in the chain — Australian-owned, Australian-operated, and Australian-hosted.

The Privacy Act 2024: the stakes went up

The Privacy and Other Legislation Amendment Act 2024 delivered the first tranche of the most significant reform to the Privacy Act 1988 in a generation. The direction of travel is unambiguous — tougher enforcement, real financial consequences, and new rights for individuals.

Combine that with the existing Notifiable Data Breaches scheme — which obliges you to assess and report eligible breaches — and the cost of a poorly-governed data stack is no longer theoretical.

APP 8 and cross-border disclosure

Australian Privacy Principle 8 is the one most SaaS teams trip over. It does not ban sending personal information overseas — but it makes you accountable for what the overseas recipient does with it. If your US-owned cloud mishandles data you disclosed to it, the obligation and the reputational damage land on you. Keeping personal information onshore with a sovereign provider removes that cross-border exposure at the root, rather than papering over it with contractual clauses.

Where sovereignty is effectively mandatory

Beyond general good practice, several sectors face rules that make Australian sovereignty a practical requirement rather than a nice-to-have:

We break the specific rules down by sector in Industries.

The sovereign-stack checklist

Use this to test any provider — including us. Sovereignty is a property you can verify, not a badge you take on trust.

  1. Corporate ownership. Is the provider an Australian entity with no foreign parent? Check the ABN and the ownership structure, not the marketing page.
  2. No foreign entity in the chain. Is there any US (or other foreign) company — parent, processor, sub-processor — that could be compelled? One is enough to break sovereignty.
  3. Data location. Are primary storage and backups in Australian data centres? Ask specifically about backups and disaster recovery.
  4. Support & administration. Are the people with production access Australian citizens working onshore, under Australian law?
  5. Written commitments. Will they state their ownership and data-handling in a contract or DPA, not just a webpage?
Sovereignty isn't a region dropdown. It's a chain-of-custody question: name every company that could be compelled to hand over the data, and confirm none of them answer to a foreign court.

How WattleDB is built for this

WattleDB is designed to pass that checklist by construction. It's a 100% Australian-owned Backend-as-a-Service, built by RR Sols Pty Ltd — an Australian company with no foreign parent — running entirely on Australian-owned infrastructure in Sydney and Melbourne, with backups kept cross-state within Australia. There is no US entity anywhere in the chain to compel, so there is no CLOUD Act exposure to disclose. The platform is architected for IRAP assessment at the PROTECTED level, giving regulated buyers a clear alignment story. For most teams it's the difference between explaining a foreign-jurisdiction risk in every procurement round and simply not having one.