July 4, 2026

Salesforce Data Sovereignty in New Zealand: There's No NZ Region, So What Actually Protects Your Data?

Salesforce has no New Zealand region, so your data sits offshore. What data residency, the US CLOUD Act, and NZISM actually mean for NZ gov and health orgs.

TL;DR

Salesforce has no data centre or Hyperforce region in New Zealand. NZ customers run offshore: historically in the United States, and now optionally in the Australia Hyperforce region for eligible instances.
"Our data is in Australia" is a statement about residency, where the bytes sit, not about sovereignty, whose laws reach them. Because Salesforce is a US company, the US CLOUD Act can compel access to the data regardless of where it is stored.
The NZ Privacy Act 2020 does not require your data to stay onshore. It keeps your agency accountable for the information wherever it goes, which shifts the question from "where is it" to "what protects it."
For government and health work the controls that actually count are contractual (a data processing agreement), cryptographic (encryption with keys you hold, so the provider cannot read the data), access-based, and evidential (a documented risk assessment against NZISM and the relevant privacy codes).
The honest answer to an RFP's "is our data in New Zealand" is no, and here is the layered protection that makes that acceptable.

What You'll Learn

Where NZ Salesforce data actually lives, and how to check your own instance
The difference between residency and sovereignty, and why the CLOUD Act makes it matter
What the NZ Privacy Act 2020 and NZISM actually require of an offshore SaaS
How to answer the data-location question in a government or health procurement honestly
The specific controls that turn "offshore" into "defensible"

The Problem

Every New Zealand government or health Salesforce procurement asks the same question early, and often first: where is our data stored? The buyer usually wants to hear "in New Zealand," and the honest answer is that it is not, because Salesforce has no New Zealand region. What happens next decides the deal. A vendor who fumbles this, or who papers over it with "it's in Australia now, so you're fine," either loses trust or makes a claim they cannot stand behind under scrutiny.

The confusion is that two different questions get collapsed into one. "Where is the data stored" is about residency. "Whose laws can reach the data" is about sovereignty. They are not the same, and for a US-headquartered provider they can point in different directions: data can sit in a Sydney data centre while still being reachable under US law. A procurement team that only asks about the map pin has not actually assessed its risk, and a supplier who only answers the map-pin question has not actually addressed it.

Common questions this article answers:

Is my Salesforce data stored in New Zealand, and if not, where?
Does moving to the Australia region make us data-sovereign?
What do the NZ Privacy Act and NZISM actually require for offshore data?

Quick Answer

Salesforce has no New Zealand region, so your data is offshore. Older NZ orgs typically sit in a United States region; with Hyperforce, eligible instances can have data residency in Australia, which runs on cloud infrastructure in Sydney. That is residency: the physical location of the data at rest. It is not sovereignty. Salesforce is a US company, so the US CLOUD Act can compel it to produce data no matter which region stores it. New Zealand law does not forbid this: the Privacy Act 2020 lets you hold personal information offshore while keeping your agency accountable for protecting it, and NZISM and government policy expect a risk assessment for offshored data rather than an outright ban. So the protection that matters is not the storage location. It is the combination of a strong contract, encryption with keys you control so the provider cannot read the data, tight access controls, and a documented assessment against the frameworks that apply to you. Confirm where your own org runs by checking your instance on Salesforce Trust Status, and treat the residency choice as one control among several, not the answer on its own.

Where NZ Salesforce data actually lives

There is no Salesforce data centre in New Zealand, and no NZ Hyperforce region. Hyperforce, Salesforce's public-cloud infrastructure model, offers data residency in a set of countries that includes Australia, Canada, France, Germany, India, Japan, the United Kingdom, and the United States. New Zealand is not on that list.

For a New Zealand customer that leaves two realistic locations. Older orgs provisioned before Hyperforce commonly run in a United States region. Newer or migrated instances can, where eligible, have data residency in the Australia region, which Salesforce runs on public-cloud infrastructure in Sydney. Australia is the nearest thing to "local" a New Zealand org can get, and for many buyers it is a meaningful improvement over United States hosting, but it is still offshore.

Do not assume which one you are on. Check it. Your instance's region is visible on Salesforce Trust Status, and your My Domain and instance details tell you which instance you run on. If a procurement answer depends on data location, confirm your actual region rather than repeating what the last person believed. Eligibility to sit in the Australia region depends on your instance and the clouds you use, so if Australian residency matters to a deal, confirm it with Salesforce for your specific org rather than assuming it is automatic.

