"Hosted in Australia" is not the same as sovereign

Ask a vendor whether their service is sovereign and you will usually get a fast, confident yes, followed by the name of an Australian region.

That answer is about where the bytes sit at rest. It is a real property and it is worth having. It is also the easiest of the three claims to satisfy, and the one that tells you least.

Here is the distinction that matters when you are writing it into a contract.

Three claims, not one

Data residency. The primary copy of the data is stored in Australia. This is what “hosted in Sydney” means, and it is usually true.

Data sovereignty. The data is subject to Australian law, and no foreign jurisdiction can compel its disclosure. This is a legal question about the corporate structure of the provider, not a technical question about the region.

Operational sovereignty. No person outside Australia can access the data or the systems that hold it, in the course of ordinary operations or support. This is the one that quietly fails.

A service can be fully resident, partially sovereign and not operationally sovereign at all — and every statement made about it will have been literally true.

The seven questions that separate them

These are the ones we ask on behalf of clients. They are deliberately narrow, because broad questions get broad answers.

1. Where do the backups go? Primary region is one question. Replication targets, snapshot storage and disaster recovery are separate ones, and the default configuration in several major platforms replicates cross-region. Ask specifically, and ask for the region name.

2. Who holds the encryption keys, and where does the key service run? Encryption at rest is meaningless as a sovereignty control if the key management service is operated from another jurisdiction. “Customer-managed keys” is the answer worth having, with the key store in-country.

3. Where does support sit — including tier 3 and the on-call escalation? A local service desk in front of an offshore engineering team is very common, and the engineering team is the one with production access. Ask where the escalation path terminates at 3am.

4. Who can access production, and under what break-glass process? Names are not required. What is required is the citizenship, location and vetting standard of the group holding standing production access, and whether privileged access is time-bound and logged.

5. What is the subprocessor list, and how are you told when it changes? Every SaaS product is a stack of other people’s services. The list is usually published, rarely read, and frequently changes with 30 days’ notice buried in a portal.

6. Which parent company is the contracting entity? A US-parented provider is subject to US legal process regardless of where the data sits — the CLOUD Act settled that. This is not a reason to disqualify a vendor, but it is a fact to acknowledge on the risk register rather than discover during an incident.

7. Is telemetry in scope? Logs, metrics, crash reports and support diagnostics are data. They are also frequently exempted from the residency commitment in the fine print, and they are often the most sensitive thing in the environment.

Where assessments help, and what they cover

An IRAP assessment is a useful signal, provided you read what was assessed. The scope statement names a system, a set of controls and a point in time — not a company, and not a whole product portfolio.

Two things follow from that. First, a vendor’s assessment does not extend to your implementation of their product: the shared responsibility split means most of the controls remain yours. Second, an assessment of one service does not cover the adjacent one, however similar the branding.

Read the scope. It is usually one page, and it is the page with the answers on it.

What this looks like in practice

Sovereignty is not a single switch and it is rarely all-or-nothing. The workable position for most agencies is to classify by workload rather than by organisation:

• Decide, per system, which of the three claims is actually required. Not everything needs operational sovereignty, and pretending otherwise inflates cost and slows delivery.
• Write the required claim into the contract as a specific, testable statement — region names, access populations, notification periods — rather than the word “sovereign”.
• Re-check annually. Subprocessor lists, support models and replication defaults all change without anybody telling you.

Our own position on this is a worked example rather than a claim: the mobile threat defence solution we deliver runs in an Oracle Cloud Infrastructure environment we manage, and both the Zimperium solution and that OCI environment carry IRAP assessment at PROTECTED. The assessments belong to those named things. CDTS as a company holds no certification, and any provider who blurs that distinction in their own favour is worth a second question.

More on how we design and run cloud infrastructure.