1. What data sovereignty is
  2. Where data sovereignty bites
  3. Australia's answer: APP 8 and offshore disclosure
  4. Data sovereignty is not data localisation
  5. Security obligations follow the data
  6. When Australian law locks data at home
  7. De-identification: the exit ramp
  8. A worked example: the manufacturer with a global stack
  9. Common misconceptions about data sovereignty
  10. When a privacy lawyer earns their fee
  11. The question to ask your cloud provider this week

Data sovereignty is the idea that data is answerable to the laws of the country where it is physically stored or processed. For an Australian business, that usually means customer information sitting on a cloud provider's servers is governed by more than one country's laws at the same time. This article explains what data sovereignty is, how the Privacy Act 1988 (Cth) treats information that crosses Australia's borders, and the practical questions it raises for your business.

What data sovereignty is

Sovereignty is the authority a state exercises over what happens inside its borders. Data sovereignty applies that idea to information. When your data sits on servers in another country, the local laws of that country can reach it. A court or regulator there may be able to compel access to it, and the people who handle it may owe duties under that country's rules. At the same time, Australian law continues to apply to you as the business that collected the data.

The result is that one file can be subject to two or more legal systems at once. That is the heart of data sovereignty. It is not a single rule you can look up. It is an overlap of rules, and the overlap is what creates the compliance risk.

Where data sovereignty bites

Data sovereignty becomes your problem anywhere data physically travels. The common situations are:

  • Cloud services: A customer relationship management platform, accounting system or file-storage service that keeps data in overseas data centres.
  • Overseas branches: A business function handled by your own office in another country, which needs access to customer information.
  • Third-party processors: Payroll providers, marketing platforms, helpdesk operators or IT support firms located outside Australia.
  • Backups and sub-processors: A provider's own subcontractors, which may sit in a third country you never considered.

The difficulty is that businesses frequently do not know where their data actually sits. An Australian-branded provider can run its servers in Singapore, Ireland or the United States, and may change data centres or add sub-processors without telling you.

The stakes are not hypothetical. In the OAIC's Australian Community Attitudes to Privacy Survey 2020, 70 per cent of Australians said protecting their personal information is a major concern, and 35 per cent named surveillance by foreign entities as a privacy risk. Your customers expect you to know what happens to their data, and the law expects more than an expectation.

Australia's answer: APP 8 and offshore disclosure

The Privacy Act 1988 (Cth) regulates this through the Australian Privacy Principles (APPs), which bind most Australian businesses with an annual turnover above $3 million, plus smaller businesses in certain sectors such as health. The key principle for data sovereignty is APP 8, which deals with cross-border disclosure of personal information.

Before disclosing personal information to a recipient outside Australia, APP 8 requires you to take steps that are reasonable in the circumstances to ensure the recipient does not breach the APPs. What is reasonable depends on the sensitivity of the information, the recipient's reputation and location, and the contractual protections you put in place.

Two features of APP 8 make it more demanding than it first appears.

First, you stay accountable after the data leaves. Under s 16C of the Privacy Act 1988 (Cth), if an overseas recipient mishandles personal information in a way that would breach the APPs, the recipient's act is treated as your act. You cannot outsource the obligation, only the performance of it.

Second, the exceptions are narrower than they sound. APP 8.2 disapplies the reasonable steps requirement where you reasonably believe the recipient is covered by a law or binding scheme that protects the information in a way that is at least substantially similar to the APPs, or where the individual has been expressly told their information may not be protected to that standard and has consented anyway. Relying on a bare consent checkbox, without a genuine warning and a genuine belief about the recipient's protections, is a weak position.

Data sovereignty is not data localisation

The two ideas are often confused, and the confusion produces opposite mistakes.

Data localisation is a rule that data must stay inside a particular country's borders. Data sovereignty is a description of which country's laws govern data wherever it happens to be. Australia has few general localisation rules, but it has important specific ones, discussed below.

Getting the distinction wrong cuts both ways. If you assume localisation rules are everywhere, you may refuse useful offshore arrangements that the law allows. If you assume they are nowhere, you may send data offshore that a sector-specific rule locks to Australia.

Security obligations follow the data

Sending data offshore does not lower the security bar. APP 11 requires an APP entity to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access, modification or disclosure, and expressly includes technical and organisational measures.

The bar is higher for sensitive information, which includes health information, political opinions and sexual orientation. For sensitive data held offshore, the practical steps that look reasonable are encryption at rest and in transit, restricted access, and contractual commitments from the provider that survive its own subcontracting.

