Data residency is the physical or geographic location where your data is stored and processed. For an organization running HPC or AI workloads, it decides which laws can reach your data, who can access it, and where your servers, backups and support staff are allowed to sit. This guide explains the term, separates it from localization and sovereignty, and walks through how to plan infrastructure so residency requirements are met by design instead of patched in after launch.
TL;DR
- Data residency is about where data and metadata physically live and how they move across borders. It is not only a storage question: backups, logs, remote support and outsourced processing all count.
- Residency is a location fact, localization is a legal mandate to keep data in-country, and sovereignty is about which government's laws govern the data.
- Start with a data map: which countries you serve, what data types you hold, and where each type may be stored, processed and accessed. Involve legal and compliance from day one.
- Cross-border transfers are governed by mechanisms such as adequacy decisions and standard contractual clauses, and no single global model exists.
- For HPC and AI, residency should shape hardware sourcing, site selection and logistics before the first server is ordered.
Table of Contents
- What data residency means
- Data residency vs. data localization vs. data sovereignty
- What residency requirements actually cover
- How to find out which requirements apply to you
- Cross-border transfers: the main legal mechanisms
- Designing HPC and AI infrastructure around residency
- Common mistakes to avoid
- Perspective
- How Dormedia helps
- FAQ
- Sources
What data residency means
The simplest definition is the geographic location of your data, identifiable by the country or region that holds the relevant data centers, servers or processing infrastructure. IBM's explainer, updated in October 2025, uses this framing. Put plainly: if someone asks "where is our data?", the answer should be a country or region, not "the cloud".
A more complete view comes from the joint paper by the Cloud Standards Customer Council and the Object Management Group. It describes residency as covering where data and metadata are located, how they move across jurisdictions, and how location-related risks are controlled. According to that paper, location can affect which laws apply, the chance of unintended or government access, security, reliability, service delivery, speed, business continuity and the ability to meet contract requirements.
That last list is why residency lands on the desk of a CTO and not only a lawyer. It touches architecture, procurement and operations as much as policy.
It is not only about personal data
Many teams assume residency is a privacy topic. The same CSCC and OMG paper says residency concerns are not limited to personal or health information. They can also involve sovereign, genomic, biometric or other non-personal data. If you train models on proprietary research, government-related datasets or biometric samples, residency questions apply to you even if no customer name appears anywhere in the data.
Data residency vs. data localization vs. data sovereignty
These three terms are used interchangeably in marketing copy, and they should not be. IBM's comparison and Salesforce's explainer draw the same lines:
| Term | What it describes | Who sets it | Typical question it answers |
|---|---|---|---|
| Data residency | The physical place data is stored or processed | Often your own choice or contract, sometimes driven by law | Where does the data live? |
| Data localization | A legal mandate that specified data stays within a country or jurisdiction | Government | Am I required to keep it here? |
| Data sovereignty | Which jurisdiction's laws and authorities govern the data, sometimes regardless of physical location | Law and legal authority | Whose rules apply to it? |
Two practical consequences follow. First, meeting residency does not automatically settle sovereignty: data stored in one country can still be subject to the laws of another, for example through the provider's home jurisdiction. Second, localization is the strictest of the three. If a rule says data must remain in-country, a transfer mechanism will not save you. You need infrastructure on the ground there.
The City of Toronto's cloud guideline illustrates the overlap. It states that data stored outside Canada can be subject both to the foreign jurisdiction's laws and to applicable Ontario and Canadian requirements. Those conflicts have to be managed through contracts and legal advice. A municipal document, but the logic holds for any enterprise.
What residency requirements actually cover
Teams often scope residency to "the primary database" and miss everything around it. The CSCC and OMG paper lists the situations where residency concerns arise: data and metadata location and movement, cross-border consolidation, remote backups or mirroring, foreign technical support, and outsourced processing.
Translated into an HPC and AI environment, that means checking:
- Primary storage and compute. Where training data, checkpoints and inference inputs sit while a job runs.
- Metadata. Job logs, telemetry and indexes can carry sensitive information even when the underlying files do not leave the country.
- Backups and disaster recovery. A replica in another country is a cross-border copy.
- Support and administration. A remote engineer viewing a console from abroad can count as access from that location.
- Outsourced processing. Any subcontractor that handles the data brings its own location into scope.
- Model artifacts. Weights trained on regulated data may need the same treatment as the data, depending on your legal advice.
How to find out which requirements apply to you
There is no universal rulebook, so the first job is to document your own situation. A useful assessment, drawn from the CSCC and OMG approach and from cloud-architecture guidance that asks for the same inputs, records the following:
- The countries and industries you serve.
- Data types and their classification: personal, health, financial, proprietary, sovereign.
- Use cases for each type, including training, inference, analytics and archiving.
- Acceptable locations for storage and processing, per data type.
- Whether data is exported, to whom, and how it is protected in transit.
- Constraints on centralizing logs.
- Backup, recovery and retention rules.
- Restrictions on who may view or share the data, and from where.
- Encryption, tokenization or masking options, and whether sensitive and non-sensitive workloads can be separated.
The same guidance is explicit that the customer remains responsible for compliance and that legal and compliance teams should be involved. Treat the output as a living document, not a one-time form. The CSCC and OMG paper describes residency analysis as starting with identifying where data is, determining which laws and risks apply, and controlling where the data is or goes. In its words, that makes it an operational governance activity and not merely an inventory.
A worked example
Imagine a health-analytics startup with customers in the US, Germany and Canada. It wants one GPU cluster to train a diagnostic model.
The data map shows three classes: de-identified imaging data, identifiable patient records and the startup's own model code. The imaging data may be allowed in a single region under contract. The identifiable records from German customers fall under EU rules and probably need a transfer mechanism or in-region processing. The Canadian public-sector customer may require data to stay in Canada, as the Toronto guidance on procurement does: it prioritizes Canadian data centers and providers and recommends assessing classification, risks of storage, access and transfer outside Canada, contractual controls, breach mitigation and the ability to extract data if legal conflicts arise.
The result might be one regional cluster per jurisdiction for identifiable data, and a shared environment for de-identified data. That is an architecture and sourcing decision, which is why it belongs in the design phase. If your workloads handle protected health information in the US, our guide to a HIPAA-compliant LLM deployment covers the adjacent compliance questions.
Cross-border transfers: the main legal mechanisms
Residency rules rarely say "never move data". More often they say "move it only under conditions". Here is how the main frameworks work.
European Union
The European Data Protection Board's Guidelines 05/2021 set out three cumulative conditions for a GDPR Chapter V transfer: the exporter is subject to the GDPR, the personal data is disclosed or made available to another controller or processor, and the importer is in a third country or international organization. When all three are met, the transfer may occur only under a mechanism such as an EU adequacy decision or appropriate safeguards under Article 46. The EDPB adds that even when Chapter V does not apply, the controller remains accountable for lawful processing and security.
One of the most common safeguards is the standard contractual clauses. The European Commission issued modernized SCCs on 4 June 2021 for transfers from controllers or processors in the EU/EEA, or otherwise subject to the GDPR, to controllers or processors outside the EU/EEA that are not subject to the GDPR.
Non-personal data is treated differently. The EU's Your Europe guidance says that such data can generally be stored, processed, transferred and managed anywhere in the EU, including on cloud servers, subject to exceptional restrictions based on public security under national law. The same page says that from January 2027 cloud customers will be able to switch providers and move data out of a cloud service free of charge, which matters when you plan an exit path.
United Kingdom
The UK Information Commissioner's Office keeps a guide to international transfers, last updated on 15 January 2026. It explains when the transfer rules apply and gives a three-step test, examples and practical compliance measures for organizations and data-protection officers. Check it directly for the current position, since it is revised periodically.
Canada and beyond
As the Toronto guideline notes, cloud services can move information between data centers worldwide, which creates additional privacy and security risk when data crosses borders. At the global level, the OECD finds that there are four broad approaches to cross-border data flows: unrestricted movement with no data-protection regulation, movement with ex-post accountability, movement conditional on safeguards such as adequacy or contractual clauses, and case-by-case movement requiring authorization. Jurisdictions combine them, often differently by data category. So a multinational deployment cannot assume one transfer model fits every country.
In the US, there is no single federal residency law. Requirements tend to come from sector rules, contracts and customers' own procurement terms, so your customer list often matters more than your headquarters. Confirm specifics with counsel.
Designing HPC and AI infrastructure around residency
Compute-heavy environments make residency harder than ordinary SaaS. Datasets are large, so moving them is slow and costly. GPU capacity is scarce, so teams are tempted to run wherever hardware is available. And hardware lead times are long, so a wrong site choice is expensive to reverse.
We suggest building the following checks into the design phase.
1. Decide the unit of separation
Separate sensitive and non-sensitive workloads so that only the former need in-region infrastructure. Encryption, tokenization or masking can narrow what must stay local, but whether they satisfy a specific rule is a legal question, not an engineering one.
2. Choose sites against the rule, not the spec sheet
List the jurisdictions where data must remain, then evaluate power, cooling, connectivity and colocation options in those places. A site that is cheap and fast but sits in the wrong country is worth nothing for regulated data. For planning a move between facilities, see our data center migration planning guide, which covers sequencing and cutover.
3. Map the supply chain to the deployment
Residency starts when the first byte lands on the first disk, but the project starts months earlier with sourcing, shipping and customs. Hardware that must be installed in several countries needs vendors, logistics and tax treatment lined up per country. Hardware itself can also face separate export rules, a different question from where data sits; our partners' note on dual-use technology export rules explains that side of cross-border technology movement. Managing multiple vendors across regions is its own discipline, covered in our global vendor management guide.
4. Plan logs, backups and support as first-class data flows
Write down where logs are centralized, where backups are replicated, where retention clocks run and which support staff can see what, and from where. These are the flows that audits and customers tend to ask about, and the ones the CSCC and OMG paper flags.
5. Keep an exit path
The Toronto guidance recommends being able to extract data if legal conflicts arise. Design for portability: documented formats, tested restores and contracts that allow you to leave without data hostage costs.
Common mistakes to avoid
- Treating residency as a one-time project. Rules, vendors and customer contracts change. Review the data map on a schedule and when you enter a new country.
- Confusing a provider's region label with compliance. A region name tells you where a primary service runs. It does not tell you where metadata, support access or backups go. Ask.
- Leaving legal out until launch. Technical teams can build exactly what was asked and still miss a mandate. Bring legal and compliance into the design review.
- Assuming one transfer mechanism covers everything. As the OECD work shows, approaches vary by country and by data category.
- Ignoring non-personal data. Proprietary research, biometric and sovereign datasets may still carry restrictions.
Perspective
Our view: decide residency before you buy hardware.
Most residency problems we see in HPC and AI projects are sequencing problems. The data policy gets written after the cluster is ordered, and then the cluster is in the wrong place, has the wrong vendor support model or cannot be shipped where the law says it must live.
We have worked in this field since 2011 and have been deeply engaged in HPC and AI since 2017. Our approach is to treat residency as a design input alongside power, cooling and performance. That means agreeing which data must stay where, then sourcing, shipping and installing infrastructure in those places with our network of vendors and logistics specialists.
We also think residency work should include the unglamorous parts: tax and tariff treatment, delivery timelines per country and ongoing support that does not quietly move data access offshore. A compliant design that cannot actually be delivered on time is not compliant for long.
Dormedia
How Dormedia helps
If your residency map points to infrastructure in more than one country, the hard part is turning policy into a delivered, supported deployment. We design, source, deploy and scale HPC and AI infrastructure for organizations that need customized configurations, with services covering servers and inventory, components, data center solutions, global shipping, tax and tariff solutions, project management, strategic advisory and ongoing support. We do not publish prices, as each engagement is scoped to the project.
To talk through a residency-driven deployment, start at dormedia.ai. If you are comparing available hardware for a regional build, see our available inventory.
FAQ
What is meant by data residency?
Data residency is the physical or geographic location where data is stored and processed, such as a particular country or region. It also covers how data and metadata move between jurisdictions and how the risks of that movement are controlled. In practice it applies to backups, logs and remote access as well as primary storage.
What is the difference between data sovereignty and data residency?
Residency is where the data physically sits. Sovereignty is which government's laws and authorities apply to the data, sometimes regardless of where it is stored. Localization is a third idea: a legal mandate that specified data stay within a country.
What are data residency requirements?
They are the legal, contractual or policy conditions on where data may be stored, processed, accessed and transferred. They come from privacy laws, sector rules, government procurement terms and customer contracts. They differ by country and data type, so you need a data map and legal advice to know which apply to you.
Does data residency apply to non-personal data?
Yes, it can. Residency concerns can involve sovereign, genomic, biometric and other non-personal data. Within the EU, non-personal data can generally move freely across member states, but exceptional public-security restrictions under national law can apply.
Who is responsible for meeting residency requirements when I use a cloud or hosting provider?
You are. Providers can offer regional options, but the customer stays responsible for compliance. Involve your legal and compliance teams and confirm in the contract where data, metadata, backups and support access are located.
Sources
- Data Residency Challenges, a joint paper by the Cloud Standards Customer Council and the Object Management Group
- What Is Data Residency? (IBM)
- Data Sovereignty vs. Data Residency (IBM)
- What Is Data Sovereignty? (Salesforce)
- Data Residency and Hybrid Cloud Lens, Scenarios (AWS)
- EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V of the GDPR
- Standard Contractual Clauses (SCC), European Commission
- A guide to international transfers, UK ICO
- Storing and processing data in Europe: the free flow of non-personal data, Your Europe
- Information Management Guideline: Data Residency for Cloud Technology, City of Toronto
- Trade and cross-border data flows, OECD
- Dual-Use Technology: Meaning, Export Rules and Defence Use