The US CLOUD Act explained for European founders

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act is a 2018 American law that requires US-based technology providers to hand over customer data when served with a valid US warrant or subpoena, regardless of whether that data is stored in the United States, Frankfurt, or Dublin. Because the law applies to any company under US jurisdiction and any subsidiaries it controls, choosing an EU data region on AWS, Google Cloud, or Microsoft Azure does not exempt your infrastructure from its reach. For European founders, this creates a direct legal conflict with Article 48 of the EU’s General Data Protection Regulation (GDPR), which forbids transferring data to non-EU authorities outside of recognized international treaties.

Key takeaways

Jurisdiction beats geography: The US CLOUD Act applies to the parent company’s legal headquarters and control structure, not the physical location of the server holding your data.
EU regions do not block US warrants: Contracting with a European subsidiary of a US hyperscaler—or using an EU-based sovereign cloud owned by a US parent company—still leaves the parent corporation subject to US legal compulsion.
GDPR Article 48 creates a conflict of laws: Complying with a US CLOUD Act order without an international mutual legal assistance treaty (MLAT) can violate the GDPR, putting cloud providers and their European customers in a grey zone.
The EU-US Data Privacy Framework does not solve this: The 2023 adequacy decision covers commercial data transfers from the EU to the US, not direct law enforcement warrants served on data stored inside the EU.
True immunity requires non-US ownership or external encryption: You can only remove CLOUD Act exposure by keeping your own encryption keys outside the provider’s infrastructure, or by hosting on cloud providers wholly owned and headquartered in the EU without a US nexus.

What the US CLOUD Act actually says

To understand the CLOUD Act, it helps to look at the court case that caused the US Congress to pass it.

In 2013, US federal investigators issued a warrant to Microsoft for emails belonging to a suspect in a narcotics case. The emails were stored on a Microsoft server in Dublin, Ireland. Microsoft challenged the warrant, arguing that US search warrants did not apply outside the territorial boundaries of the United States. The case went all the way to the US Supreme Court (United States v. Microsoft Corp.).

Before the Supreme Court could issue a ruling, the US Congress passed the CLOUD Act in March 2018 as an amendment to the Stored Communications Act (specifically codified at 18 U.S.C. § 2713). That rendered the court case moot.

The key text of the law states that a service provider must preserve, backup, or disclose the contents of electronic communications and customer records in its “possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.”

Who is covered?

The law applies to any provider of an “electronic communication service” or “remote computing service” that is subject to US jurisdiction. In plain English, that means any cloud infrastructure provider, SaaS company, email host, or content delivery network that is:

Incorporated or headquartered in the United States.
Controlled by a US parent company (such as an Irish or German subsidiary of Amazon, Google, or Microsoft).
Operating with a substantial legal and corporate presence inside the US, potentially subjecting foreign companies with US subsidiaries or operations to US court orders if the US entity has access to or control over the data.

How is the data requested?

There is a common misconception in Europe that the CLOUD Act gives US intelligence agencies free, unfiltered access to read European databases at will. That is not how this specific law works (intelligence gathering is governed by other laws, such as FISA Section 702).

The CLOUD Act is a law enforcement tool used in criminal investigations. To obtain content data (such as database rows, stored files, or emails), US federal or state prosecutors must go to a US judge and obtain a warrant based on “probable cause” that a crime has been committed. For metadata (such as billing records, IP addresses, or account creation dates), investigators can use a subpoena or court order with a lower legal threshold.

Furthermore, the order is often accompanied by a non-disclosure order (a gag order). When a cloud provider receives a warrant accompanied by a gag order, they are legally forbidden from telling you, the customer, that your data is being accessed or copied.

Why “hosted in Frankfurt” does not exempt your data

When European startups pitch enterprise clients or healthcare providers, the standard reassurance is: “All our data is hosted in AWS eu-central-1 in Frankfurt.”

From a latency and physical security standpoint, hosting in Frankfurt is great. Your data remains physically inside Germany during normal commercial operations. However, from a legal standpoint, physical residency is not the same thing as legal sovereignty.

Under the CLOUD Act, the determining test is possession, custody, or control.

Even if your service agreement is signed with Amazon Web Services EMEA SARL (located in Luxembourg), Microsoft Ireland Operations Limited, or Google Cloud EMEA Limited, those entities are wholly owned subsidiaries of US corporations. Under US corporate and procedural law, a parent company is deemed to have “control” over the data held by its foreign subsidiaries if it has the legal power to direct the subsidiary or the technical ability to access the systems.

What about “European Sovereign Clouds” from US providers?

In response to European regulatory pressure, US hyperscalers have launched specialized sovereign cloud offerings. For example, the AWS European Sovereign Cloud keeps all data, metadata, and day-to-day operations inside the European Union, run exclusively by EU-resident staff.

While this setup solves operational residency requirements and isolates the network from standard global control planes, the sovereign cloud entity still belongs to Amazon, a US company. If a US federal court serves a CLOUD Act warrant on Amazon’s parent corporation in Seattle and orders it to compel its European subsidiary to produce data, the ultimate corporate parent remains under US jurisdiction. Unless the architecture makes it mathematically and operationally impossible for the parent company to compel access, the legal conflict remains.

