Zendesk Data Storage and Residency

Somebody in procurement asks where the data lives. On Zendesk data storage the honest first answer, in most companies, is that nobody has ever checked.

Start free trial All guides

Where your Zendesk data storage actually sits

A Zendesk account's service data lives in the infrastructure region assigned to it, which for most accounts was decided at signup and never thought about again. It works fine right up until a customer contract or a regulator asks the question.

Zendesk offers regional data hosting as an option for certain regions, letting you specify where primary service data is stored at rest. Which regions are available, and how it is packaged commercially, both change. Get the current list from Zendesk rather than from any article, including this one.

If you don't know where your account sits today, that is a question for Zendesk support or your account team, and it takes one email. Better to ask now than during a security review.

Worth separating two things while you're at it. Where the data is stored is one question. Where it's processed, cached, backed up and accessed from are others, and they don't always have the same answer. A reviewer who asks precisely gets a precise answer; a reviewer who asks where is the data gets a region name that turns out to cover less than they assumed.

Residency, localisation and sovereignty are not synonyms

Data residency is a statement about where data is stored at rest. That is a narrower promise than most people hear when the word is used.

Data localisation is stronger: the data does not leave, full stop. Data sovereignty is stronger again: local law governs the data and foreign access is constrained by it. Global SaaS vendors generally offer residency.

The mistake to avoid is quietly upgrading the promise on the way to your legal team. If you tell them the data never leaves the region, make sure that's what the vendor actually committed to in writing.

What residency doesn't guarantee

That nobody outside the region can access it. Support engineers, on-call staff and sub-processors may access data from elsewhere even when it is stored in one place. The DPA and the sub-processor list are where you find out.

That every component is covered. Residency options can apply to core service data and not to every add-on, integration, backup or telemetry stream. Ask which components are in scope, by name.

That transfers stop being a legal question. If personal data crosses a border for any reason, you still need a transfer mechanism. Residency reduces exposure. It does not remove the paperwork.

Compliance with anything. Storing data in a region doesn't make you compliant with that region's law. It's one control among many, and it is not legal advice from us or from anyone else.

Your own copies. The nightly export into a warehouse, the BI tool, the Slack integration. Your residency posture is only as strong as the weakest downstream copy, and that copy is usually one you built yourself.

Moving an existing account

Changing region on an account that already has years of history isn't a toggle. It is a project you run with Zendesk, with a planned window and verification afterwards.

Treat it like a migration, because it's one. Inventory your integrations, find anything that hardcodes a URL or an address, and plan to retest the ones that matter. Ask directly about downtime and about what happens to historical data, because that's where the surprises live.

The most common one is that historical data and new data behave differently. Ask early, get the answer in writing, and tell whoever is expecting a clean answer about your archive.

Deciding whether you need it

You probably do if a regulator, a public sector buyer or a large enterprise contract names a region, or if you handle a category of data with a localisation rule attached to it.

You probably don't if the requirement traces back to a general nervousness about the cloud. That's a real concern and residency is not the control that answers it. Access management and retention usually are.

Either way, price it before you promise it, and write down what you've told customers you'll do. Then check the two are still the same thing at renewal.

And if the answer is that you don't need it, write that down too, with the reasoning. The next person who asks will be a customer or an auditor, and a documented decision beats a shrug. It's also the cheapest way to stop the same debate restarting every twelve months when somebody new joins the security team.

FAQ

Frequently asked questions

Where does Zendesk store data, physically?

In regional data centres you can select on the higher tiers. Where does Zendesk store data by default depends on when the account was created, and the Zendesk data location for an existing account can only be changed by Zendesk. The Zendesk data centers list is published in the trust centre.

Where is Zendesk data storage located?

In the infrastructure region assigned to your account, which may or may not be one you chose. Ask Zendesk support or your account team to confirm the current location, since assumptions here are frequently wrong.

Is regional data hosting included in my plan?

It has historically been an option rather than a universal inclusion, and both the region list and the commercial terms change. Confirm availability and cost with Zendesk for your specific account.

Does data residency mean nobody outside the region sees our data?

No. Residency is about storage at rest. Support access, on-call access and sub-processors can involve people elsewhere, and the DPA is where those terms are set out.

Can we move our Zendesk account to a different region later?

Sometimes, as a coordinated project with Zendesk rather than a self-serve setting. Ask about downtime, about integrations and specifically about historical data.

Does hosting in the EU make us GDPR compliant?

No. It removes one class of transfer question and does nothing about lawful basis, retention, request handling or your internal access control.