The US CLOUD Act Explained: Why European Businesses Need Non-US Cloud Alternatives (2026)

If you run a European business and your data lives on AWS, Microsoft Azure, Google Cloud, Oracle Cloud, IBM Cloud, Salesforce, or Cloudflare, there is a US law you need to understand: the CLOUD Act.

It does not matter that your account is on AWS eu-central-1 in Frankfurt. It does not matter that you picked "Azure Germany" or a Microsoft "EU Data Boundary" subscription. It does not matter that your Google Cloud project is pinned to europe-west3. Under the CLOUD Act, US authorities can compel any US-based service provider to hand over data it has "possession, custody, or control" of — anywhere in the world.

This is not a theoretical concern. In June 2025, Microsoft's own French subsidiary confirmed under oath at a French Senate hearing that it cannot guarantee data sovereignty against US authorities, even for data stored in France under a French-marketed "sovereign" offering. That moment ended the debate about whether the CLOUD Act actually reaches into Europe: it does, and the hyperscalers now admit it on the record.

This post is a 2026 guide to the CLOUD Act for European decision makers: what it says, who it binds, how it interacts with GDPR, why the big "sovereign cloud" rebranding from Amazon, Microsoft, and Google does not fix the problem, and — if you actually need your data beyond US reach — what truly EU-sovereign alternatives look like, including DanubeData.

This is the CLOUD-Act-focused sibling to our broader Schrems II digital sovereignty post. Where that one covers the full legal and regulatory picture, this one zooms in on the single US statute that matters most when you are picking a cloud provider in 2026.

What Is the CLOUD Act?

The Clarifying Lawful Overseas Use of Data Act — the "CLOUD Act" — was signed into US law in March 2018 as part of an omnibus spending bill. It amended the Stored Communications Act (18 U.S.C. § 2701 et seq.) to accomplish two things:

1. Extraterritorial reach: US law enforcement can compel any provider of "electronic communications services" or "remote computing services" under US jurisdiction to produce data in its "possession, custody, or control" — regardless of where that data is physically stored.
2. Executive agreements: The US can sign bilateral "executive agreements" with other countries (UK first, Australia second) to speed up cross-border data requests between their law enforcement agencies and US-domiciled providers.

Why did the US pass it? Because the Supreme Court was about to rule on United States v. Microsoft Corp. — the famous "Microsoft Ireland" case, where the US DOJ wanted emails stored on a Microsoft server in Dublin and Microsoft refused, arguing that a US warrant could not reach data stored overseas. The CLOUD Act made that case moot: Congress simply legislated the result the DOJ wanted.

The CLOUD Act's text is short and brutal. Here is the operative language, paraphrased for readability:

A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.

Five words do the work: regardless of whether located outside. That is the hinge on which hundreds of billions of euros of European cloud spend now awkwardly hang.

Who Does the CLOUD Act Apply To?

The CLOUD Act applies to any "electronic communications service" (ECS) or "remote computing service" (RCS) provider subject to US jurisdiction. In plain English: any company incorporated in the US, any US parent company, and any subsidiary of a US parent that the parent has "control" over.

That very much includes every US hyperscaler and most household-name SaaS vendors. A non-exhaustive list:

• Amazon Web Services (AWS) — including AWS Europe, AWS Germany, and the new "AWS European Sovereign Cloud" that launched 2025
• Microsoft Azure — including Azure Germany, "Microsoft EU Data Boundary", Microsoft 365, Azure Stack, GitHub
• Google Cloud Platform — including Google Workspace, Google Cloud "Sovereign Controls by S3NS" (France), "Sovereign Controls by T-Systems" (Germany)
• Oracle Cloud Infrastructure — including Oracle EU Sovereign Cloud
• IBM Cloud — including IBM Cloud for SAP, IBM Cloud Satellite
• Salesforce — including Hyperforce EU regions
• Cloudflare — CDN, Workers, R2, D1
• MongoDB Atlas, Snowflake, Databricks, Datadog, Atlassian, Slack, Zoom, Dropbox, Box, Okta, Auth0...

If the company's headquarters is in the US — or its ultimate parent is a US corporation, or a majority US-owned entity — the CLOUD Act applies. Full stop. Rebranding a regional offering as "sovereign" does not change corporate structure.

What Does "Possession, Custody, or Control" Mean?

This is the legal test. US courts have long interpreted "control" very broadly — it does not mean physical possession. It means the provider has the practical ability to obtain the data. A US parent company that can instruct its Irish or German subsidiary to produce data has "control" of that data, even if the data never leaves Europe physically.

