The US CLOUD Act and your files

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 evolving. 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 litigated for years: whether a US provider could be compelled to produce data stored abroad.

The answer it gave is yes. US providers must produce data in their possession, custody or control, regardless of where it is stored. It also created a framework for executive agreements allowing certain foreign governments to request data directly from US providers.

The important word 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 resolve it

This is the part that surprises people, and it is why so many procurement conversations go in circles.

Choosing an EU region for a US-owned cloud service changes where the bytes rest. It does not change:

• Where the company is incorporated
• Which courts have jurisdiction over that company
• Whether the company can technically access the data

If all three of those still point at the US, the data centre location has not answered the question. It has answered a data residency question, which is real and often required — but it is a different requirement from jurisdictional control.

Both can be requirements. They are frequently confused for one requirement, and the confusion runs in both directions: people over-engineer for residency when they needed jurisdiction, and people accept an EU region when their actual requirement was jurisdictional.

Where this actually bites

For most work it does not. If you are sending a video to a friend or a design to a client with no compliance function, this is genuinely not your problem and you should not let it become one.

It matters when:

• A contract specifies it. Plenty of client DPAs in regulated sectors prohibit sub-processors under particular jurisdictions. If you signed one, it binds you regardless of your own view.
• You handle special-category data — health, biometrics, anything about someone's private life. The obligations there are sharper.
• Public-sector work, where requirements are often written as hard rules.
• Legal or professional privilege is involved, where the possibility of third-party access is the thing being protected against.
• Your client's own regulator has views, which flow down to you.

The questions that actually settle it

Do not evaluate this from marketing pages. Ask a vendor, in writing:

1. Where is the company incorporated? Not where the servers are.
2. Who is the ultimate parent company, and where is it incorporated? A European subsidiary of a US parent is a US-controlled company for these purposes.
3. Who are your sub-processors, and where are they incorporated? A European company running entirely on US-owned cloud infrastructure has moved the question rather than answered it.
4. Which countries' legal processes can compel you to produce customer data?
5. Do you publish a transparency report of government requests?
6. Where are backups held?

Question three is the one that catches most European resellers. It is not automatically disqualifying — plenty of compliant architectures look exactly like that, particularly where the customer holds the keys — but you need to know, because it changes the analysis entirely.

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 the key holder.

If the customer holds the keys and the provider genuinely cannot decrypt, then what can be compelled is ciphertext. That is a meaningfully different position — and it is also why claims of end-to-end encryption deserve testing rather than acceptance. The fast test: if the provider can show you a thumbnail of your file, or recover your data when you forget your password, it holds the key. The longer version.

This is a real strategy, not a loophole. But it comes with the costs of the property: no server-side previews, no scanning, and no recovery.

The pragmatic position

Most organisations end up somewhere sensible:

Ordinary business data: use whatever works well. This is not a real risk for most of it, and pretending otherwise wastes attention that belongs elsewhere.

Personal data of clients and their customers: know your answer to the six questions above, 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 applied before you compare features. Otherwise 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 the test to apply is incorporation, not hosting.

For completeness: I run Yungle, an EU-incorporated company with files in Germany and backups in the EU — which is a direct answer to this particular concern, and exactly the kind of claim you should verify with the six questions above rather than take from a blog.