Data residency is the geographic location where an organization stores and processes its data, including backups, logs, and disaster recovery copies. It matters because the country or region where data sits decides which laws apply to it. GDPR does not require EU personal data to stay in the EU, but it does regulate how that data leaves. Stricter rules, called data localization, exist in some countries and sectors.
The question comes up in every infrastructure purchase. It is sharper with hosted AI inference, because prompts and outputs often contain personal data. Geodd runs AI inference for production teams, so region and data handling matter when you choose a provider.
This guide explains why residency matters, how it differs from data sovereignty and data localization, what GDPR and other laws actually require, and how to put residency into practice. It ends with the specific problems that cloud and AI workloads create.
Why data residency matters to your organization
Data residency matters because the place your data sits decides which laws, regulators, and courts can reach it. Get that wrong and you face fines, stalled deals, and expensive re-architecture.
Legal exposure and fines
GDPR sets the benchmark. Violating its international transfer rules can bring fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher. In May 2023, Ireland's Data Protection Commission fined Meta €1.2 billion for moving EU user data to the United States without adequate safeguards. At the time it was the largest GDPR fine ever issued.
Smaller companies rarely see headline fines. They do face regulator inquiries, audit findings, and breach duties. A GDPR personal data breach generally has to be reported to the regulator within 72 hours, and you cannot report on data you cannot locate.
Location decides which rules apply, so where your data sits is a legal decision, not only an infrastructure one.
Contracts and customer trust
Residency is often a contractual promise before it is a legal one. Enterprise, public sector, healthcare, and financial buyers write storage regions into security questionnaires and data processing agreements. If you cannot answer precisely, deals slow down. Expect questions like these:
- In which country or region is production data stored?
- Where do backups and disaster recovery copies live?
- Which subprocessors touch the data, and where are they based?
- From which countries can your staff access customer data?
Security, access, and performance
Different jurisdictions have different rules on government access and disclosure. Keeping data in a region with strong protections, and holding the encryption keys in that region, reduces your exposure to foreign legal demands.
Residency also affects speed. A region close to your users cuts latency. The trade-off appears when one region has to serve a global audience, and you need regional caching or replication that still respects your rules.
Data residency vs data sovereignty vs data localization
Data residency is where data is stored and processed. Data sovereignty is whose laws and authorities govern it. Data localization is a legal mandate that certain data stay inside a jurisdiction. People use the three terms interchangeably, but they answer different questions.
Side-by-side comparison
| Concept | Core question | Where the rule comes from | Typical example |
|---|---|---|---|
| Data residency | Where is the data stored and processed? | Business policy, contracts, regulatory expectations | Customer data pinned to an EU cloud region, with backups in the same region |
| Data sovereignty | Which country's laws and authorities apply? | The legal system of the jurisdiction where data sits or the provider is based | Choosing a region because its law limits foreign access |
| Data localization | Must the data stay inside the border? | Binding national or sector law | A statute requiring certain records to remain in the country |
Residency is usually a choice you make, often to satisfy a contract or a transfer rule. Localization is a rule imposed on you, with little or no room for transfers. Sovereignty is the legal lens you use to decide which region to pick.
Why residency alone does not give you sovereignty
Storing data in a region does not remove it from the reach of other countries' laws. A provider headquartered in one country can be compelled by that country's authorities to produce data, even when the servers are abroad. The US CLOUD Act is the best-known example.
So a residency commitment answers "where is it?" and not "who can demand it?". If sovereignty matters to you, ask both questions. Check where the data sits, and check which legal systems the provider and its subprocessors answer to.
Residency tells you where your data is. Sovereignty tells you who can compel access to it. You need to check both.
GDPR data residency requirements and other laws
GDPR contains no general data residency requirement. It does not say personal data must stay in the EU. It regulates transfers outside the EU and the European Economic Area (EEA), and it requires a lawful safeguard whenever data leaves. This section is general information, not legal advice, so confirm your situation with counsel.
What GDPR requires for transfers
Under GDPR's transfer rules, personal data can leave the EU or EEA only on a recognized basis. The main mechanisms are:
- Adequacy decisions. The European Commission has found some countries' protections adequate. For the United States, this covers companies certified under the EU-US Data Privacy Framework, adopted in July 2023. Verify that a vendor's certification is current.
- Standard contractual clauses (SCCs). Pre-approved contract terms between exporter and importer, usually paired with a transfer risk assessment.
- Binding corporate rules (BCRs). Internal rules approved by regulators for transfers inside a corporate group.
Two details catch teams out. Remote access can count as a transfer, so a support engineer outside the EEA viewing EU customer records is covered, even if the database never moves. And some member states or sectors, such as public bodies and healthcare, add their own location rules on top of GDPR.
GDPR does not say "keep it in the EU." It says "prove it is protected wherever it goes."
Requirements by region
| Region | Residency or localization rule | What to watch |
|---|---|---|
| EU and EEA (GDPR) | No general residency rule. Transfers need a lawful safeguard. | Backups, logs, support access, subprocessors |
| United States | No single federal residency mandate. Rules come from sector laws such as HIPAA and GLBA, state privacy laws, and contracts. | Government and education contracts that require in-country or in-state hosting |
| China | Localization duties for certain data, with assessments for exports. | Whether your data counts as personal information or important data |
| Russia | Initial collection of Russian citizens' personal data must use servers in Russia. | Database location at the point of collection |
Many other countries, including Australia, Brazil, Canada, Japan, South Africa, and the UAE, have passed privacy laws since GDPR. Most regulate transfers rather than ban them, but details vary, so check requirements for every country where you have customers. In the United States, the strictest rule is often a customer's contract, not a statute.
How to put data residency into practice
You put data residency into practice by finding your data, assigning each type a location rule, enforcing that rule in your infrastructure, and collecting proof. Seven steps cover it.
A seven-step process
- Inventory and classify data. List personal, regulated, and confidential datasets, and every system that holds them.
- Assign a rule per class. For example: "EU customer data stays in EU or EEA regions, with transfers only under SCCs."
- Pin regions. Set storage, compute, analytics, and logging to approved regions, and block deployments elsewhere.
- Cover every copy. Backups, replicas, failover regions, caches, search indexes, and exports must follow the same rule as production.
- Control access and keys. Use regional encryption keys, least-privilege access, and logged support sessions. Document the transfer mechanism for any access from outside the region.
- Vet vendors. Ask for hosting regions, subprocessor lists, and written residency commitments in the contract.
- Monitor and test. Alert on region drift and cross-region replication, and run failover tests to confirm recovery stays in-region.
Most failures happen at step 4. Production gets pinned carefully, and the copies get forgotten.
Pinning the production database is the easy part. Residency fails in the backups, logs, and support tools around it.
A worked example
Picture a US software company with customers in Germany and France. It hosts its production database in an EU region and believes it is compliant. A review of every data copy shows a different picture:
| Data copy | What actually happens | Fix |
|---|---|---|
| Production database | Stored in the EU region | None needed |
| Nightly backups | Default storage class replicates to a US region | Pin backups to an EU region |
| Application logs | Sent to a US-hosted monitoring tool | Scrub personal data, or use an EU endpoint |
| Support access | US team views EU customer records remotely | Treat as a transfer: SCCs, least privilege, access logs |
One of four copies was compliant. After the review, all four match the company's stated rule, and the company can show evidence for each.
Data residency for cloud and AI workloads
Cloud and AI services break residency through copies you did not plan for. The data you send to a model is rarely the only data created, because providers generate logs, caches, and files around every request.
Where AI data hides
When you use a hosted model, check each of these for location:
- Prompts and outputs. They can contain names, emails, or health details typed by users.
- Uploaded files. Documents sent for analysis may be stored by the provider.
- Logs and telemetry. Request logs can capture prompt content.
- Embeddings and vector stores. They are derived from personal data and usually carry the same obligations.
- Fine-tuning datasets. Training data is the longest-lived copy.
The same applies to chat products such as ChatGPT. Residency options depend on the plan and the provider's current regional offerings, so read the provider's documentation rather than assuming a region.
Questions to ask an inference provider
Ask these before you integrate, and get the answers in writing:
- Are prompts, outputs, and uploaded files stored, and for how long?
- Is API data used to train models?
- In which region does inference run by default, and can you choose one?
- Do region options differ by model?
- Which subprocessors handle data, and where?
- What are the breach-notification terms?
For reference, here is how Geodd answers. It does not store API prompts, outputs, or uploaded files unless separately agreed in writing. It does not use API data for model training. For EU customers, it hosts API inference in EU data center infrastructure by default. Its active regions are US-EAST and EU-NORTH in Norway, which is in the EEA, so GDPR applies there. Geodd is GDPR ready, its SOC 2 compliance is pending, and it notifies customers of personal data breaches within 72 hours where feasible. Regional availability can differ per model, so check the page of the exact model you plan to use.
A provider that states its storage, training, and region policies plainly makes your own compliance work easier.
Make location a decision, not a default
Data residency is about where your data is stored and processed. Data sovereignty is about whose laws govern it, and data localization is a binding mandate to keep data in-country. GDPR does not require EU data to stay in the EU, but it does require safeguards whenever it leaves, including for remote access. In the United States, contracts and sector rules usually set the practical limits.
The practical work is the same everywhere. Map your data, set a rule per class, pin every copy, vet your vendors, and keep evidence. If your workloads include AI, apply the same discipline to prompts, logs, and uploaded files. When you are ready to evaluate regions and data handling for production models, run production inference with Geodd's inference service.
