What the US CLOUD Act actually means for European businesses

Almost every European business now runs on US-headquartered cloud services. Mail goes through Google Workspace or Microsoft 365. Files live on Google Drive, OneDrive, or Dropbox. Customer data passes through Stripe, HubSpot, or Salesforce. The default assumption — when anyone bothers to think about it — is that storing the data in an "EU region" means it stays under EU law.

That assumption is wrong, and the law that makes it wrong is the US CLOUD Act. It's worth understanding precisely, because the consequences are concrete: a procurement team that signs off on "the data is in eu-central-1" without understanding the corporate-domicile question has signed off on something they probably didn't mean to.

How the CLOUD Act actually works

The Clarifying Lawful Overseas Use of Data Act was passed by the US Congress in 2018. It does two things relevant here. First, it lets US federal authorities compel a US-incorporated company to produce data in its "possession, custody, or control", regardless of where in the world that data is physically stored. Second, it lets the US Department of Justice enter bilateral agreements with foreign governments to streamline mutual access.

The phrase that matters is possession, custody, or control. It's not a location test. It's a corporate-relationship test. If the entity that holds your data is a US corporation, or a subsidiary of one, or under the "control" of one as a matter of US legal interpretation, the CLOUD Act applies. The data could be on a hard drive in Frankfurt, Stockholm, or Reykjavik. The location is not the question. The corporate structure is.

This is not a theoretical reading. US courts have already enforced CLOUD Act production orders against US tech companies for data stored on EU soil. The case law is settled. The mechanism works.

"But my data is in `eu-central-1`" doesn't help

The most common mistake in procurement reviews is treating cloud-provider "EU regions" as a sufficient safeguard. They aren't — not because the providers are dishonest about where the data physically sits (they aren't), but because the legal test is corporate, not geographic.

AWS Frankfurt (eu-central-1) is operated by Amazon Web Services EMEA SARL, a Luxembourg entity that is a subsidiary of Amazon.com, Inc. — a US corporation. The parent retains the corporate control the CLOUD Act looks for.
Google Cloud Belgium (europe-west1) is operated by Google Cloud EMEA Limited, an Irish entity that is a subsidiary of Alphabet Inc. — also US. Same structure.
Azure Sweden Central is operated by Microsoft Ireland Operations Limited, a subsidiary of Microsoft Corporation — also US. Same structure again.

Each of these EU regions is a real data centre in a real EU country. The packets really do route there. The disks really are inside the Schengen zone. None of that protects the data from being produced under a US CLOUD Act order served on the parent company in Seattle, Mountain View, or Redmond.

Google's and Microsoft's own transparency reports acknowledge this directly. Both companies disclose receiving and responding to US government data requests for customer data, including customer data stored in EU regions. The numbers are published. The mechanism is not in dispute.

What CLOUD Act exposure looks like in practice

The honest answer is: most of the time, nothing. The vast majority of European businesses are not the target of US federal investigations. The CLOUD Act risk for a Berlin design studio running Google Workspace is, in practice, vanishingly small. This is why the issue is so often dismissed as theoretical.

It is also why it tends to be taken seriously only in three contexts, and dismissed everywhere else:

Regulated industries.Financial services, health, legal — anywhere a national regulator has a position on third-country data access. Increasingly the answer from EU regulators is "avoid CLOUD Act-exposed providers for regulated workloads."
Public sector procurement.National and EU-level tenders increasingly require "sovereign cloud" or "no third-country data access risk" clauses. The CLOUD Act is the third-country risk.
Cross-border legal exposure. Companies operating in jurisdictions where the EU-US Data Privacy Framework is being tested, or where Schrems-style invalidation case law is pending. Some legal opinions advise hedging through provider choice now, rather than during the next ruling.

Outside those three contexts, the typical conversation is: "is this likely to affect us? Probably not. Should we still pick a non-exposed provider when one is available? If the price and product are comparable, yes." That "yes" is the procurement wedge that's reshaping EU SaaS.

What actually puts you outside CLOUD Act reach

Three conditions, all of which must hold:

The data controller has no US corporate presence. No US parent, no US subsidiary, no US-incorporated entity that holds the data. A Swedish, German, or French company with operations only in the EU.
The infrastructure is not operated by a US-parented company. Not AWS-Frankfurt, not Google-Belgium, not Azure-Sweden. The provider running the workload must be EU-owned end-to-end. Examples: Hetzner (DE), OVH (FR), Scaleway (FR), IONOS (DE), Open Telekom Cloud (DE), UpCloud (FI), a sovereign cloud partnership.
Sub-processors in the data path are also non-US. This is the part most "EU-hosted" competitors fail. The mail server can be in an EU cloud in Frankfurt and still pipe transactional email through Sendgrid (US), payments through Stripe-US, customer support tickets through Intercom (US), edge caching through Cloudflare (US). Each one is a CLOUD Act re-entry. Authentic sovereignty requires the whole chain.

These conditions are concrete and testable. Ask a vendor: who owns the company? Where is each subprocessor incorporated? Is the subprocessor list published? Will you be notified when it changes? The answers should not require legal interpretation. They should be a list.

A procurement checklist

Five questions to ask any SaaS vendor when CLOUD Act exposure is on the table. None of these are difficult; the difficulty is that vendors often haven't prepared the answers.

Where is your company incorporated, and is there any US-incorporated entity in your corporate structure?If the answer involves "our US holding company" or "our Delaware parent", that's the answer.
Who operates the infrastructure where customer data lives?If the answer is AWS, GCP, or Azure — including their EU regions — that's the answer.
Can I have the current subprocessor list, and will changes be notified in advance?A vendor that can't produce this on demand has not done the work.
Are encryption keys managed by you on EU-owned infrastructure, or by a US-owned KMS service? AWS KMS, GCP KMS, and Azure Key Vault are US-owned. EU-sovereign KMS options exist.
What happens when a US legal order reaches you? The honest answer for a US-incorporated vendor is "we comply with valid orders." The honest answer for a clean EU structure is "US orders are processed through Swedish/EU legal channels, not direct compulsion."

How Verkio addresses this

Verkio is a European company with no US presence in the corporate structure or the data path. Infrastructure runs on EU-owned providers; encryption keys live in an EU-located KMS we operate; the subprocessor list is published with changes announced ahead of time. The full posture is summarised on the residency section of the homepage — including the explicit "no US subprocessors in the data path" commitment, which is the part most "EU-hosted" competitors don't make.

This isn't marketing positioning bolted onto a generic SaaS; it's a structural choice that constrains every vendor decision we make. The point of writing it down is to make the constraint visible, so procurement reviewers don't have to reverse-engineer it from a privacy policy.