"Sovereign Australian SaaS" is having a moment. Government procurement rules, the Privacy Act reforms, and a decade of news stories about overseas data leaks have pushed the question to the front of every buying decision. But the term is also being used loosely. And if you don't ask the right questions, you can buy a product that says "Australian" on the tin while your customer data sits in Oregon.
What data residency actually means
Data residency is the physical location of the servers storing your data. Not your vendor's head office. Not their support team. The disk, in the rack, in the data centre.
This matters because the law that applies to your data is broadly the law of the country the servers sit in. US-hosted data can be subject to US legal process, including the CLOUD Act, even if the business that owns it is Australian.
The three questions to ask your SaaS vendor
1. Where are the servers?
Be specific. Ask for a region code, not "Australia". A vendor on Google Cloud should say australia-southeast1 (Sydney). AWS Sydney is ap-southeast-2. If they can't give you a region code, they probably don't know.
2. What about backups and replicas?
Some vendors host primary data in Sydney but replicate to US regions for disaster recovery. Under APP, that may still count as a disclosure to an overseas recipient. Ask about backup locations too.
3. Who has access?
Even if data sits in Sydney, support engineers sitting in Bangalore may have admin access. Ask whether admin access is restricted to Australian-based staff. This often matters more to regulators than the raw hosting location.
Why Brand and Go made this choice
Brand and Go runs entirely in australia-southeast1. Firestore, Cloud Functions, and Storage all pinned to Sydney. No backups offshore. No US support team with admin. This costs more than the default and it's a design constraint for everything we build, but it's the only way to give Australian businesses a straight answer when they ask "where does my data live?"