For a European company, the problem with the CLOUD Act is not necessarily that the US Department of Justice is interested in your B2B SaaS application. The problem is that using a provider subject to the CLOUD Act puts you in potential conflict with European data protection law.

The tension centers on two specific parts of the GDPR:

1. Article 48 (Transfers not authorized by Union law)

Article 48 of the GDPR was written specifically to block foreign extraterritorial laws. It states that any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognized or enforceable if it is based on an international agreement, such as a mutual legal assistance treaty (MLAT), in force between the requesting third country and the EU or a Member State.

The US CLOUD Act allows the US government to bypass the slow MLAT process and serve warrants directly on US cloud providers. Therefore, if a US provider complies with a CLOUD Act warrant and hands over EU personal data without going through an MLAT or an equivalent EU-US CLOUD Act executive agreement (which the EU as a bloc has not signed), that disclosure lacks a recognized legal basis under Article 48.

2. Chapter V and the Schrems II principles

Under Chapter V of the GDPR (Articles 44–49), transferring personal data outside the European Economic Area requires strict safeguards. Even when data is stored in Europe, European data protection authorities (and the European Data Protection Board) consider the remote access to data from a third country—or the legal exposure to third-country disclosure orders—as a critical factor when evaluating processor compliance under Article 28.

Why the EU-US Data Privacy Framework (DPF) doesn’t fix it

In July 2023, the European Commission adopted the adequacy decision for the EU-US Data Privacy Framework (DPF). Many founders assumed this ended all transatlantic cloud compliance debates.

The DPF makes it legal to transfer commercial data to certified companies in the United States, and it introduced new redress mechanisms (like the Data Protection Review Court) for US signals intelligence activities. However, the DPF regulates data transferred to the US. It does not invalidate the CLOUD Act’s reach over servers located inside the EU, nor does it amend Article 48 of the GDPR regarding direct foreign court orders served on European data stores.

How different cloud setups compare

To evaluate how your infrastructure choices affect your exposure to non-EU jurisdiction, consider how ownership, location, and encryption interact:

Cloud setup	Physical data location	Parent company jurisdiction	Exposed to US CLOUD Act?	GDPR Article 48 conflict risk
US cloud, US region (e.g., AWS `us-east-1`)	United States	United States	Yes	High (governed by DPF if certified, but direct US law applies)
US cloud, EU region (e.g., AWS Frankfurt, GCP Belgium, Azure Dublin)	European Union	United States	Yes (via parent control)	Moderate to High (depends on data sensitivity and threat model)
US Sovereign Cloud in EU (e.g., AWS European Sovereign Cloud)	European Union	United States	Yes (ultimate corporate ownership is US)	Low to Moderate (operational separation, but legal parent is US)
US cloud + External Hold Your Own Key (HYOK)	European Union	United States	Metadata: Yes Plaintext data: No	Low (provider cannot read encrypted data at rest)
EU-owned cloud, EU region (e.g., UpCloud, Hetzner, Scaleway, OVHcloud, STACKIT)	European Union	European Union (Finland, Germany, France)	No (assuming no substantial US corporate nexus)	None

How likely is a CLOUD Act request in practice?

Honesty matters when assessing legal risk. If you run a 30-person European startup building project management software, the probability that the FBI will serve a warrant on AWS for your database is extremely low.

All three major US hyperscalers publish semi-annual transparency reports detailing law enforcement requests:

Volume: While US cloud providers receive tens of thousands of legal requests from US authorities each year, the vast majority target consumer accounts (such as Gmail, Outlook, or iCloud) rather than enterprise cloud infrastructure.
Enterprise protections: AWS, Microsoft, and Google publicly commit to redirecting government agencies to request data directly from the enterprise customer whenever possible. They also promise to challenge warrants that conflict with foreign laws like the GDPR—a right explicitly granted under the “comity analysis” provisions of the CLOUD Act (though only fully automated for countries that have signed an Executive Agreement with the US, like the UK and Australia).
Actual disclosures: For non-US enterprise cloud customers, the number of times US providers actually hand over content data to US authorities each year is in the single or low double digits globally.

So why do European founders care?

For most European B2B startups, the CLOUD Act is not an operational risk that the FBI will raid your database. It is a commercial and procurement risk.

If you sell software to:

European public sector bodies (municipalities, ministries, state agencies),
Healthcare providers and hospitals handling patient data,
Financial institutions regulated under DORA (Regulation (EU) 2022/2554), or
Legal, defense, or critical infrastructure enterprises,

their data protection officers (DPOs) and procurement teams often take a strict, literal view of GDPR compliance and digital sovereignty. To them, any theoretical legal pathway for a non-EU government to compel access to their data—no matter how statistically small—is a blocker during vendor security assessments. If a competitor can check the box saying “100% EU-owned infrastructure, zero CLOUD Act exposure,” they win the deal without a six-month legal review.

Practical options to reduce or eliminate exposure