What about a New Zealand region?

For the first time, the local infrastructure exists. AWS opened its Asia Pacific (New Zealand) Region in Auckland in September 2025, a multi-billion-dollar investment with in-country data residency, and Salesforce Hyperforce runs on AWS. So a New Zealand Hyperforce region is now technically feasible in a way it was not a year ago. That said, Salesforce has not announced one, and New Zealand is not on any published Hyperforce roadmap, so it changes nothing about where your data sits today. It is worth watching, because if Salesforce ever lights up a New Zealand region, the residency half of this conversation changes overnight. The sovereignty half, the CLOUD Act exposure, does not, because that turns on who owns Salesforce, not where the servers are.

Residency is not sovereignty, and the CLOUD Act is why

Residency is where the data is stored. Sovereignty is which government's laws can compel access to it. For a provider headquartered in the same country as the data, those questions have the same answer. For Salesforce serving a New Zealand customer from Australia, they do not.

Salesforce is a United States company. Under the US CLOUD Act, a US provider can be compelled by US legal process to produce data in its custody or control regardless of where in the world that data is physically stored, a reach the US Department of Justice sets out in its own CLOUD Act guidance. So data resident in Sydney is still potentially reachable under US law, because the company holding it is subject to US jurisdiction. Moving from a US region to the Australia region reduces some risks, latency, alignment with an Australian buyer's expectations, distance from routine US operational access, but it does not place the data beyond US legal reach. Anyone who tells a New Zealand agency that Australian hosting makes them "sovereign" is overstating it.

This is not a reason to avoid Salesforce. It is a reason to stop treating the storage location as the whole answer, and to put controls in place that hold even if a legal-access question is ever raised.

What NZ law and NZISM actually require

The reassuring part is that New Zealand's own rules are not asking for the impossible.

The Privacy Act 2020 does not require personal information to be stored in New Zealand. It works on accountability: your agency remains responsible for the personal information it holds, including when a provider stores or processes it overseas on your behalf. Where the overseas provider holds the information as your processor, or agent, it is treated as still held by you rather than disclosed, so what matters is the safeguards you put around Salesforce, not the map pin. Where an overseas party is instead a separate recipient of the information, Privacy Principle 12 (IPP 12) governs that cross-border disclosure, allowing it only where the recipient is subject to comparable safeguards or the person authorises it. For health information the bar is higher in substance: the Health Information Privacy Code and, for suppliers to the health system, the HISO security expectations set stronger requirements around safeguarding and handling, but again they are about protection and accountability rather than a blanket onshore mandate.

For government, the rules expect a risk assessment, not an automatic no. Under the government's Cloud First policy, agencies adopt public cloud on a case-by-case basis after a risk assessment, and may hold information classified RESTRICTED or below in a public cloud service whether it is hosted onshore or offshore. The Digital Public Service's Cloud Jurisdictional Risk guidance goes straight to the heart of this article: it tells agencies to assess how foreign governments can lawfully access data held by a provider subject to their laws, which is exactly the CLOUD Act question. The framework anticipates this situation and tells you to reason about it and evidence your reasoning, rather than to rule it out. One nuance worth knowing: the policy nudges agencies to host RESTRICTED information onshore over time where a suitable New Zealand service exists, which is part of why the arrival of local infrastructure discussed above matters.

That reframes the whole conversation. The question a procurement team should be asking is not "is it in New Zealand," it is "given that it is offshore, what protects it, and can you show me." That is a question a well-run Salesforce implementation can answer well.

The controls that make offshore defensible

If geography is not the control, these are. Layer them, and document each one, because in a government or health context the documentation is part of the control.

A data processing agreement. Get Salesforce's data processing terms in place and understand what they commit to: sub-processors, breach notification, the residency option you have selected, and the handling of legal-access requests. This is the contractual floor, and a procurement team will want to see it.

Encryption with keys you control. This is the strongest technical answer to the sovereignty concern. Salesforce Shield Platform Encryption lets you encrypt sensitive data at rest, and with Bring Your Own Key you supply and control the key material. Cache-Only Key Service goes further: Salesforce holds no persistent copy of the key and fetches it from your key service only when needed, so if you withhold the key the data cannot be decrypted. Data that is encrypted with a key the provider does not hold is far less exposed to a compelled-access scenario, because producing ciphertext without the key is producing very little. This is the control that most directly addresses the CLOUD Act worry, and it is worth the design effort for sensitive workloads.

