Topics: Custom software & SaaS
Want this done for your business? Get a fixed quote or book a free 30-minute call.
In this guide
- What do data sovereignty and data residency mean for a small business?
- Does the Privacy Act require you to keep data in Australia?
- Does offshore developer or support access count as a disclosure?
- Which parts of your system should be hosted onshore?
- What should your contract and architecture include?
- When do government or enterprise clients demand Australian hosting?
- Frequently asked questions
- Map your data before you build
Quick answer: Australia's Privacy Act doesn't ban storing personal information overseas, but APP 8 makes you accountable for how overseas recipients handle it. For most businesses the sensible default is to keep production databases, backups and logs in an Australian cloud region, limit and log any offshore access, and write hosting location and sub-processors into your contracts.
Ask three advisers whether your customer data must stay in Australia and you may hear three different answers. Most of the confusion comes from blending separate questions: where the data is stored, which country's laws can reach it, and who can look at it. This guide pulls those apart, then walks through a typical business system component by component.
What do data sovereignty and data residency mean for a small business?
Residency is where the data physically sits; sovereignty is whose laws can reach it; access is who can see it. A system can tick one box and fail another.
| Term | Plain meaning | The question to ask |
|---|---|---|
| Data residency | The location where data is stored and processed | Which region holds the database, backups and uploaded files? |
| Data sovereignty | Which jurisdictions' laws apply to the data and its provider | Could the provider or a sub-processor be compelled to hand data over under foreign law? |
| Data access | Who can view, query or export it, and from where | Can anyone outside Australia log in to production or download records? |
A database in a Sydney region run by a US-owned cloud provider gives you residency. It doesn't give you complete sovereignty, because a US company can in some circumstances be compelled under US law, such as the CLOUD Act, to produce data it controls wherever it's stored. For most private businesses, residency plus tight access control is what clients and regulators actually ask about. Full sovereignty usually only becomes a hard requirement in government and defence work.
Does the Privacy Act require you to keep data in Australia?
Generally, no. It requires you to stay accountable for personal information you send overseas. Per the OAIC's APP guidelines, before disclosing personal information to an overseas recipient you must take reasonable steps to ensure it won't breach the Australian Privacy Principles, which in practice means a contract. Under section 16C, you can be held responsible if that recipient mishandles it. There are exceptions, for example where the individual consents after being expressly told the protections won't apply, but most businesses rely on contracts rather than exceptions.
Two other points catch people out:
- Who's covered. The OAIC sets the small business threshold at an annual turnover of $3 million or less, but some smaller businesses are covered regardless of turnover, including health service providers and businesses that trade in personal information.
- Your privacy policy. APP 1 expects it to say whether you're likely to disclose personal information overseas and, where practicable, to which countries.
Our guide to Privacy Act obligations for software covers the wider principles; this article stays on location and access.
Does offshore developer or support access count as a disclosure?
It can, even when the database never leaves Australia. The OAIC's guidance treats making personal information accessible to an overseas recipient as a disclosure, and an offshore contractor who can query production data is exactly that. By contrast, a cloud provider that only stores data under contractual limits, without using or accessing it, is generally treated as a use rather than a disclosure. Your own employees working from overseas are part of your organisation, so their access is generally a use as well, although every other APP still applies.
If any developer or support person outside Australia works on your system, a few controls do most of the work:
- Masked or synthetic data for development and testing, so real customer records never reach a laptop.
- Role-based production access, granted per task and removed afterwards, rather than standing admin rights.
- Audit logs of every production login, query and export, kept where the offshore team can't edit them.
- No bulk exports without approval from someone in Australia.
- A contract that names the countries involved and binds the supplier to the APPs.
Our article on working with offshore developers covers the commercial side, and role-based access permissions explains how to design the controls.
Which parts of your system should be hosted onshore?
Keep the systems of record onshore, then check every add-on that quietly copies data elsewhere. The database is rarely where data escapes; the email tool, the error tracker and the AI feature are.
| Component | Recommended location | What to check |
|---|---|---|
| Production database | Australian region | Read replicas and failover targets stay in Australia too |
| Backups and snapshots | Australian region | Cross-region backup defaults are switched off or pointed onshore |
| File uploads and documents | Australian storage bucket | Signed, expiring links rather than public URLs |
| Application and error logs | Australian region, or scrubbed | Logs often capture names, emails and request bodies |
| Email and SMS sending | Provider with a clear processing statement | Message content usually includes personal details |
| Analytics and session recording | Configured to mask form fields | Many tools process data in the US or EU by default |
| AI features | Australian-hosted models where available | Prompts may carry customer data to another region |
| Helpdesk and CRM | Wherever practical, disclosed in your privacy policy | Exports, attachments and integrations |
AWS, Microsoft Azure and Google Cloud all run regions in Sydney and Melbourne, and Azure adds Canberra. Picking the region is the easy part; our guide to choosing a cloud host compares the providers more broadly.
What should your contract and architecture include?
Write the hosting rules down, then build the system so it can't drift from them. A clause nobody can verify is only a promise.
For the development and support contract:
- Hosting location for production, backups and disaster recovery, named by region
- A list of sub-processors, with notice before any change
- Which people and countries may access production, and on what terms
- Breach notification to you within a set number of hours, so you can meet your own obligations under the Notifiable Data Breaches scheme
- Data return and deletion on exit, with a documented handover; our software handover checklist lists what to collect
- Your right to request access logs or an audit
For the architecture:
- Infrastructure defined in code, with the region pinned
- Encryption at rest and in transit, with keys held in the Australian region
- Single sign-on and multi-factor authentication for every admin account
- Separate production, staging and development environments
- An automated job that produces masked copies of data for testing
When do government or enterprise clients demand Australian hosting?
When they handle sensitive data, they'll usually push the requirement down to you through the contract. Per the Digital Transformation Agency, Commonwealth agencies hosting sensitive government data and systems must use providers certified under its Hosting Certification Framework. A small supplier rarely needs certification itself, but expect tender questions about where data lives, whether services have been through an IRAP assessment and how you align with the Australian Signals Directorate's Essential Eight.
Large enterprises, health groups, universities and financial services firms tend to send security questionnaires that ask the same things in their own words. If you plan to sell to them, choosing Australian hosting from day one is far cheaper than migrating a live system after you've won the contract. If that's your path, we build software for Australian businesses with these questions in mind.
Frequently asked questions
Is it legal to store Australian customer data overseas?
Generally, yes. The Privacy Act doesn't prohibit it, but APP 8 requires reasonable steps to ensure overseas recipients handle the data in line with the APPs, and you can remain accountable for their mistakes. Some contracts and sector rules go further and require onshore hosting.
Does using an offshore developer breach the Privacy Act?
Not automatically. If an offshore contractor can access personal information, treat it as a cross-border disclosure: have a contract binding them to the APPs, give them masked data wherever possible, and control and log any production access.
Which cloud regions count as Australian hosting?
Regions physically located in Australia, such as the Sydney and Melbourne regions of AWS, Microsoft Azure and Google Cloud, plus Azure's Canberra regions. Check that backups, replicas and add-on services also stay in those regions, not just the main database.
Do small businesses have to comply with APP 8?
Businesses under the $3 million turnover threshold are often exempt from the Privacy Act, but not all. Health service providers and some others are covered regardless of size, and clients may impose APP-style terms by contract anyway.
What if our AI tool sends data to the US?
Then personal information in the prompts is likely being disclosed overseas, so APP 8 applies. Use an AI service that runs models in an Australian region where one is available, strip identifiers before sending, and confirm the provider doesn't keep or train on your data.
Map your data before you build
The cheapest time to decide where data lives is before the first table is created. If you're planning a new system or worried about an existing one, we'll map where your data sits and who can reach it, then quote the work as part of our custom software development service. Tell us about your system and we'll come back with a fixed quote, usually within one business day.