A server in Sydney is not data sovereignty.
It’s worth saying that plainly, because plenty of cloud sales pitches would like you to believe otherwise. “Your data stays in Australia” is a sentence that sounds like an answer. It’s actually the start of about six more questions.
If you lead a government agency, a department, or a public sector organisation of any kind, you’re under pressure to modernise. Citizens expect digital services that work like the ones they use everywhere else. Your teams are stretched. Legacy systems are creaking. And somewhere in your inbox is a proposal from a cloud vendor with a very confident compliance slide.
This piece is for the moment before you sign. Not to scare you off the cloud. The cloud is where modern government services get built, and the security story for major platforms is genuinely strong. But the sovereignty questions are real, they’re specific, and the people asking them on your behalf should know what they’re looking for.
Three words that get used interchangeably (and shouldn’t be)
Start here, because most of the confusion in this space comes from three terms being blurred into one.
Data residency is geography. It answers one question: where does the data physically sit? A data centre in Sydney or Melbourne satisfies residency. That’s all it satisfies.
Data sovereignty is jurisdiction. Which country’s laws can reach your data, and who can be legally compelled to hand it over? This is where residency stops helping you. Data stored in Australia by a provider headquartered overseas can still be subject to foreign legal process. Location doesn’t erase jurisdiction.
Data localisation is a legal mandate that certain data must never leave the country. Australian health records under the My Health Records Act are the classic example.
The practical upshot: when a vendor says “your data stays onshore,” they’re making a residency claim. Whether that adds up to sovereignty depends on who owns the provider, where they’re incorporated, who can access the systems, and what their contracts actually say. Those are the questions worth asking. Very few procurement conversations get to them.
The frameworks doing the heavy lifting
The good news is you’re not working from scratch. Australia has built real machinery for this, and it’s more usable than most people expect.
The Hosting Certification Framework, administered by the Department of Home Affairs, exists precisely because “trust us, it’s secure” wasn’t good enough. Under the Framework, all sensitive government data, whole-of-government systems and systems rated at PROTECTED must be hosted using certified services. It has two meaningful tiers. Certified Strategic is the highest level of assurance, available only to providers who let the government specify ownership and control conditions. Certified Assured provides safeguards through financial penalties if a provider significantly changes its ownership or operations.
That distinction between the tiers is the framework quietly telling you something important: the government’s biggest worry isn’t where the servers are. It’s who controls the company that runs them, and what happens if that changes.
Then there’s IRAP, the Information Security Registered Assessors Program run by the Australian Signals Directorate. IRAP assessments involve independent assessors evaluating a system’s security controls against the Australian Government Information Security Manual, and agencies use the resulting reports to evaluate cloud services before authorising them. An IRAP report isn’t a rubber stamp. It’s evidence. It tells your authorising officer what controls exist, what’s effective, and what residual risk you’re accepting. If a vendor can’t produce one, that’s your answer.
Sitting behind both is the Protective Security Policy Framework, which sets the classification and risk posture your hosting decisions have to align with.
Where Salesforce fits into this
Since this is the platform we live in, let’s be specific about it rather than vague.
Salesforce runs on Hyperforce in Australia, its public cloud architecture delivered locally on AWS infrastructure. Customer data is generally stored in the country where the org is located, provided the services being used are available in that Hyperforce region. On the assurance side, the coverage has become genuinely broad. Salesforce completed an IRAP assessment against PROTECTED-level controls for the Salesforce Platform and Agentforce in 2025, following earlier assessments of Tableau, MuleSoft and Marketing Cloud.
That’s a strong position. It’s also not the whole picture, and an honest partner will tell you where the edges are.
Residency has fine print. Some Einstein features for Australian orgs on Hyperforce can process data outside your geographic location. Default configurations don’t always match your obligations, and specific features need to be checked one at a time against your data classification. And the jurisdictional question doesn’t vanish: Salesforce is a US company, which means the Australia-US CLOUD Act Agreement is relevant reading. Notably, the Agreement prohibits the US from targeting Australian persons, including government entities and corporations. That’s a meaningful safeguard. It’s also the kind of thing you want to understand before you sign, not discover in a Senate Estimates briefing afterwards.
None of this is a reason to avoid the platform. Agencies across Australia run citizen services on it. It’s a reason to implement it deliberately, with someone in the room who knows which settings matter.
The questions to put in front of any vendor
Skip the compliance slide. Ask these instead, and write the answers into the contract.
Where is our data stored, processed, and backed up? All three. Processing and backups are where residency claims quietly fall apart.
Which specific services in this proposal are covered by a current IRAP assessment at the classification level we handle? Not the platform generally. The services in the proposal.
What is your certification level under the Hosting Certification Framework, and for which facilities?
Under what circumstances could a foreign government compel access to our data, and what is your process when a request arrives? A vendor who’s thought about this will answer in detail. A vendor who hasn’t will change the subject.
Who in your organisation can access our environment, from where, and how is that logged?
If we leave, how do we get our data out, in what format, and how quickly?
That last one gets asked least and matters most. Sovereignty isn’t only about who can reach your data. It’s about whether you can walk away with it.
The honest bit
Here’s the part vendors won’t tell you: perfect sovereignty doesn’t exist in commercial cloud. Every arrangement is a set of trade-offs between capability, cost, and control. The agencies that navigate this well aren’t the ones that found a magic provider. They’re the ones that classified their data properly, understood which trade-offs they were making, and documented why.
That work is unglamorous. It’s also the difference between a defensible decision and a hopeful one.
We’re a 100% onshore team, which means the people configuring your Salesforce environment are in Australia, working under Australian law, in your timezone. We’ve delivered projects into government and regulated industries where these questions weren’t hypothetical, and we’ve learned that the sovereignty conversation goes best when it happens early, before the architecture is locked in and every change costs triple.
If your agency is weighing up a Salesforce implementation and the sovereignty questions are piling up, let’s talk them through. No pitch, just a straight conversation about what your data classification actually requires.
