Your organisation stores all its data on servers in Frankfurt. Legal picked an AWS data centre in Germany so European customer data never leaves EU territory. Your procurement checklist has “EU data residency: confirmed” ticked off. You close the laptop feeling reasonably covered.
You are not covered.
The US CLOUD Act — the Clarifying Lawful Overseas Use of Data Act, signed into law in March 2018 — requires US-headquartered cloud providers to hand over stored data when compelled by US authorities, regardless of where that data physically sits. The server is in Frankfurt. The company is in Seattle. The law follows the company.
In this article we’re going to explain the mechanics: how the warrant process works, what a gag order means for your operations, why the International Criminal Court’s Chief Prosecutor got locked out of his Outlook email, how GDPR Article 35 turns this into a compliance obligation, and where encryption key management actually helps versus where it gives you a false sense of security. We’ll close with five questions you can apply to your own infrastructure today.
Sovereign cloud spend is forecast to more than triple across Europe from 2025 to 2027. Understanding how this law works is the first step — because cloud procurement is now a jurisdictional risk decision.
What is the US CLOUD Act and what does it actually authorise?
The CLOUD Act was signed into law on 23 March 2018. It amends the Stored Communications Act (SCA) — a 1986 statute written before cloud infrastructure existed — and adds a single operative provision codified at 18 U.S.C. § 2713: US-based service providers must preserve, backup, or disclose electronic communications and records regardless of whether that data is located within or outside the United States.
The obligation attaches to the provider, not to the geography of the server. What matters legally is whether the data is in the “possession, custody, or control” of the US-headquartered company. The operative phrase: jurisdiction follows the provider.
The warrant process itself is straightforward. A US law enforcement or intelligence authority issues a warrant, court order, or subpoena to the provider. The provider must comply — and may simultaneously be prohibited from telling the affected customer anything about it. That prohibition is the gag order, which we’ll get to.
Before the CLOUD Act, the Mutual Legal Assistance Treaty (MLAT) system governed cross-border data requests. That bilateral framework required judicial review in both countries, giving the affected party’s home jurisdiction a voice. MLATs were slow, but they provided procedural safeguards. The CLOUD Act bypasses MLATs entirely. A US authority can compel production directly, without involving any European judicial body.
Running alongside the CLOUD Act is a second exposure layer: FISA Section 702, which authorises US intelligence agencies to compel bulk collection of communications data from US providers under national security justifications, without an individual order for each target. Where the CLOUD Act is the law enforcement route, FISA 702 is the intelligence route. Both apply to your data.
Why does a Frankfurt data centre not protect you if the provider is American?
The jurisdiction-follows-the-provider principle collapses the distinction between where a server sits and what laws govern it. The relevant question isn’t “where is the data?” It’s “who controls the data, and where are they headquartered?”
Microsoft, Google, and AWS are US corporations. Every byte they store — whether in Frankfurt, Dublin, Amsterdam, or Tokyo — is within CLOUD Act reach. Microsoft’s own chief legal officer acknowledged this before the French Senate: the company cannot guarantee EU data is safe from US access requests, because Microsoft is a US-headquartered company subject to US jurisdiction regardless of server location.
This is the most important distinction in this whole article, so let’s be direct about it:
Data residency is where data physically sits — a server in Frankfurt, a data centre in Dublin. Data sovereignty is whose laws govern that data. A US provider with EU data centres gives you data residency. It does not give you data sovereignty.
The confusion is commercially useful to hyperscalers. Microsoft’s EU Data Boundary, Amazon’s European Sovereign Cloud, and Google’s Sovereign Controls are real products that limit certain operational access by provider employees. They do not change the provider’s legal obligations under US federal law. As Cristina Caffarra of the Eurostack Foundation put it: “A company subject to the extraterritorial laws of the United States cannot be considered sovereign for Europe. As long as the parent company is American, it remains subject to the CLOUD Act.”
Any private contract between a European customer and a US cloud provider is ultimately subordinate to US federal law. The provider cannot opt out by operating a European subsidiary, or by making contractual promises to resist government orders. A motion to quash exists — a legal challenge in US courts — but the burden of proof falls on the provider, and in practice these rarely succeed. How AWS and Microsoft respond to this legal threat is covered separately.
What is a CLOUD Act gag order and what happened at the ICC?
A gag order — technically a non-disclosure order — can be attached to a CLOUD Act order, an SCA order, or a National Security Letter, legally prohibiting the provider from notifying the affected customer that their data has been demanded or disclosed. The data access happens in legal silence. The customer receives no notice, cannot contest the order, and cannot invoke contractual notification clauses — the provider is legally barred from triggering them.
National Security Letters are even more opaque: the FBI can compel data production without any judicial oversight at all. Gag orders have no fixed maximum duration. You may never learn your data was accessed.
The ICC / Karim Khan case illustrates what this looks like in practice.
Karim Khan is the Chief Prosecutor of the International Criminal Court, headquartered in The Hague, Netherlands, operating under the Rome Statute. In 2025, Khan was temporarily locked out of his Microsoft Outlook account following a US government request — this during the period when the US had sanctioned Khan over his efforts to prosecute Israeli officials for alleged war crimes. A Microsoft spokesperson said the company hadn’t cut services to the ICC as a whole, yet Khan’s account access was disrupted.
In November 2025, the ICC announced it was replacing its Microsoft productivity software with OpenDesk — an open-source suite developed by ZenDiS, the German Centre for Digital Sovereignty, bundling Nextcloud (file sharing) and Collabora (office productivity). The migration was a direct institutional response to legal pressure that the ICC — despite operating as an international institution in a neutral European jurisdiction — could not resist while on infrastructure controlled by a US-headquartered company.
The gag order element is structurally important here. An organisation that relies on contractual transparency provisions as its primary protection is relying on a mechanism that gag orders are specifically designed to nullify. How European certifications address CLOUD Act exposure builds on this.
How does GDPR Article 35 turn CLOUD Act exposure into a compliance obligation?
GDPR Article 35 requires a Data Protection Impact Assessment (DPIA) before any processing “likely to result in a high risk to the rights and freedoms of natural persons.” Using a US cloud provider to process EU personal data triggers this requirement. When DPIAs are conducted properly for Microsoft, Google, or AWS services, they consistently flag CLOUD Act-enabled government access as a significant or unacceptable risk. There is no contractual or technical mitigation that fully eliminates CLOUD Act exposure while you remain with a US-headquartered provider. That documented finding creates a compliance obligation to act — not just to acknowledge the risk and move on.
GDPR Article 48 creates a direct statutory conflict. Article 48 prohibits using a foreign court order as the lawful basis for transferring EU personal data to a third country — transfers must be based on an international agreement like an MLAT, not a unilateral US legal demand. If a US provider complies with a CLOUD Act order by producing EU personal data, that compliance may violate GDPR Article 48. Comply with US law: potentially violate EU law. Refuse US law: face US legal consequences. That’s the double bind, and there’s no clean way out of it.
Austria’s Federal Ministry for Economy, Energy and Tourism migrated 1,200 employees to Nextcloud as a sovereignty decision, not a cost exercise. CIO Martin Ollrom was direct: “This is not just about Microsoft. It’s about a fundamental shift where Big Tech companies are moving all your data and operational control into their clouds.” Several other Austrian ministries have since followed.
The Schrems II ruling (Court of Justice of the EU, July 2020) invalidated the EU-US Privacy Shield because US surveillance law — specifically FISA Section 702 — didn’t adequately protect EU personal data. Since Schrems II, organisations transferring data to the US must complete Transfer Impact Assessments (TIAs) and implement supplementary measures when relying on Standard Contractual Clauses. SCCs cannot override US federal law. The EU-US Data Privacy Framework (DPF, July 2023) was intended to replace Privacy Shield, but Max Schrems has publicly indicated it doesn’t address the fundamental issues from Schrems II, and many legal experts anticipate a “Schrems III” challenge. The European cloud sovereignty decision framework addresses what organisations do once a DPIA reaches the inevitable conclusion.
Does BYOK encryption actually protect you from a CLOUD Act production order?
In standard BYOK implementations, the customer supplies encryption keys that are then imported into and managed by the cloud provider’s own Key Management System — AWS KMS, Azure Key Vault, or Google Cloud KMS. Despite the name, the provider retains access to those keys. Thales frames the risk precisely: encrypting data without managing the keys is like locking the door and leaving the key under the mat. A CLOUD Act production order can require the provider to use its KMS to decrypt and produce the data, and a gag order means you won’t be told it happened.
Here’s how the three options stack up:
Provider-stored BYOK: Customer-supplied keys imported into the provider’s own KMS. The provider retains access. No CLOUD Act shield. This is the most common enterprise “BYOK” implementation, and the one most often sold as a security solution when it isn’t one.
External KMS BYOK: Keys managed in a customer-controlled external KMS that the provider never directly accesses. This meaningfully increases the technical barrier — but the external KMS must itself be outside US legal jurisdiction to matter.
HYOK (Hold Your Own Key): Keys held entirely outside the provider’s environment — on-premises, in a hardware security module (HSM), or in a private cloud. The provider is technically incapable of decrypting data without customer co-operation, even under legal compulsion.
HYOK, correctly implemented, is the only encryption architecture that creates a genuine technical barrier to a CLOUD Act production order. Any implementation where the provider can reach the keys negates the protection. Even HYOK has limits — the provider still controls the compute layer, and HYOK has not been judicially tested as a CLOUD Act shield. The gap between “greater customer control” and “CLOUD Act immunity” is worth being very clear on before you treat BYOK as a sovereignty solution.
How do you audit your organisation’s CLOUD Act exposure right now?
This checklist is a starting point for risk visibility, not a compliance certification. The goal is to surface unknowns so you can make an informed decision about what to do next.
Question 1: Who manages your encryption keys? Identify whether the provider manages encryption keys in its own KMS. If yes — even if you originally supplied those keys under a “BYOK” arrangement — those keys and the data they protect are reachable under a CLOUD Act production order.
Question 2: Is your cloud provider US-headquartered? Check the headquarters of the legal entity your contract is with — not the data centre location. If the provider is incorporated or headquartered in the United States, the CLOUD Act applies to all data it holds regardless of where the server sits.
Question 3: Have you conducted a DPIA for your cloud services? Verify whether a DPIA has been conducted for each US cloud service processing EU personal data. If not, GDPR Article 35 likely requires one. If one was conducted, check whether CLOUD Act exposure was explicitly assessed. Many DPIAs from before 2021 predate the post-Schrems II understanding of this risk.
Question 4: Do your contracts include notification clauses, and under what jurisdiction? Review your enterprise agreements for notification clauses requiring the provider to alert you of government data requests. If US law governs those clauses, a CLOUD Act gag order renders them unenforceable at exactly the moment they matter most.
Question 5: What categories of data are in scope? Identify what your US cloud services actually hold: employee personal data, customer personal data, financial records, legally privileged communications, health records. Many organisations discover during data mapping that US-based sub-processors or integrations create CLOUD Act exposure through indirect routes, even when the primary provider is European.
These five questions are a starting point, not a complete legal assessment. Organisations processing sensitive EU personal data at scale should seek specialist legal advice and complete a formal Transfer Impact Assessment. As Martin Ollrom, CIO of Austria’s Federal Ministry for Economy, put it: “You don’t achieve digital sovereignty overnight. You have to start with the first step. Don’t just talk about it, but execute it.”
The sovereign cloud decision framework for European tech companies covers what those steps look like in practice.
FAQ
What does “jurisdiction follows the provider” mean in plain language?
US law attaches to your data based on where the cloud company is headquartered, not where the server sits. If your provider is a US company, the US can legally compel it to produce your data even if the server never leaves Germany.
Can a US cloud provider simply refuse a CLOUD Act order to protect its European customers?
A provider can file a motion to quash in US courts, but the burden of proof falls on the provider. In practice, motions to quash rarely prevent the production of European data.
What is the difference between BYOK and HYOK?
BYOK (Bring Your Own Key) means the customer supplies keys that are managed inside the provider’s own KMS — the provider retains access and can be compelled to decrypt. HYOK (Hold Your Own Key) means keys are held entirely outside the provider’s environment, so the provider technically cannot decrypt the data even under a legal order. Only HYOK creates a genuine technical barrier, and even then it hasn’t been judicially tested.
Does the EU-US Data Privacy Framework protect my data from the CLOUD Act?
No. The DPF governs commercial data transfers, not law enforcement or intelligence access. The CLOUD Act operates independently, and many legal experts anticipate a Schrems III challenge that could invalidate the DPF as Privacy Shield was invalidated in 2020.
How long does a CLOUD Act gag order last?
There’s no fixed maximum duration. Gag orders persist until a US court lifts them or the government withdraws them, with no mandatory notification once a gag order expires. You may never learn your data was accessed.
Can a company using Microsoft 365 or Google Workspace in Europe be confident its data is protected from US government access?
No contractual or operational measure short of migrating away from US-headquartered providers entirely eliminates CLOUD Act exposure. Microsoft’s EU Data Boundary and similar programmes reduce some operational access by provider employees but don’t change the provider’s obligations under US federal law.
What is GDPR Article 48 and why does it conflict with the CLOUD Act?
GDPR Article 48 prohibits using a foreign court order as the sole basis for transferring EU personal data to a third country — transfers require an international agreement like an MLAT. If a US provider complies with a CLOUD Act order by producing EU personal data, that compliance may violate Article 48. Comply with US law, potentially violate EU law: that’s the double bind.
What is FISA Section 702 and how does it relate to the CLOUD Act?
FISA Section 702 authorises US intelligence agencies to compel US providers to hand over communications of foreign nationals without an individual court order for each target. It operates alongside the CLOUD Act as a second exposure layer and was the primary basis for the Schrems II ruling that invalidated Privacy Shield.
What happened with the ICC and the CLOUD Act?
Karim Khan, the ICC’s Chief Prosecutor, was temporarily locked out of his Microsoft Outlook account following a US government request. The ICC — headquartered in The Hague, operating under international law — was not shielded from CLOUD Act reach. The ICC subsequently migrated to OpenDesk (ZenDiS), Nextcloud, and Collabora. Gag order provisions mean the full details haven’t been publicly disclosed.
Is there any data category that the CLOUD Act cannot reach?
No category is categorically exempt. Attorney-client privilege and medical confidentiality can be raised as grounds to challenge or narrow an order, but don’t automatically prevent access. The process is slow, costly, and uncertain.
What does a DPIA for a US cloud provider actually conclude?
A properly conducted GDPR Article 35 DPIA for Microsoft, Google, or AWS will document CLOUD Act extraterritorial access as a significant or unacceptable risk to EU data subjects. The DPIA must then conclude whether additional safeguards — HYOK encryption, data minimisation, service migration — are required, or whether the residual risk is accepted with documented rationale.
What is the OpenDesk migration and why did the ICC do it?
OpenDesk is a German open-source government desktop stack developed by ZenDiS, combining Nextcloud for file sharing and Collabora for office productivity. The ICC adopted it as a sovereignty-preserving alternative to Microsoft 365 following the Karim Khan account disruption — a documented institutional response to CLOUD Act exposure at the highest level of international public institutions.