Access controls and monitoring. Least-privilege permissions, strong authentication, IP and session controls, and event monitoring so you can see who accessed what. Sovereignty concerns are partly about external legal reach, but most real-world data exposure is ordinary over-permissioning and weak access control, which are entirely within your power to fix.

A documented risk assessment. Assess the offshore arrangement against NZISM, the Privacy Act, and, for health, the Health Information Privacy Code and HISO expectations, and write it down. Name the jurisdiction risk, state the controls that mitigate it, and record the residual risk and who accepted it. For a government or health buyer, a supplier who arrives with this assessment already done is a very different proposition from one who has never thought about it.

We have written separately about how to map Salesforce findings to these frameworks precisely, control by control, in Mapping Salesforce security to NZISM, the NZ Privacy Act and ISO 27001, and about the specific stakes for clinical data in Why Salesforce Health Cloud needs its own security review.

Answering the procurement question honestly

When the RFP asks where the data is stored, the answer that wins trust is direct and layered:

"Salesforce has no New Zealand region, so the data is hosted offshore. We run in the [US / Australia] region, and where eligible we use the Australia region to keep data within Australasia. Because Salesforce is a US company, offshore hosting carries US legal-jurisdiction exposure under the CLOUD Act, which we address with Shield Platform Encryption using keys we control, a data processing agreement, least-privilege access with event monitoring, and a documented risk assessment against NZISM and the relevant privacy codes. Here is that assessment."

That answer does three things a "it's in Australia, you're fine" answer does not: it is accurate, it shows you understand the real risk, and it demonstrates the controls that manage it. In a market where most vendors get this question wrong in one direction or the other, getting it right is a genuine advantage.

Frequently Asked Questions

Q: Is my Salesforce data stored in New Zealand?

A: No. Salesforce has no New Zealand data centre or Hyperforce region. New Zealand orgs run offshore, typically in a United States region for older instances, or in the Australia region for eligible Hyperforce instances. Check your own instance on Salesforce Trust Status rather than assuming, because the answer varies by org.

Q: Does moving to the Australia region make us data-sovereign?

A: No. It changes residency, where the data is stored, not sovereignty, whose laws can reach it. Salesforce is a US company, so the US CLOUD Act can compel access regardless of whether the data sits in Sydney or the United States. Australian hosting is a real improvement for latency and for staying within Australasia, but it does not place the data beyond US legal reach.

Q: Does the NZ Privacy Act require us to keep data in New Zealand?

A: No. The Privacy Act 2020 allows personal information to be held offshore. It keeps your agency accountable for protecting that information wherever it is, so the safeguards you apply matter more than the storage location. Health information carries stronger safeguarding expectations under the Health Information Privacy Code, but still no blanket onshore requirement.

Q: What single control most reduces the sovereignty risk?

A: Encryption with keys you control, using Shield Platform Encryption with Bring Your Own Key or the Cache-Only Key Service. If Salesforce does not hold your key, it cannot decrypt the data, which is the most direct answer to a compelled-access concern. Pair it with a data processing agreement and least-privilege access.

Q: Can a New Zealand government agency use Salesforce at all, then?

A: Yes. NZISM and government policy expect a documented risk assessment for offshored data, not an outright ban. Agencies can use offshore cloud services where the risks are assessed and mitigated proportionately. A well-run implementation with the controls above, and the assessment written down, meets that expectation.

Key Takeaways

There is no NZ Salesforce region. Data is offshore: United States for older orgs, or the Australia region for eligible Hyperforce instances. Confirm your own on Trust Status.
Residency is not sovereignty. The US CLOUD Act reaches Salesforce data wherever it is stored, so Australian hosting is not sovereignty.
NZ law does not mandate onshore storage. The Privacy Act keeps you accountable for protection; NZISM expects a documented risk assessment, not a ban.
The real controls are contractual, cryptographic, access-based, and evidential. Keys you control are the strongest answer to the jurisdiction risk.
Answer the procurement question honestly and in layers. "It's in Australia, you're fine" is both wrong and a red flag; the layered answer wins trust.

What's Next?

Recommended Reading:

Action Items:

Confirm which region your org actually runs in on Salesforce Trust Status before answering any data-location question.
If sensitive data is involved, design Shield Platform Encryption with keys you control, and get the data processing agreement in place.
Write the offshore risk assessment against NZISM and the relevant privacy codes, and keep it ready for procurement.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.