“Where is my data stored?” is the most common question we get that is not about a feature. It is a reasonable question, it has a specific answer, and the answer has legal consequences. This piece is about both halves: the law that applies to an Australian software business, and the engineering decisions that follow from it.
None of this is legal advice. It is the reading that informed our own choices, and a solicitor should check yours.
The law you are actually under
The Privacy Act 1988 (Cth) and the thirteen Australian Privacy Principles are the framework. They are not the GDPR, and porting a European privacy policy word for word produces something that is wrong in both jurisdictions.
Four parts matter most when you are deciding where things run.
APP 1 — open and transparent management. You need a privacy policy that says what you collect, why, and who you give it to, in terms a person can actually follow. This is the principle a vague policy fails.
APP 8 — cross-border disclosure. Before you disclose personal information to an overseas recipient, you have to take reasonable steps to ensure they handle it consistently with the APPs. And here is the part people miss: under section 16C you generally remain accountable for what that overseas recipient does with it. Sending data offshore does not send the responsibility with it.
APP 11 — security. Reasonable steps to protect information, and to destroy or de-identify it when you no longer need it. Retention is a security control, not a filing preference.
The Notifiable Data Breaches scheme. If a breach is likely to result in serious harm, you notify affected individuals and the OAIC. You want to have decided in advance who makes that call and how fast, because the middle of an incident is a terrible time to design a process.
One more thing worth saying plainly: there is still a small-business exemption for organisations under a turnover threshold, and it has been recommended for removal more than once. Do not build a product whose privacy posture depends on staying under it. We treat the APPs as binding on us regardless, which is both simpler and the position we would end up in anyway.
Region choice is an engineering decision with a legal shadow
Since the Sydney region opened in 2012, and Melbourne in 2023, there has been no real excuse for an Australian consumer product to default to a region in North America. The gap in service availability that used to justify it has mostly closed.
The practical rule we follow: primary data in an Australian region, and anything that leaves the country is deliberate, documented and named in the privacy policy.
That rule is easier to state than to hold, because data leaves in ways that are not obvious:
- A third-party API that only runs in one overseas region. Every request you send it is a disclosure.
- Error and crash reporting, which routinely ships stack traces containing user identifiers, request payloads and sometimes content.
- Email delivery, where the body of a transactional email may contain personal information and the provider is usually offshore.
- Backups and logs, which are easy to leave in whatever region the tooling defaulted to.
- Support tooling, which accumulates the most sensitive information you hold because customers paste it in.
- Model providers, if your product sends user content to an AI service. That is a disclosure like any other, and it belongs in the policy with everyone else.
The audit that matters is not “where is the database”. It is “list every system that has ever seen a customer’s personal information, and where it runs”. The first list is short and comforting. The second one is the real one.
Questions to ask a vendor before you sign
We keep the vendor list deliberately short, and each new one gets the same questions:
- Which regions can this run in, and can I pin it to Australia?
- Where are backups held, and can they leave the region I picked?
- Which sub-processors do you use, and where are they?
- What are your breach notification commitments, and how fast?
- What happens to my data when I leave, and how do I get it out?
- What certifications do you hold, and when were they last audited?
If a vendor cannot answer the first three quickly, that is the answer. A provider that has thought about data residency has the documentation ready, because everyone asks.
Say it out loud in the policy
The APPs require you to disclose, so you may as well do it usefully. Our privacy pages name each provider, what it does for us, and where the data may be held. It is a table, it fits on a screen, and it is the first thing a careful customer reads.
Two habits make that table honest:
Write it when you add the vendor, not when someone asks. Policies that are updated in response to a question are always out of date at the moment they matter.
Say what you do not know. “We prefer Australian regions and use them where a provider offers them” is true and verifiable. “All data is stored in Australia” is a claim you have to be able to defend for every system on the list above, including the ones you added last week.
What is coming, and worth watching
The Privacy Act reforms that began in 2024 are not finished. The changes already in motion include a statutory cause of action for serious invasions of privacy, and new transparency obligations around automated decisions that significantly affect people, with policies expected to disclose them from late 2026. Further tranches have been flagged for years, and the small-business exemption is a standing candidate.
The practical response is not to guess at the detail. It is to build so that the likely direction is cheap: collect less, keep it for less time, know exactly where it is, and be able to explain any automated decision your product makes about someone. Every one of those is good engineering before it is compliance.
What we do
For our own products the position is simple enough to state in a sentence: primary data sits in an Australian region, the vendor list is short and published, everything that crosses a border is named, and retention is measured in the shortest period the law and the product allow.
This corporate website is the easy case. It has no accounts, no forms, no cookies and no analytics, so the only personal information involved is a delivery log and whatever you choose to put in an email to us. That is the whole disclosure, and it fits in a paragraph of our website privacy policy. Each product publishes its own, because each product holds its own data.
Next in the series: designing for distance, where latency stops being a legal question and becomes an engineering one.