No. GDPR contains no data residency requirement and no obligation to store personal data inside the EU. It regulates the conditions under which data may move to a third country, which is a different thing entirely: with a valid transfer mechanism in place, personal data can lawfully sit on a server in Ohio. The pressure you are feeling to move everything to Frankfurt is almost certainly contractual or commercial rather than legal.
This article covers why residency and transfers get confused, what actually replaces a residency rule, where genuine localisation requirements do come from, why "EU data residency" from a vendor is almost never total, and why choosing an EU region does not close the question.
Residency And Transfers Are Different Questions
The confusion comes from Chapter V, which restricts transferring personal data outside the EEA unless certain conditions are met. Teams read "restricted" as "prohibited" and conclude that the safe answer is to keep everything in Europe.
But Chapter V is a permission regime, not a prohibition. It says a transfer is lawful where there is an adequacy decision, or appropriate safeguards, or in narrow cases a derogation. Meeting one of those makes the transfer lawful. Nothing anywhere in the regulation says personal data must be stored in the EEA, and nothing conditions your compliance on the physical location of a disk.
The distinction has a practical consequence that runs the opposite way to most people's instinct: a company with everything in an EU data centre can still be badly non-compliant, and a company running on US infrastructure with a proper transfer mechanism, documented assessment and honest disclosure can be fine. Location is evidence about risk. It is not the rule.
The mechanisms themselves — adequacy decisions, the current Standard Contractual Clauses, Binding Corporate Rules, transfer impact assessments — are a substantial subject and our cross-border data transfer guide covers them. This article deliberately stays on the residency myth and hands the transfer machinery to that page.
One point of currency, because it moves: for transfers to the United States, the EU-US Data Privacy Framework adopted in July 2023 provides an adequacy route for organisations that certify to it, sitting alongside the Standard Contractual Clauses that most vendors keep in reserve. Any analysis that stops at the invalidation of Privacy Shield is several years out of date.
Where Real Localisation Requirements Come From
Genuine obligations to keep data in a particular place do exist. They just are not in GDPR.
Member state law can impose them for specific categories, most often health records, and public sector procurement frequently carries location conditions. Sector regulation does the same in parts of financial services and for classified or government-adjacent work. Other countries' laws impose localisation more often than the EU does, which is why a global product ends up with regional infrastructure for reasons that have nothing to do with GDPR.
And then there is the one that actually drives most SaaS roadmaps: customer contracts. An enterprise buyer's DPA says data will be stored and processed in the EEA. That is a commercial commitment, freely entered into, and breaching it is a contract problem rather than a regulatory one — but it is a real problem, and it is enforceable by a counterparty with a strong motive to enforce it.
This is worth being precise about internally, because the two get muddled in the same sentence. "We have to be in the EU for GDPR" is usually false. "We have to be in the EU because we signed something saying we would" is usually true, and it changes who you need to talk to.
"EU Data Residency" Is Almost Never Total
If you do buy regional hosting, the single most important thing to establish is what it excludes — because in every vendor arrangement worth reading, it excludes something.
The recurring pattern across vendors is that content sits in region while the surrounding layer does not. Account and authentication data, billing records, support tickets, telemetry and various categories of metadata frequently stay wherever the vendor's primary systems are. Our piece on Airtable's data residency sets out one published example in detail, including categories of descriptive metadata that never move region at all — and a descriptive base name can be revealing on its own.
Residency is also often a product rather than a default. Our piece on Cloudflare covers a localisation offering that is three separate controls you configure, not a single switch that keeps everything in Europe. Buying "the EU option" and assuming it is comprehensive is how teams end up making residency claims in questionnaires that their own vendor's documentation contradicts.
There is a further trap. Migration is frequently not retroactive: enabling a regional setting governs new data, while everything created beforehand stays where it was until somebody arranges a migration. If you switched last quarter, you may still be storing years of data in the region you thought you had left.
Access Is A Transfer, Even When Storage Is Not
Here is the point that undoes a residency-only strategy.
A transfer does not require data to be copied to another country. Making personal data available to someone in a third country counts. A support engineer in Austin opening a session against your Frankfurt database is a transfer. So is a developer on a US laptop querying production, an offshore contractor with a dashboard login, and a third-country parent company with administrative access to a European subsidiary's systems.
So residency alone does not remove your need for a transfer mechanism. It changes where the data rests, not who reaches it. A company that moved its infrastructure to the EU and left global support and engineering access unchanged has usually solved the easier half of the problem and told its customers it solved both.
The Questions Worth Asking Instead
Who can access production, from where? Does your vendor's support organisation operate from a third country? Do your backups replicate across regions? Is your monitoring or error-tracking pipeline sending data somewhere else entirely? Each of those is a transfer to document, whether or not your primary storage is European.
Common Mistakes With EU Data Residency
Believing GDPR mandates EU storage. It does not, and organising your architecture around a rule that does not exist costs money and solves nothing that a transfer mechanism would not have solved.
Assuming a vendor's residency option covers everything. Metadata, account data, support data and backups routinely sit outside the region. Never repeat a residency claim without stating what it excludes.
Forgetting that access from a third country is a transfer. Storage in Frankfurt with support in Texas is still an international transfer, and it still needs a mechanism.
Confusing a contractual promise with a legal requirement. If a customer DPA commits you to EEA storage, that is binding on you regardless of what GDPR says — and it is breached the moment a new subprocessor lands elsewhere.
Assuming a region switch is retroactive. Enabling residency usually governs new data only. Existing data stays put until someone actively migrates it.
FAQ
Does GDPR require personal data to be stored in the EU?
No. There is no residency or localisation requirement anywhere in the regulation. Chapter V sets conditions for transferring personal data outside the EEA — adequacy, appropriate safeguards such as the Standard Contractual Clauses, or a narrow derogation — and satisfying one of those makes the transfer lawful wherever the servers are.
Does choosing an EU region make us compliant?
No. It can reduce transfers, which reduces one category of risk, but it does not address lawful basis, retention, security, transparency or data subject rights. It also does not eliminate transfers if people outside the EEA can access the data, and it usually leaves several data categories outside the region regardless.
Is remote access from outside the EU a transfer?
Yes. Making personal data available to someone in a third country is a transfer even if nothing is copied or permanently stored there. Support access, engineering access to production and administrative access from a parent company all count, and all need a mechanism and a record.
Why do customers keep asking for EU data residency then?
Because it is a simple proxy for a complicated risk assessment, because their own procurement policy or DPA requires it, and sometimes because their regulator or sector rules do. It is a legitimate commercial requirement. It is just not a GDPR one, and answering it honestly is more useful than agreeing to something you cannot fully deliver.
Closing Thought
Data residency is popular because it is legible. "Our data is in Europe" fits on a slide, survives a procurement review, and feels like an answer. A transfer impact assessment does not fit on a slide.
The awkward part is that legibility is exactly what makes it a poor proxy. It reassures the buyer about the one question they know how to ask, while leaving the harder ones — who can reach the data, under what contract, with what oversight — entirely untouched. Vendors who answer the residency question well and the access question vaguely are usually not hiding anything. They just were not asked.
ComplyDog helps with the part buyers actually need to see: a subprocessor list that stays current as your stack and your regions change, DPA management, and a compliance portal on your own domain where prospects can read your position before they send the questionnaire. You can try it free for 14 days, no credit card required.