If your customers, investors, or regulators require you to address US CLOUD Act exposure, you have three realistic paths depending on your engineering capacity and compliance targets.

1. Contractual and administrative measures (Low effort, partial protection)

If you stay on a US hyperscaler, make sure you have the baseline legal documentation in place:

Sign the provider’s GDPR Data Processing Addendum (DPA) and ensure their Standard Contractual Clauses (SCCs) or DPF certifications are active.
Document a Transfer Impact Assessment (TIA) showing that the data you store is low-risk commercial data unlikely to attract US national security or criminal warrants.
Enable provider features that restrict support staff access to EU personnel only.

Limitation: Paperwork does not override a US federal judge’s warrant. Strict public-sector DPOs often reject this approach for sensitive data.

2. Technical encryption with external keys (High effort, strong protection for data at rest)

If a cloud provider only holds ciphertext and cannot access the decryption keys, handing that ciphertext over to a US prosecutor reveals nothing useful.

However, standard cloud encryption is not enough. Using AWS KMS, Google Cloud KMS, or Azure Key Vault in their default configurations means the cloud provider holds the keys in their infrastructure and could theoretically be compelled to use them.

To defeat legal compulsion via encryption, you need Hold Your Own Key (HYOK) or External Key Management (such as AWS KMS External Key Store). In this setup, your encryption keys live on a hardware security module (HSM) hosted inside your own premises or with an independent European provider.

Limitation: You can only do this for data at rest (like S3 buckets or backups). If your application runs on an EC2 virtual machine or an RDS database, the data must be decrypted in memory (RAM) for the CPU to process it. Unless you re-architect your entire stack around confidential computing enclaves, a cloud provider with control over the hypervisor still has technical access to running workloads.

3. Moving to an EU-owned cloud provider (Moderate effort, complete legal clarity)

The cleanest way to remove US extraterritorial jurisdiction is to run your workloads on a cloud provider that is headquartered in Europe, owned by European entities, and operates exclusively under EU and Member State law.

Providers such as UpCloud (Finland), Scaleway and OVHcloud (France), and Hetzner, STACKIT, and IONOS (Germany) offer core infrastructure—virtual machines, managed PostgreSQL/MySQL databases, managed Kubernetes, and S3-compatible object storage—without a US corporate parent.

Thanks to the EU Data Act (Regulation (EU) 2023/2854), switching providers has also become financially easier. Under Article 29 of the Data Act, cloud providers can charge no more than their direct cost for data egress when a customer is switching providers, and from 12 January 2027, all switching and egress fees for moving to another provider are banned across the EU.

When selecting an EU provider for strict compliance deals, verify one detail: check whether the European provider has a US corporate subsidiary (for example, to operate US data centers). Some strict legal interpretations argue that a US subsidiary could give a US court a lever over a European parent company. Providers like STACKIT, Exoscale, or UpCloud (depending on corporate structure and entity segregation) can provide specific legal assurances on how they isolate or avoid US jurisdiction.

Frequently asked questions

Does the US CLOUD Act apply to open-source software like PostgreSQL or Kubernetes?

No. The CLOUD Act applies to service providers (companies that host data or run infrastructure for you), not to software code. Running open-source PostgreSQL or Kubernetes on an EU-owned cloud provider carries zero CLOUD Act exposure, even if US companies contributed to the open-source code.

If I use Cloudflare in front of an EU-owned server, does the CLOUD Act apply?

Yes, to the traffic passing through Cloudflare. Cloudflare is a US-headquartered company. Because it terminates TLS connections to inspect and cache traffic, it has technical custody of the data in transit and any cached content or logs stored on its edge network. If you require strict immunity from US jurisdiction, your DNS, CDN, and DDoS protection must also be provided by European companies (or pass through encrypted without TLS termination).

A provider can challenge a warrant in a US court by arguing that compliance would force them to violate foreign law (like the GDPR). The US court will then conduct a “comity analysis,” weighing the US government’s need for the evidence against the foreign country’s legal interests. However, the US judge makes the final decision. If the judge upholds the warrant, the US provider must comply or face contempt of court sanctions in the United States.

Does the UK have a similar agreement with the US?

Yes. The United Kingdom and the United States signed a bilateral Data Access Agreement under the CLOUD Act, which entered into force in October 2022. This allows UK and US law enforcement agencies to serve warrants directly on telecom and cloud providers in each other’s countries for serious crimes, bypassing traditional diplomatic channels. The European Union as a whole does not have an active agreement of this kind with the US.

How MoveInfra can help

If US CLOUD Act exposure is slowing down your enterprise sales or creating compliance headaches with European public-sector and regulated clients, MoveInfra moves your infrastructure from AWS, Google Cloud, Azure, or DigitalOcean to EU-owned clouds like UpCloud, Scaleway, Hetzner, or OVHcloud. We rebuild your environment as clean Terraform code, sync your databases and object storage with live replication, and switch your DNS during a short planned write pause—keeping a 30-day reverse replication rollback window so your team can migrate for a fixed price without rewriting your applications. You can start by uploading your current cloud bill at moveinfra.eu for a free inventory and cost comparison without granting any system access.