Data Residency: Where Your Data Actually Lives

Most people asking about data residency have been handed a requirement by a customer, a regulator or a procurement questionnaire, and are trying to work out whether their current setup satisfies it.

The short answer is that a region setting in a cloud console is not the same as a residency guarantee, and the gap between the two is where compliance problems live.

Three terms that get used interchangeably and should not be

Data residency is where data is physically stored. It is a location question, and it is usually the one being asked when someone says "our data has to stay in the US."

Data sovereignty is which laws apply to that data. It is a jurisdiction question, and location does not settle it. Data held in one country by a company incorporated in another may be subject to both legal systems.

Data localisation is a legal requirement that certain data must not leave a defined territory at all. It is the strictest of the three and it usually comes from national legislation covering specific data types.

These get conflated constantly, including in vendor documentation, and the conflation matters because satisfying one does not satisfy the others. Storing EU customer data in an EU region addresses residency. It does not by itself resolve sovereignty questions about a US-incorporated provider, which is what the Schrems II ruling and the ongoing debate around the CLOUD Act are ultimately about.

When someone hands you a requirement, the first job is working out which of the three they actually mean. Frequently they do not know.

Why a region setting is not a residency guarantee

Choosing a region tells you where your primary storage sits. It does not tell you the whole story, and there are at least five places data ends up that people forget to check.

Backups and replication. Cross-region replication configured for disaster recovery moves data to another region by design. That is the point of it. It is also a residency exposure if nobody checked which region.

Metadata and logs. Telemetry, audit logs, monitoring data and usage records frequently aggregate centrally regardless of where the workload runs. Whether that counts depends on whether the metadata contains personal data, and often it does.

The control plane. The management layer of a cloud service may run in a different location from the resources it manages, which becomes a question when someone asks not just where data rests but who can reach it.

Support access. If a support engineer in another jurisdiction can access your environment to troubleshoot, your data is accessible from that jurisdiction. Support models are a residency question and they are almost never in the residency documentation.

Subprocessors. CDN nodes, email delivery, monitoring platforms and analytics tools all receive some portion of your data, and each has its own geography.

The practical implication is that residency is a property of the whole architecture rather than a checkbox on the storage service.

What actually drives the requirement

Four categories, roughly in order of how often they come up.

Regulation. GDPR governs transfers of personal data outside the EEA, requiring an adequacy decision or appropriate safeguards. Sector-specific rules add their own constraints, and public sector procurement frequently carries national requirements attached to it.

Contracts. A large customer's data processing agreement can impose stricter residency terms than any law does. This is now the most common driver in B2B software, because enterprise procurement pushes its own compliance obligations down the supply chain.

Procurement questionnaires. Related but distinct. Winning the deal requires answering the question, whether or not a regulation is behind it.

Latency and gravity. Not compliance at all, but a real reason to care where data sits. Distance costs milliseconds, and large datasets are expensive to move, as we covered in cloud cost optimization.

What to ask an infrastructure provider

A residency questionnaire that only asks "which region" is not doing its job. These are the questions that produce useful answers.

Where is the primary data physically stored? Name the facility or at minimum the metropolitan area, not just the region label.

Where do backups and snapshots live? Same facility, different facility, different country.

Is any data replicated across regions by default? Defaults matter more than options here, because defaults are what happens when nobody configures anything.

Where does the control plane run? And where does its data live.

Who can access the environment, and from where? Support model, escalation paths, and the geography of the people involved.

Who are the subprocessors and where do they operate? This should be a documented list, not an answer someone composes on a call.

Is the hardware dedicated or shared? Single tenancy does not by itself satisfy residency, but it substantially simplifies the answers to several of the questions above.

What evidence can you provide to an auditor? The difference between a provider saying something and a provider being able to demonstrate it is the difference between passing an audit and not.

Which entity holds the contract, and where is it incorporated? This is the sovereignty question, and it is the one most often left off.

Single tenancy and why it simplifies the answers

Multi-tenancy is not a residency violation. It does complicate the evidence.

On shared infrastructure, your data sits on hardware that also holds other customers' data, and the isolation is logical rather than physical. That is a perfectly normal arrangement and it satisfies a great many compliance regimes. What it makes harder is answering questions of the form "demonstrate that only your data was on this hardware during this period."

Dedicated infrastructure gives you a simpler story. Specific hardware, in a specific facility, running only your workloads. When an auditor asks who else was on the machine, the answer is nobody, and that is straightforward to evidence.

Whether that simplicity is worth anything depends entirely on how strict the obligation is. For most organisations it is not necessary. For regulated workloads, it turns a difficult conversation into an easy one. We wrote about that trade in more depth in private cloud vs public cloud for regulated industries and in the audit-readiness checklist.

Building for residency rather than retrofitting it

Retrofitting is expensive, so a few decisions made early save a great deal later.

Know your data before you place it. Not all of it carries the same obligation, and treating everything as if it were the most restricted category is a common and costly over-correction.

Keep replication explicit rather than default. Every copy of a dataset is a copy that has a location, and defaults create copies nobody decided on.

Document the architecture as you build it. The residency answer you can produce in an afternoon is worth far more than the one that requires a two-week archaeology exercise every time a questionnaire arrives.

And treat encryption and key management as a separate question. Where the keys are held, and who can access them, is a distinct control from where the data sits. It does not substitute for residency, and it is frequently what a sophisticated auditor asks about next.

Frequently asked questions

What is data residency? Where data is physically stored. It is distinct from data sovereignty, which concerns which laws apply, and data localisation, which is a legal prohibition on data leaving a territory.

Is data residency the same as data sovereignty? No. Residency is about physical location, sovereignty is about legal jurisdiction. Data can be stored in one country and still be subject to another country's laws, depending on who operates the infrastructure and where that entity is incorporated.

Does GDPR require data to stay in the EU? Not exactly. GDPR restricts transfers of personal data outside the EEA unless there is an adequacy decision or appropriate safeguards in place. Storage location and transfer legality are related but separate questions.

Do backups count for data residency? Yes. A backup is a copy of the data and has its own location. Cross-region replication is one of the most common causes of unintended residency exposure.

Does choosing a cloud region guarantee data residency? It determines where primary storage sits. Backups, metadata, logs, control plane data and support access can all sit elsewhere, so a region setting alone is not a complete answer.

How do I prove data residency to an auditor? With documented architecture, provider attestations, a subprocessor list and evidence of where data is stored and replicated. What counts as sufficient depends on the framework and the auditor.