Jurisdiction follows the company, not the server. A US-incorporated provider storing your files in Frankfurt can still be required under US law to produce data it controls, because the obligation attaches to the company rather than to the hardware. That single fact is why "we have an EU data centre" answers a different question from the one most compliance requirements are actually asking.
Not legal advice, and deliberately general — the details are contested and still moving. What follows is the shape of the problem, which is enough to ask the right questions.
What the CLOUD Act does
The Clarifying Lawful Overseas Use of Data Act, passed in the US in 2018, settled a question that had been in court for years: can a US provider be compelled to produce data it stores abroad?
The answer it gave is yes. US providers must produce data in their possession, custody or control, regardless of where it is stored. The Act also created a framework for executive agreements that let certain foreign governments request data from US providers directly.
The word doing the work is control. Not location. If a US company can reach the data, US legal process can reach the company.
Why an EU data centre does not settle it
Choosing an EU region on a US-owned cloud changes where the bytes rest. It does not change:
- where the company is incorporated
- which courts have jurisdiction over it
- whether the company can technically access the data
If all three still point at the US, the data centre has answered a data residency question — which is real, and often required — but not the jurisdictional control question. People confuse the two in both directions: over-engineering for residency when they needed jurisdiction, and accepting an EU region when jurisdiction was the actual requirement.
When it matters, and when it does not
For most work it does not. Sending a video to a friend, or a design to a client with no compliance function, is not your problem to solve here, and you should not let it become one.
It matters when:
- A contract says so. Plenty of client DPAs in regulated sectors rule out sub-processors under particular jurisdictions. If you signed one, it binds you.
- You handle special-category data — health, biometrics, anything about someone's private life. The obligations are sharper.
- It is public-sector work, where requirements are often written as hard rules.
- Privilege is involved — legal or professional — where third-party access is the very thing being protected against.
- Your client's regulator has views, which flow down to you.
Six questions that actually settle it
Do not evaluate this from marketing pages. Ask a vendor, in writing:
- Where is the company established? Not where the servers are.
- Who is the ultimate parent, and where is it established? A European subsidiary of a US parent is a US-controlled company for these purposes.
- Who are your sub-processors, and where are they established? A European company running on US-owned infrastructure has moved the question, not answered it.
- Which countries' legal processes can compel you to produce customer data?
- Do you publish a transparency report of government requests?
- Where are backups held, and by whom?
Question three catches most European resellers. It is not automatically disqualifying — plenty of sound architectures look exactly like that, especially where the customer holds the keys — but it changes the analysis, so you need to know.
What encryption does, and does not, fix
If the provider holds the keys, it can produce readable data when compelled. Encryption at rest protects against a stolen disk, not against lawful process served on whoever holds the key.
If only the customer holds the key and the provider genuinely cannot decrypt, then what can be compelled is ciphertext. That is a meaningfully different position:
It is a real strategy, not a loophole, and it costs exactly what you would expect: no server-side previews, no virus scanning, no recovery if you lose the key. It is also why claims of end-to-end encryption deserve testing. The fast test: if the provider can show you a thumbnail of your file, or restore your data when you forget your password, it holds the key. The longer version.
The pragmatic position
Most organisations land somewhere sensible:
- Ordinary business data: use whatever works well. For most of it this is not a real risk, and pretending otherwise spends attention that belongs elsewhere.
- Personal data of clients and their customers: know your answers to the six questions, get the DPAs in place, and be able to state it when asked. The full framework.
- Special-category, privileged or public-sector data: treat jurisdiction as a filter you apply before comparing features, or you will pick a tool you then cannot use.
If jurisdiction is a filter for you, the European services page is the right starting point, and leaving US big tech describes the move itself. Test establishment, not hosting.
For completeness, and answering my own six questions: Yungle, which I run, is a Dutch business, and files live on a server in Germany at Hetzner. Nightly backups go to a second Hetzner data centre in Finland, so on question six the answer is that no US company holds the files or their backups. Sub-processors are listed in the privacy policy. For files where that matters, the vault and end-to-end encrypted transfers keep the key out of our hands entirely; the security page explains both. Verify all of it with the questions above rather than taking it from a blog — including this one.