When Australian law locks data at home

For some data, Australian law does impose localisation. The clearest example is the My Health Record system. Under s 77 of the My Health Records Act 2012 (Cth), the operators and registered service providers in that system must not hold, take, process or handle records outside Australia, subject to narrow exceptions. A health business participating in the system cannot simply follow APP 8 and store offshore.

The lesson generalises. Before moving any category of data offshore, check whether a sector-specific law, a government contract, or an industry code restricts where it can be stored. APP 8 is the default position, not the whole picture.

De-identification: the exit ramp

The Privacy Act 1988 (Cth) protects personal information, which the Act defines as information about an identified individual, or an individual who is reasonably identifiable. The Act now also defines de-identification: personal information is de-identified if it is no longer about an identifiable individual, or an individual who is reasonably identifiable.

If information is genuinely de-identified, it falls outside the Act's protections and most of the cross-border questions above fall away. The trap is that de-identification must be real. If names are removed but a unique customer number, a birth date and a postcode remain, an individual may still be reasonably identifiable, and the information remains personal information. Masking a few fields is not the same as de-identifying a dataset.

A worked example: the manufacturer with a global stack

Consider a family-run Australian manufacturer with a retail website and a trade customer base. It keeps its customer database in a United States software platform whose servers sit in Singapore and Ireland, and it uses a support provider in the Philippines that can view customer names, addresses and order histories.

APP 8 is engaged twice. Each disclosure, to the platform and to the support provider, requires reasonable steps. For the platform, reasonable steps look like checking its security certifications, confirming where its servers and sub-processors are located, and getting written commitments that it will protect the data in line with the APPs. For the support provider, reasonable steps look like restricting access to what the support team actually needs and including the same protections in the contract.

The consequences of getting this wrong are concrete. If the platform suffers a breach and mishandles the data, s 16C treats the manufacturer as having breached the APPs itself. If the support provider loses customer records, the same attribution applies. And if the loss is an eligible data breach, Part IIIC of the Privacy Act 1988 (Cth) requires the manufacturer to give a statement to the OAIC as soon as practicable and to notify affected individuals, or publish the statement if notification is not practicable. The manufacturer cannot point to its providers; the law points back at it.

Common misconceptions about data sovereignty

Several beliefs about data sovereignty are common, and each can lead to an expensive mistake:

  • An Australian provider means Australian storage: Provider nationality says nothing about server location. An Australian company can and often does store data overseas. What matters is where the data physically sits.
  • The cloud provider carries the responsibility: Under s 16C, the disclosing business remains accountable for how an overseas recipient handles the data. A contract with the provider manages the risk; it does not transfer it.
  • De-identification makes the problem disappear automatically: Only genuine de-identification does. If an individual remains reasonably identifiable, the information is still personal information.
  • Data sovereignty means data must stay in Australia: Generally false. APP 8 permits offshore disclosure where reasonable steps are taken. Localisation is the exception, applied by specific regimes such as the My Health Records system.

When a privacy lawyer earns their fee

The reasonable steps standard under APP 8 is assessed case by case, which is why a privacy lawyer earns their fee at the planning stage, not the crisis stage. A practitioner can help you map where each category of personal information is stored and who can access it, review cloud contracts for data residency commitments, sub-processor controls and breach notification flow-downs, and structure de-identification so it genuinely removes the data from the Act's reach.

A lawyer is also the difference between a managed breach and an escalating one. When an eligible data breach occurs, the questions of whether to notify, whom to notify and how quickly are time-sensitive and fact-sensitive. Getting them wrong matters. A serious interference with privacy now carries a maximum civil penalty for a body corporate of the greater of $50 million, three times the value of the benefit obtained, or 30 per cent of adjusted turnover, under s 13G of the Privacy Act 1988 (Cth).

The question to ask your cloud provider this week

If you take one action from this article, ask your cloud provider where your data physically resides, in writing, and ask for the list of sub-processors. If the provider cannot answer, that is itself a finding: your reasonable steps position under APP 8 is thin, and your ability to respond to a breach is weaker than you think.

The decision this forces is practical. Before you sign the next renewal or the next platform subscription, decide whether your contracts document where data is stored, who can access it and what happens on breach. The focus question to answer about your own business is this: if the OAIC asked you today where each category of customer data is held, could you answer from your records rather than from a guess?