This is exactly why Microsoft lost the Dublin argument before the CLOUD Act even passed: the DOJ's theory was that Microsoft could simply log in from Redmond and download the emails from the Irish server. After the CLOUD Act, that theory is now statute.

How CLOUD Act Requests Actually Work

A CLOUD Act request is not a routine background process. It typically starts with a US court order or warrant — usually issued under the Stored Communications Act, the Electronic Communications Privacy Act, FISA 702 (for foreign intelligence), or a grand jury subpoena. Key points for European businesses:

• No notification requirement. The provider can be — and routinely is — served with a gag order under 18 U.S.C. § 2705(b), legally prohibiting them from telling the customer that data was requested.
• No requirement to inform EU data subjects. Under GDPR Articles 13–14, data subjects have a right to know how their data is processed. Under the CLOUD Act, the US provider is legally barred from informing them. These obligations directly conflict.
• Challenging requests is expensive and usually futile. The CLOUD Act does allow a provider to move to quash an order if it would violate the law of a "qualifying foreign government." But only a handful of countries qualify (UK does, most of the EU does not), and the provider — not the customer — decides whether to fight.
• FISA 702 is worse. For national-security requests, there is no adversarial process, no customer notice, no practical way to challenge, and the standard is only that the target be "reasonably believed to be a non-US person located outside the US." That describes essentially every European business customer.

CLOUD Act vs GDPR: The Direct Conflict

Here is where European companies run into real compliance trouble. The GDPR has a very specific article — Article 48 — designed precisely to block this scenario:

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 recognised or enforceable in any manner if based on an international agreement...

Article 48 says a US court order alone is not a lawful basis to transfer personal data out of the EU. The GDPR demands a proper international instrument — a Mutual Legal Assistance Treaty (MLAT) or a framework like the EU-US Data Privacy Framework.

The CLOUD Act, meanwhile, says: produce the data, Article 48 be damned, or face US contempt sanctions.

So a US cloud provider subject to a CLOUD Act order has two options:

1. Comply with US law, violate GDPR Article 48, and expose the European customer to supervisory-authority fines of up to 4% of global turnover.
2. Defy US law, risk US contempt sanctions, lose their business license, and expose their executives to personal liability.

Spoiler: they comply with the CLOUD Act. Every time.

European supervisory authorities have been saying this clearly for years. The EDPB's Schrems II recommendations, the CNIL's 2021 guidance, the BfDI's repeated warnings, and the Dutch DPA's 2023 Microsoft 365 risk assessment all identify the CLOUD Act as a "problematic" third-country law that cannot be squared with GDPR through contractual measures alone.

The "Sovereign Cloud" Rebranding: Does It Fix the CLOUD Act?

Since Schrems II (2020) and the ongoing rise of European data sovereignty politics, every US hyperscaler has launched something they call a "sovereign" or "EU-boundary" offering. Let us go through them.

AWS European Sovereign Cloud (launching 2025–2026)

AWS announced in 2023 that it would build a separate European Sovereign Cloud, first region in Brandenburg, Germany. It promises data residency in the EU, EU-only operational staff, and a new legal entity based in the EU.

The catch: that legal entity is still a subsidiary of Amazon.com, Inc., a US corporation. Unless Amazon divests it to a non-US owner — which it has explicitly declined to do — the CLOUD Act "possession, custody, or control" test continues to reach it. AWS has not committed (and cannot credibly commit) to ignoring a CLOUD Act order directed at its US parent.

Microsoft EU Data Boundary (launched 2024)

Microsoft's "EU Data Boundary for the Microsoft Cloud" promises that customer data and personal data for Microsoft 365, Dynamics 365, Power Platform, and most Azure services is stored and processed in the EU. This is a genuine engineering improvement on data flow but — critically — does not change who owns Microsoft.

Microsoft Corporation is a Washington-state corporation headquartered in Redmond. Every Microsoft subsidiary in every EU country is, under corporate law and under the CLOUD Act, controlled by that US parent.

Which brings us to the moment that broke the spell.

The "Microsoft Spilled the Beans" Moment (June 2025)

On 10 June 2025, before the French Senate's Commission of Inquiry on digital sovereignty, Anton Carniaux — Director of Public and Legal Affairs at Microsoft France — was put under oath and asked, directly, whether Microsoft could guarantee that data stored by French public sector customers in Microsoft's French regions would never be transmitted to US authorities without the French government's explicit consent.

Carniaux's answer, on the record, was unambiguous: no, Microsoft cannot provide that guarantee. He explained that Microsoft must comply with US legal orders, that CLOUD Act requests do occur, that Microsoft challenges them where possible and publishes aggregate numbers, but that it cannot contractually or technically promise that European data will never be accessed under US legal process.

