EU hosting does not mean what most plan pages imply. GDPR does not require that personal data about EU residents physically sit on a server inside the EU or EEA - what it requires is a lawful basis for any transfer outside that zone, documented processing agreements with every company that touches the data, and genuine ability to say where data lives and who can reach it. A server in Frankfurt is not automatically GDPR-compliant, and a server in Virginia is not automatically non-compliant; the distinction that actually matters is data residency (where the bytes sit) versus processor jurisdiction (which country’s courts can compel the company operating the server), and the two do not always point the same direction.
This post is a checklist, not a legal opinion - GDPR compliance is ultimately a legal determination and this is not legal advice. What it covers is the six things a hosting decision actually controls: where data is stored, who processes it and under what agreement, whether the CLOUD Act or an equivalent reaches the provider, where backups and logs end up, and what a data processing agreement needs to say.
Table of contents
- Data residency is not the same question as GDPR compliance
- Data residency versus processor location
- The CLOUD Act, briefly and accurately
- Data processing agreements and subprocessors
- Backups and logs: the part EU hosting claims usually skip
- A practical checklist before calling a setup EU-compliant
- How this fits the rest of the stack
- FAQ
Data residency is not the same question as GDPR compliance
GDPR’s core transfer rule, per Article 30 and the adequacy/SCC framework, is that personal data can leave the EEA if the transfer is covered by an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules - not that it can never leave. A company can be fully compliant while processing data outside the EU, and a company can be non-compliant while storing every byte inside Frankfurt, if the rest of its practices (consent, retention, access controls, breach notification) do not hold up.
That said, keeping data inside the EU is still the simplest way to sidestep the transfer-mechanism question entirely - it is a legitimate simplifying choice, just not a legal requirement in itself. Read a hosting provider’s ‘EU hosting’ claim as ‘this removes one variable’, not as ‘this alone makes us compliant’.
This distinction matters most at the procurement stage, before a contract is signed, because it changes what question to ask a vendor. Asking only ‘is my data in the EU’ gets a yes-or-no answer that settles nothing on its own; asking what transfer mechanism covers any data that does leave, and what the DPA says about it, gets an answer that actually maps onto GDPR’s real requirement.
Data residency versus processor location
These are two different facts a provider can state, and marketing pages routinely blur them. Data residency is where your database’s disk physically sits - which region, which data center. Processor location is which legal entity operates that infrastructure and which country’s courts have jurisdiction over it. A US-headquartered cloud provider’s Frankfurt region stores data physically in Germany, but the parent company is still a US legal entity, which is precisely the fact pattern the CLOUD Act was written to reach.
The practical framing that shows up consistently across compliance writeups is: GDPR protection travels with the data, not with the disk. A US company’s EU region is a genuine risk-reduction step, but it is not the same guarantee as a provider that is itself an EU legal entity with no CLOUD Act exposure.
The CLOUD Act, briefly and accurately
The US CLOUD Act lets US law enforcement compel a US-based provider to hand over data the provider controls, regardless of where that data is physically stored - a Frankfurt data center does not put the data outside the Act’s reach if the company operating it is American. This is a distinct risk from GDPR’s transfer rules and one that a data residency claim alone does not resolve; it is a question about the operating company’s jurisdiction, not the server’s postal code.
None of this means a US-headquartered provider is unusable for EU data - most large EU organizations run on exactly that setup with SCCs and additional safeguards in place. It means the residency claim and the jurisdiction question need to be evaluated separately, and a hosting provider that only advertises the first is only answering half the question.
For a small team without a dedicated legal function, the practical shortcut is to treat CLOUD Act exposure as one more line in the same vendor questionnaire as the DPA and subprocessor list, rather than a separate research project. A provider that can answer it plainly, in writing, is telling you something about how seriously the rest of its compliance posture was built.
Data processing agreements and subprocessors
A DPA is the contract that makes a hosting provider your GDPR processor rather than an undocumented third party sitting between you and a fine. It needs to specify what data is processed, for what purpose, the security measures in place, breach notification timelines, and critically, a list of subprocessors - every other company the provider relies on that also touches the data, from the datacenter operator to the email service that sends password resets.
Subprocessors are where residency claims quietly fail in practice. A provider whose primary database is EU-resident can still route backups through a subprocessor’s US region, send error logs to a monitoring service headquartered elsewhere, or use a CDN that terminates connections outside the EU. Ask for the subprocessor list, not just the primary region, and re-check it periodically - providers add subprocessors over time.
Backups and logs: the part EU hosting claims usually skip
A checklist that stops at ‘where is the primary database’ misses where the derivative copies of that data end up. Backups, if replicated cross-region for durability, can put a copy of EU personal data on a server outside the EU even when the primary is correctly located. Application logs, error tracking, and analytics pipelines routinely capture personal data - an email address in a request log, a name in an error stack trace - without anyone treating them as the sensitive data they are.
The honest checklist question is not ‘is the database in the EU’, it is ‘is every place this data gets copied to, on purpose or by accident, in the EU or covered by a proper transfer mechanism’. That includes database backups, runtime logs, and any third-party analytics or error-tracking service wired into the app.
A practical checklist before calling a setup EU-compliant
- Confirm the primary data region, and get it in writing, not just inferred from a region picker in a dashboard.
- Confirm the operating entity’s jurisdiction - an EU-resident data center run by a US-headquartered company is a different risk profile than one run by an EU-domiciled company.
- Get the DPA and read the subprocessor list, not just the marketing page.
- Check where backups replicate to, and whether that is configurable.
- Check what personal data ends up in logs and whether log retention and access are covered by the same agreement as the primary data.
- Confirm breach notification timelines are specified, not just implied.
None of this is exotic - it is the same due diligence GDPR expects for any processor, applied specifically to the hosting layer instead of treated as solved by a region dropdown. Running through it once at procurement time is far cheaper than discovering a gap during an audit or, worse, after a breach notification is already due.
How this fits the rest of the stack
Most of this checklist is about asking a provider the right questions rather than about a specific technical feature, and that holds regardless of which platform ends up running the workload. What a hosting decision can concretely offer is a stated region for the primary database and the service, private networking between them so the two are not exposed to the open internet, and backups you control rather than ones replicated somewhere undocumented - the RunxBuild hosting calculator prices services and managed databases together so the region and plan for both are decided in the same place, not assumed.
Useful related references:
- Cloudflare and the EU: GDPR, Data Localization, and Whether Your Traffic Actually Stays in Europe
- DigitalOcean Data Centers: The Regions, How to Pick One, and Why the Choice Is Hard to Undo
- Database Backup: Strategies That Survive a Real Disaster (Not Just a Test)
- Database network security on RunxBuild
FAQ
Does GDPR require hosting servers to be located in the EU?
No. GDPR requires a lawful basis for transferring personal data outside the EEA - an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules - not that the data physically stay in the EU. Keeping data in the EU is a simplifying choice that avoids the transfer-mechanism question, not a legal requirement by itself.
What is the difference between data residency and GDPR compliance?
Data residency describes where data is physically stored. GDPR compliance depends on the full set of practices around that data - lawful basis, consent, retention, security, breach notification and transfer mechanisms - so a provider can state a residency fact truthfully while still leaving compliance questions unanswered.
Does the US CLOUD Act override EU data protection?
The CLOUD Act lets US authorities compel a US-based company to produce data it controls regardless of where that data is physically stored, including in an EU data center. It is a separate legal exposure from GDPR’s transfer rules and depends on the operating company’s jurisdiction, not the server’s location.
What should a GDPR data processing agreement include?
What data is processed and why, the security measures in place, breach notification timelines, and a list of subprocessors - every other company that also touches the data, such as backup providers, monitoring services or CDNs. The subprocessor list is where residency claims most often quietly fail.
Can backups break EU data residency even if the main database is EU-based?
Yes. Backups replicated cross-region for durability, or third-party logging and analytics tools wired into the app, can move a copy of personal data outside the EU even when the primary database is correctly located there. A full checklist covers backups and logs, not just the primary data store.