Data sovereignty in Australia, explained

Data sovereignty gets used as a catch-all. A security questionnaire asks for it, a vendor says they have it, and nobody stops to say which of three different ideas they mean. The difference decides whether an answer satisfies a reviewer or just sounds reassuring.

Sovereignty, residency and localisation

• Data residency is where the data is stored and processed: a country, a region, a data centre.
• Data sovereignty is whose law governs the data and who can compel access to it. Data sitting in Sydney can still be reachable by a foreign legal order if the provider or its parent is subject to one.
• Data localisation is a legal requirement that certain data stay inside a country. It is a rule, not a product feature.

Residency is the part a vendor can configure and a buyer can check. Sovereignty depends on ownership, contracts and legal exposure, which is harder to verify from a pricing page. Localisation only applies where a specific law or contract demands it.

What the Privacy Act actually requires

Many teams assume Australian privacy law forces personal information to stay onshore. For most organisations it does not. Australian Privacy Principle 8 deals with disclosing personal information to an overseas recipient. Before you do, you must take steps that are reasonable in the circumstances to ensure the recipient does not breach the APPs.

The OAIC's guidance is explicit that APP 8 does not require onshore storage. It is about disclosure, and it carries accountability: if the overseas recipient mishandles the information, the Australian entity can be treated as having done it, even where it took reasonable steps first. There are exceptions, including the individual's informed consent after a clear warning, and a reasonable belief that the recipient is subject to a substantially similar law or binding scheme, provided individuals can access mechanisms to enforce its protections. Being bound by a similar scheme is not enough on its own.

Overseas cloud storage can count as a use rather than a disclosure, but only where a binding contract limits the provider to storing the data, flows the same obligations to its subcontractors, and leaves you in effective control of how the information is handled. In practice that is a contract and evidence exercise. Keeping the data in Australia removes much of it, which is why many teams choose onshore processing even though the law does not force them to.

The OAIC's APP 8 guidelines set out the reasonable steps test, the accountability rule and the exceptions. Read the OAIC guidance on APP 8

Where onshore storage is required

Some regimes do localise. The My Health Records Act 2012 includes a section titled "Requirement not to hold or take records outside Australia", which restricts specified registered operators and service providers from holding My Health Record data, or processing related information, outside Australia. It is far narrower than "healthcare email", and whether it applies to you depends on your role in that system.

Government work can bring its own rules. The Australian Government's Hosting Certification Framework, led by the Department of Home Affairs, certifies providers that host for government, with a Certified Assured level and a Certified Strategic level, the latter for providers that let government set ownership and control conditions. If a government customer asks for certified hosting, a general sending region will not answer it.

What buyers ask in security questionnaires

• In which country is customer data stored, and in which is it processed?
• Do message content, metadata, logs, backups and support tooling stay in that country?
• Which subprocessors can access the data, and where are they based?
• Can staff or support outside Australia read production data?
• Is the data ever replicated or transferred overseas, and under what contract?

Notice that none of these ask whether the vendor has a region setting. They ask about the whole path.

How to check where a vendor handles your email

Start with the vendor's documentation, not the marketing page. Find the data processing agreement and the subprocessor list, then ask three direct questions. Where is message content stored? Where are metadata, event logs and webhook payloads stored? Who outside the region can access either? A sending region only tells you where delivery is routed. It does not answer those questions.

Treat a missing answer as an answer. If a vendor lists a region for sending but is silent on logs and account data, assume the silence covers a gap and ask for it in writing.

How Boundry handles it

Boundry is a transactional email API. Each project is permanently bound to one region and its regional application storage, and Sydney is the only live region today. Project message operations and configured application storage run in that regional plane, and the dashboard calls the regional API directly rather than relaying messages through a central service.

That is residency, not a legal sovereignty guarantee, and it does not replace advice on your own obligations. It does give you a short, checkable answer for the questionnaire.

The regulations directory lists the Australian rules we reference and the sources they come from. See the Australian regulations directory