French senators and sovereignty-minded press reported this as a milestone admission: the biggest US cloud vendor, speaking under French parliamentary oath, conceded that its "EU Data Boundary" marketing does not — and cannot — neutralize the CLOUD Act. Germany's Bundestag has cited this transcript in subsequent debates on federal cloud procurement. The Netherlands' Court of Audit referenced it in its 2025 Microsoft 365 risk report.

If you are still running a Transfer Impact Assessment (TIA) that assumes Microsoft's EU Data Boundary neutralizes the CLOUD Act, that TIA is now demonstrably wrong.

Google "Sovereign Controls" (S3NS in France, T-Systems in Germany)

Google's answer is operationally stronger: it licenses its Anthos/GCP stack to French (S3NS, backed by Thales) and German (T-Systems) partners who run the infrastructure independently. The partner, not Google, holds the keys and the operational staff.

This genuinely helps — but it is not a complete fix. The software and update pipeline still originate from Google in Mountain View. Any back door, telemetry channel, or software supply-chain vulnerability in Google's code remains potentially subject to US legal orders against Google LLC. For data-at-rest and operational access, S3NS/T-Systems is meaningfully better than vanilla Google Cloud EU. For data-in-motion through Google-authored code, it is not provably beyond US reach.

Oracle EU Sovereign Cloud

Launched 2023 in Frankfurt and Madrid. EU-based legal entity, EU staff. Same fundamental issue as AWS: Oracle Corporation is US-domiciled; the subsidiary is "controlled" in the CLOUD Act sense.

The short answer

None of the US hyperscaler "sovereign" offerings close the CLOUD Act gap by themselves. They reduce some risk vectors (data residency, operational staff location, some telemetry) but they do not change the corporate ownership structure that the CLOUD Act keys on. As long as the ultimate parent is a US corporation, the US government has statutory reach.

Comparison: US Hyperscaler "Sovereign" Offerings vs Truly EU-Sovereign Providers

"Truly EU-sovereign" here means: the ultimate corporate parent is an EU (or EEA/Swiss) entity, no US shareholding majority, no US-held escrow or legal control, and all operational control sits with EU personnel under EU law.

What an EU Business Processing Personal Data Should Actually Do

Three practical moves, in order of effort:

1. Classify Your Data

Not all data is equal. Public marketing site content is different from HR files, which are different from client financial records, which are different from health data. Build a short classification policy:

• Tier A (sovereign-critical): health data (Art. 9 special categories), client financial and legal records, HR and payroll, security incident logs, law enforcement correspondence, anything covered by national critical-infrastructure law (NIS2, DORA), and anything about identifiable minors.
• Tier B (sensitive but less critical): internal business communications, internal documents, B2B CRM data, analytics about identifiable users.
• Tier C (low-risk / public): static website assets, public marketing content, non-personal aggregated analytics.

Tier A and most of Tier B should not live on a CLOUD-Act-exposed provider. Tier C can live wherever is cheapest and most convenient.

2. Run an Honest Transfer Impact Assessment (TIA)

Schrems II and the EDPB's Recommendations 01/2020 require any data exporter using a Standard Contractual Clause (SCC) to a non-EU provider to run a TIA. A real TIA for a US cloud in 2026 has to answer these questions:

