What is data residency?
Privacy, law and compliance
Data residency is the requirement or design choice that data be stored, and sometimes processed, in a specified geographic location. It is about where data physically lives and where certain computing steps occur. It is not the same as data sovereignty, which is about which laws and legal authorities apply. In practice, data residency is implemented through region choices, architecture, contracts, provider controls, and clear scoping of which data is actually kept in-region.
What this means
If someone asks about data residency, the simplest plain-English question is, "Where does the data actually sit, and where is it handled?" That sounds simple, but in modern cloud and AI systems the answer is often more granular than people expect.
A service may store customer files in one region, run model inference in another, keep logs and billing metadata elsewhere, and use support staff from several countries. So data residency is rarely a single switch. It is a set of location commitments that apply to specific types of data and specific processing steps.
This is also where confusion begins. Data residency is not the same as data sovereignty. Residency is about physical location. Sovereignty is about legal control and jurisdiction. Data can reside in one place and still be affected by legal duties, transfer rules, or government access questions linked to another place. The two ideas are related, but they are not interchangeable.
For leaders, that distinction matters because many conversations about "keeping data local" mix up storage location, processing location, cross-border transfers, contractual controls, and legal jurisdiction. Good decisions depend on separating them.
Why it matters
Data residency matters because it sits at the intersection of compliance, procurement, trust, architecture, and operational resilience. Some organisations face explicit local storage or local processing requirements. Others face sector expectations, customer contract terms, or internal policy rules that are nearly as important in practice.
It also matters because AI systems create new data paths. Prompts, uploaded files, embeddings, fine-tuning data, generated outputs, logs, and evaluation traces can all raise residency questions. A team may think it has solved the problem by choosing an EU or UK region, then discover that one feature stores only customer content in-region while routing metadata or non-content logs elsewhere.
Residency choices can also affect latency and resilience. Keeping data or inference closer to the user can improve performance. On the other hand, tight residency constraints can reduce available regions, failover choices, or supplier options, so there is usually a trade-off between control and flexibility.
Most importantly, data residency can be a board-level trust issue. If a provider cannot clearly explain where your data is stored, where inference happens, what is in scope, what is out of scope, and what still crosses borders, leadership should treat that as a serious diligence gap.
How it works
Data residency works by combining technical design choices with provider commitments and contract language.
The first design choice is location at rest. This is the most common meaning of data residency. It refers to where data is stored when it is sitting in a database, object store, file system, backup, or other persistent layer. In cloud platforms, this is often controlled by selecting a region or multi-region when you create the relevant service or workload.
The second design choice is processing location. This is where the data is actively handled. In AI systems, that includes model inference, embedding creation, indexing, code execution, image processing, and sometimes moderation or safety review. Processing location can matter as much as storage location. A file stored in one region but processed elsewhere may still create transfer or governance issues.
The third design choice is scoping. This is where many misunderstandings arise. Providers often apply residency controls only to defined "customer content" or to specific product features. Account records, billing details, usage analytics, operational metadata, and some logs may be outside scope. That means "data residency enabled" does not necessarily mean every piece of data tied to the service stays in-region.
A fourth element is architecture around replication and failover. Many systems rely on backups, disaster recovery copies, multi-region redundancy, or global services that improve uptime. If those copies or control-plane functions move data outside the target geography, your residency position may be weaker than the sales summary suggests.
In practice, this means you need a data flow map, not just a region selector. Map where data is collected, stored, processed, cached, indexed, backed up, logged, and accessed by support or subprocessors. Only then can you tell whether the residency design matches the requirement.
This is especially important in AI services. As of mid 2026, major providers offer different mixes of storage residency and inference residency. Some allow storage at rest in many regions but offer in-region processing only for a smaller set. Some separate storage controls from inference controls. Some support region controls only for certain models or features. Some still route parts of the workload globally unless you opt into stricter settings.
That means leaders need to ask more precise questions than "Do you support data residency?" Better questions include: Which data types are in scope? Which features are covered? Where does GPU inference run? What still happens outside-region? Are backups local? Are embeddings local? Are logs with content local? Are support processes or subprocessors outside-region?
Now to the legal side. Data residency and international transfer compliance are related, but not identical. Under EU GDPR and UK GDPR, if personal data is made available to a separate organisation outside the EEA or UK, transfer rules may apply. So choosing a local region does not automatically remove every cross-border issue. It may help substantially, but it is not the same thing as proving no restricted transfer occurs.
This is why residency should be thought of as an architectural and contractual control, not as a magical compliance badge. It supports compliance, customer commitments, and procurement goals, but it does not replace legal analysis or supplier diligence.
It also helps to distinguish data residency from data localisation. Residency describes where data is held or processed. Localisation usually refers to a legal requirement to keep data in a particular place, sometimes with tighter restrictions on moving it elsewhere. Not every residency choice is caused by a localisation law. Sometimes the driver is customer trust, sector expectation, or internal policy.
One more practical point: self-hosting can improve residency control, but it does not settle the whole picture either. If your own architecture still uses remote telemetry, external support channels, third-party moderation, or off-region backups, you may still have location exposure.
So the operational truth is simple but demanding. Data residency is about disciplined specificity. You need to know which data, which processing steps, which regions, which exceptions, and which contractual promises actually apply.
Examples
A public sector body may require that citizen documents, prompts, and generated summaries remain in a European region, with clear evidence that the covered features are stored there and that inference also runs there for the approved workload. In that case, storage-only residency may not be enough.
An insurer might want claims documents and extracted claim fields to stay in-country or in-region, but may allow non-content operational logs outside-region if the contract describes that clearly and the legal review accepts it.
A manufacturer may run a local model at the plant edge for equipment triage because internet dependency or cross-border data flow is unacceptable for the workflow. Here data residency is driven by both policy and resilience.
A multinational SaaS buyer may use residency as a customer trust commitment. Even where the law does not strictly require local hosting, customers may insist that their uploaded files and AI-generated artefacts remain within a named geography.
Common misunderstandings
One misunderstanding is that data residency and data sovereignty are the same. They are not. Residency is about where data sits and runs. Sovereignty is about what legal authority applies.
Another is that picking a region means everything stays in that region. Often only some data categories or features are covered. Logs, account metadata, routing, and support processes may be treated differently.
A third misunderstanding is that if data is encrypted, location no longer matters. Encryption is important, but it does not erase contractual, regulatory, transfer, or procurement requirements about where data is stored or processed.
Teams also assume that data residency is only about storage. In AI systems, processing location can be just as important, especially for inference and indexing.
Finally, some leaders believe self-hosting automatically proves residency. It can improve control, but only if the wider architecture, backups, support access, subprocessors, and logging are designed accordingly.
Risks and boundaries
The main risk is vague requirements. If the business says "keep data in Europe" without defining which data, which features, and which processing stages matter, teams can build something that sounds compliant but is not fit for the real requirement.
Another risk is hidden scope gaps. A provider may store customer content in-region while keeping metadata, control-plane activity, or non-content logs outside-region. That may be acceptable, or it may not. The point is that it must be surfaced and assessed.
There is also a resilience trade-off. Strict residency can constrain failover and vendor choice. That may be worth it, but it should be a conscious decision.
Residency is also not a substitute for broader privacy and security controls. Minimisation, access control, encryption, retention, incident response, and vendor management still matter. Data can be perfectly resident and still poorly governed.
This section is practical guidance, not legal advice. If your use case involves regulated personal data, government contracts, health information, financial records, or cross-border processing rights, get advice from the right legal, privacy, and security specialists.
What to do next
Start by turning "data residency" into a precise requirement. Specify which data classes matter, whether you mean storage at rest, inference in-region, endpoint processing, backups, logs, or all of the above.
Then map the workflow end to end. Include prompts, uploads, outputs, embeddings, indexes, backups, analytics, moderation, support access, and subprocessors. You cannot govern what you have not mapped.
Next, challenge suppliers with precise questions. Ask what is in scope, what is out of scope, which regions are supported for which features, and what processing may still occur elsewhere. Ask for the answer in writing.
After that, align the design with contracts and controls. Region settings alone are not enough. Your agreements, operating procedures, retention settings, and audit evidence need to match the architecture.
Finally, review residency periodically. Provider capabilities, feature scope, and region support change over time. A design that meets the requirement now may drift later if new features bypass the same controls.
FAQs
Is data residency the same as data sovereignty?
No. Data residency concerns physical storage and processing location. Data sovereignty concerns legal jurisdiction and control.
Does GDPR always require data to stay in the EU?
Not generally. GDPR includes rules for international transfers outside the EEA, but it does not create a universal rule that all data must stay in the EU.
What is the difference between data residency and data localisation?
Residency describes where data is stored or processed. Localisation usually means a legal requirement to keep data in a particular place.
If a provider offers data residency, does that cover all data?
Not necessarily. Many providers limit residency commitments to specific customer content or features, while account data, logs, or metadata may be treated separately.
Does in-region inference mean all processing stays in-region?
Not always. Some providers distinguish GPU inference from other processing such as authentication, routing, or logging.
How can a leader assess a vendor's residency claim?
Ask for a clear statement of in-scope data, supported regions, covered features, off-region processing exceptions, backup behaviour, and contractual commitments.
Sources
International data transfers (European Data Protection Board). Primary regulatory source for the point that GDPR transfer rules still matter when personal data is made available to another organisation outside the EEA.
International transfers (ICO). Primary regulatory source for the equivalent UK framing that transfer rules apply when personal information goes to other countries.