• Is the provider subject to CLOUD Act, FISA 702, Executive Order 12333, or NSLs? (Yes, for all US hyperscalers.)
• What "supplementary measures" have been put in place? (Encryption with customer-held keys that the provider cannot access; strict data minimization; pseudonymization at the application layer.)
• Are those measures actually effective against the identified risk? (Encryption-at-rest managed by the provider is not effective — the provider can decrypt under court order. Encryption with keys held only by the customer, outside the provider's infrastructure, is partially effective, but not for data in active use.)
• Does the provider's own testimony support your conclusion? (Here the June 2025 Microsoft Senate transcript is a relevant evidentiary source. A TIA that concludes "no risk" now has to explain why it diverges from that sworn testimony.)

If your TIA cannot honestly reach a conclusion of "effective protection," you need either (a) real supplementary measures that actually work, or (b) a different provider.

3. Migrate Tier-A/B Workloads

For data where the CLOUD Act actually matters, move it. This is cheaper and less scary than most people think. Concrete migration paths:

For most small- and mid-sized European SaaS companies, moving Tier A/B workloads off US clouds costs less than keeping them there — DanubeData's Postgres starts at €19.99/mo versus AWS RDS's typical €80–150/mo for comparable specs, with 20TB of traffic included and €50 signup credit.

Decision Framework: Does the CLOUD Act Actually Matter For Your Org?

For some organizations, CLOUD Act exposure is a rounding-error risk. For others, it is existential. Use this quick triage:

CLOUD Act likely matters if...

• You process Article 9 special category data (health, biometric, trade-union, political, religious).
• You are in a regulated sector: banking (DORA), health (national health-data laws), defense/government, critical infrastructure (NIS2), lawyers/doctors/notaries (professional secrecy).
• You process data of identifiable EU children or minors.
• Your customers are EU public-sector entities — they are increasingly contractually forbidden from choosing CLOUD-Act-exposed providers.
• You have a German or French BfDI/CNIL-visible data footprint — both regulators have explicitly flagged US clouds.
• You want to win EU government RFPs (GAIA-X, SecNumCloud in France, C5 in Germany, BSI certification).
• Your competitors advertise "100% EU" as a differentiator — it is becoming table stakes in B2B.

CLOUD Act might be acceptable risk if...

• You process only pseudonymous or aggregate data with strong client-side encryption.
• Your data is public anyway (marketing site, documentation, open-source artifacts).
• You are a personal side project with no personal data of third parties.

Even in the "acceptable risk" category, the macro-trend is clear: EU customers, EU investors, and EU regulators are all moving toward "default EU-sovereign." Being on AWS in 2030 may be a sales objection the way "still using jQuery" is a hiring objection today.

DanubeData: An EU-Sovereign Option

A quick word on why DanubeData exists, since this is our blog: we built DanubeData specifically to be a no-US-reach managed cloud for European businesses who want the hyperscaler developer experience without the US-jurisdiction baggage.

• EU-only ownership. Romanian company (IFAS Consult S.R.L.), no US shareholders, no US board members, no US subsidiary structure. Zero CLOUD Act reach by construction.
• Bare-metal in Falkenstein, Germany. Hetzner dedicated servers, not hyperscaler reselling. We do not run on top of AWS, Azure, or GCP.
• GDPR-native. German data center, EU data controller, standard DPAs available, Art. 28 processing agreements on request.
• Prices that undercut AWS by 60–80% for comparable workloads: VPS from €4.49/mo, Managed Postgres/MySQL/MariaDB from €19.99/mo, Managed Redis/Valkey/Dragonfly from €4.99/mo, S3 storage from €3.99/mo, Knative serverless from €5/mo.
• 20 TB traffic per VPS included, €1.21/TB overage — no surprise bandwidth bills.
• €50 signup credit so you can actually evaluate it.

We are also transparent about what we are not: we are not a Fortune-500 hyperscaler, we do not have a region in every continent, and we do not offer 400 managed services. We offer the core primitives (compute, managed databases, managed caches, object storage, serverless) well, in Europe, under EU jurisdiction — which is exactly what most businesses actually use.

Frequently Asked Questions

Does the CLOUD Act apply to AWS's Frankfurt region (eu-central-1)?

Yes. The region is operated by Amazon Web Services EMEA SARL, a Luxembourg subsidiary of Amazon.com, Inc. The US parent has "control" in the CLOUD Act sense and can be compelled to produce Frankfurt-region data. AWS has never claimed immunity here; their standard position is that they will notify customers where legally permitted (i.e., not under gag order) and challenge invalid requests. Neither of those notes changes the legal reach.

What about Microsoft Azure Confidential Computing — does hardware enclaves solve this?

Partially. Intel SGX, AMD SEV-SNP, and similar confidential-computing technologies encrypt data in use such that the provider's own infrastructure operators cannot read memory contents. That is genuinely helpful against insider risk and against some CLOUD Act access patterns. It does not solve the problem for: data at rest (unless you also manage the keys outside the enclave), data passing through provider-controlled code paths outside the enclave (logging, telemetry, load balancers), and data held in backups. Confidential computing is a supplementary measure, not a replacement for picking a non-CLOUD-Act provider.

Is FISA 702 more dangerous than the CLOUD Act?

For European personal data, yes. FISA 702 is the statute Schrems II cited as incompatible with EU fundamental rights. It authorizes bulk collection from US "electronic communications service providers" targeting non-US persons abroad — which is basically the definition of a European business customer. Unlike the CLOUD Act, FISA 702 requests have no meaningful adversarial process, no customer notice (ever), and no realistic challenge path. The CJEU's Schrems II ruling was primarily about FISA 702 and EO 12333, not the CLOUD Act — though all three together form the reason European regulators treat US clouds as "third country with problematic surveillance law."

Does the EU-US Data Privacy Framework (TADPF, 2023) fix this?

No. The Trans-Atlantic Data Privacy Framework addresses the commercial transfer side: it gives US companies a certification mechanism to receive EU personal data legally under Article 45. It does not amend the CLOUD Act, FISA 702, or Executive Order 12333. It adds a "Data Protection Review Court" (DPRC) where EU persons can theoretically complain about US intelligence access, but that court is administrative, non-public, cannot award damages, and its independence has been challenged. Max Schrems has already announced a "Schrems III" challenge is in preparation; most EU lawyers expect TADPF to fall within 2–4 years, just as Privacy Shield (2016) and Safe Harbor (2000) did before it.

What about GAIA-X — is that a real alternative?

GAIA-X is an EU-wide framework and data-space initiative, not itself a cloud provider. It defines certifications, interoperability standards, and federated-identity primitives for European cloud offerings. It is aspirational, partially implemented, and still includes US hyperscalers as members — so GAIA-X membership is not, by itself, evidence that a provider is CLOUD-Act-free. Look instead at corporate ownership, jurisdiction, and specific certifications like France's SecNumCloud or Germany's BSI C5 Type 2.

What about end-to-end encryption — does that fully solve the CLOUD Act?

It helps a lot but does not fully solve it. End-to-end encryption where keys never leave the customer's infrastructure protects data at rest and in transit through the provider. It does not protect: (a) metadata (who communicated with whom, when, from where — which is often what intelligence agencies actually want), (b) data while in active use (open files, live database queries, running application memory), and (c) data in services where the provider necessarily has access to cleartext (email spam filtering, full-text search, AI/ML features). For sensitive workloads you should combine E2E encryption with an EU-sovereign provider, not pick one and skip the other.

Our competitors still use AWS — is CLOUD Act risk really a sales issue?

Increasingly, yes, and more every quarter. In 2026, EU public-sector RFPs routinely require "not subject to third-country law with extraterritorial reach." Regulated B2B buyers — banks under DORA, insurers, healthcare, large enterprises with a DPO who reads Schrems II rulings — ask the question in procurement. Being on AWS is not disqualifying everywhere, but being on an EU-sovereign provider is now a positive differentiator in RFPs that three years ago would not have asked.

If CLOUD Act requests are rare, why worry?

Two reasons. First, rarity is a red herring — regulatory risk, not per-request probability, is what matters for GDPR compliance. A single enforcement action can result in fines up to 4% of global turnover. Second, the CLOUD Act is the floor, not the ceiling, of US extraterritorial data reach. FISA 702, NSLs, grand jury subpoenas under the SCA, and export-control-adjacent demands all layer on top. The aggregate exposure is much larger than any one statute's individual volume.

Bottom Line

The CLOUD Act is not going away. Microsoft's own lawyers told the French Senate, under oath, that their EU Data Boundary cannot neutralize it. The "sovereign cloud" offerings from AWS, Azure, Google, and Oracle are engineering improvements that reduce some risks without closing the core legal gap: as long as the parent company is US-domiciled, the US government has reach.

The practical response for a European business in 2026 is not "ban all US software" — it is data classification plus right-sized provider choice. Keep the public and low-sensitivity workloads wherever they are cheapest. For Tier A and most of Tier B — personal data, regulated data, anything that would embarrass you on the front page of Le Monde or Der Spiegel — use a genuinely EU-sovereign provider.

OVHcloud, Scaleway, Hetzner, IONOS, STACKIT, Exoscale, and DanubeData are all viable depending on your workload and scale. The one we built — DanubeData — aims at the specific developer-facing sweet spot: managed Postgres/MySQL/MariaDB, managed Redis/Valkey/Dragonfly, S3-compatible storage, Knative serverless, and KubeVirt VPS — all on Hetzner bare metal in Falkenstein, Germany, under EU jurisdiction, with no US parent in the ownership chain.

If you want to move one workload to start, a Postgres database or an S3 bucket is usually the lowest-effort, highest-sovereignty-win swap.

Start your EU-sovereign stack:

• Spin up a Managed Postgres in Falkenstein for €19.99/mo
• Create an S3 bucket for €3.99/mo (1 TB storage + 1 TB traffic included)
• Deploy a VPS from €4.49/mo with 20 TB traffic
• Pair with our companion Schrems II sovereignty guide for the full regulatory picture

Your €50 signup credit is waiting at danubedata.ro.

Questions about your specific TIA, DPIA, or migration? Get in touch — we read every message, and we're happy to help you plan a sovereign migration even if it means only part of your stack moves to us.