Here is something most CTOs get wrong: storing your data in Frankfurt or Dublin does not put it beyond the reach of US law enforcement. Two US federal laws — the CLOUD Act and FISA Section 702 — let US authorities compel any US-controlled cloud provider to hand over data, wherever in the world that data actually sits. Jurisdiction follows corporate ownership. Not server location.
That creates a direct, irreconcilable conflict with GDPR Article 48, which prohibits disclosure of EU personal data to foreign authorities without a recognised international agreement. The current EU-US Data Privacy Framework does not fix this. And the Schrems case history tells you exactly how durable these frameworks are — two have already been struck down, and a third challenge is now before the CJEU.
This article explains what the CLOUD Act and FISA 702 actually say, how they collide with GDPR, and what it means for your cloud provider decisions. For some useful background on the difference between data residency and data sovereignty, start with our guide on understanding sovereign cloud.
What Does the CLOUD Act Actually Say?
The Clarifying Lawful Overseas Use of Data Act passed in 2018. It was designed to close a gap exposed by the “Microsoft Ireland” case, in which a US court ruled the government could not compel disclosure of data held overseas. Congress closed that gap.
The principle is straightforward: jurisdiction attaches to the entity, not the data. Any US-controlled provider — Microsoft, Amazon, Google — can be compelled by US court warrant to produce data stored in EU data centres. No notification to the data subject required. No involvement of any EU supervisory authority. EU-resident data can be accessed without the user or any European institution knowing about it.
The normal channel for this kind of cross-border data access is the Mutual Legal Assistance Treaty process — a government-to-government mechanism that takes time and requires bilateral agreement. The CLOUD Act was specifically created to bypass it. There is no US-EU executive agreement in place, so the law applies in its default and broadest form. Amazon, Microsoft, and Google control roughly 70% of the European cloud market. All three are US entities. Selecting an EU region does not change that.
What Is FISA Section 702 and How Does It Differ from the CLOUD Act?
FISA Section 702 is the less-discussed sibling of the CLOUD Act — but it operates through the same jurisdictional logic and hits the same US-controlled providers.
The CLOUD Act is a law enforcement tool. It requires a court-issued warrant for specific data on a specific target. FISA 702 is different in kind. It is bulk intelligence collection — it authorises US intelligence agencies, principally the NSA and FBI, to collect communications data of non-US persons from US providers, without individualised warrants. NOYB characterises it as allowing the US government to engage in “mass surveillance of EU users by scooping up personal data from US Big Tech.”
FISA 702 was a primary basis for the CJEU invalidating Privacy Shield in Schrems II. The Court found it does not meet EU fundamental rights requirements on necessity and proportionality.
Things got worse in January 2025. The Trump administration dismissed members of the Privacy and Civil Liberties Oversight Board — the independent US body responsible for overseeing FISA 702 programmes — leaving it non-functional. The EU Commission cited the PCLOB 31 times in its DPF adequacy decision. Max Schrems put it bluntly: “This deal was always built on sand. Instead of stable legal limitations, the EU agreed to executive promises that can be overturned in seconds.”
How Do GDPR Article 48 and the CLOUD Act Directly Conflict?
GDPR Article 48 is the critical provision here. It says that foreign court or authority orders for data transfer can only be enforced in the EU if they are based on a recognised international agreement — like an MLAT — between the requesting country and the EU or a Member State.
A CLOUD Act warrant is not based on any such agreement. It is a unilateral US instrument. That puts US-controlled providers in an impossible position: comply with the CLOUD Act and breach GDPR Article 48, or refuse the warrant and face US contempt of court. There is no safe path through the middle.
Standard Contractual Clauses do not fix this either. Schrems II was explicit on this point — SCCs are a contractual mechanism and cannot cure a statutory problem. A CLOUD Act warrant overrides any contractual commitment your provider has made about data handling. The EDPB stated clearly: “Service providers subject to EU law cannot legally base data transfers to the US solely on CLOUD Act requests.”
Here is the practical consequence for your organisation: even though the disclosure decision is your provider’s, you bear GDPR responsibility for your processing arrangements. We are talking potential DPA enforcement, fines up to 4% of global annual turnover, and civil liability to data subjects — for a warrant disclosure you never knew about.
Why Do EU-US Data Transfer Frameworks Keep Failing?
It comes down to a structural mismatch. US executive action provides data protection safeguards; the CJEU assesses whether those safeguards are adequate given unchanged US surveillance law. Twice, the Court has found they are not.
Safe Harbor (2000–2015) was invalidated in Schrems I after Snowden’s revelations exposed US surveillance at a scale incompatible with EU fundamental rights.
Privacy Shield (2016–2020) was invalidated in Schrems II because FISA Section 702 and Executive Order 12333 were found incompatible with EU fundamental rights. The Court found US law does not provide “essentially equivalent” protection.
The EU-US Data Privacy Framework (DPF, 2023) followed Executive Order 14086, which created a redress mechanism. But the CLOUD Act is entirely unchanged. The DPF addresses adequacy of commercial data transfers — it does not touch CLOUD Act or FISA 702 authorities. If you are relying on the DPF for GDPR compliance, you are not protected against CLOUD Act warrants. These are distinct legal questions with different answers.
The active risk right now is the Latombe challenge, appealed to the CJEU on 31 October 2025 — a potential Schrems III. The pattern is structural: every framework relies on US executive action, which the next administration can reverse. US surveillance law itself has not changed through any of them.
What AWS ESC and Azure’s EU Data Boundary Actually Resolve — and What They Do Not
The hyperscalers have introduced sovereign cloud products that address real operational concerns while not resolving the underlying legal exposure. Here is what they actually do — and what they do not.
Microsoft Azure EU Data Boundary restricts certain data flows outside the EU/EEA and limits Microsoft support staff access. Genuine improvements for data residency. What does not change: Microsoft is a US-controlled entity subject to the CLOUD Act. Microsoft’s chief legal officer stated before the French Senate — under oath — that Microsoft cannot guarantee EU customer data is safe from US government access. A US court can still issue a CLOUD Act warrant to Microsoft Corporation, and Microsoft is legally obligated to comply.
AWS European Sovereign Cloud (ESC), which opened in January 2026, is operated by a dedicated German legal entity — Amazon Web Services EMEA SARL — with EU-resident staff and physical separation. Meaningful for data residency. Unresolved: Amazon.com Inc. remains the US parent. The CLOUD Act applies at the parent level. A US court can issue a CLOUD Act warrant to Amazon.com Inc. for data held in the ESC. The subsidiary’s operational independence does not sever the parent’s statutory obligation to comply.
Google Cloud Sovereign Controls offers customer-managed encryption and access controls. Google LLC is a US entity subject to both the CLOUD Act and FISA 702. Sovereign controls do not change that.
The core distinction is data residency versus data sovereignty. Residency is where data sits. Sovereignty is who has legal control over access. EU Data Boundaries and sovereign cloud regions address residency. None of them changes legal control, because that is determined by corporate ownership.
Encryption helps but does not solve it. BYOK and HYOK protect data at rest by keeping encryption keys under your control. But data must be decrypted in RAM during active processing — that is the residual gap. For a detailed breakdown, see how BYOK and HYOK reduce your practical exposure. For a full assessment of the hyperscaler offerings, see how AWS ESC and Azure attempt to address this.
What This Means for Your Cloud Provider Choice
The exposure is real, it is unresolved by any existing hyperscaler product, and it is your compliance problem even though it originates in your provider’s legal obligations. Here is what you do with it.
Run a Transfer Impact Assessment. A TIA is required under GDPR for any data processing arrangement involving non-EU providers. For US providers, the TIA must explicitly address the CLOUD Act and FISA 702 as material transfer risks. Not a generic adequacy finding — an actual assessment of what these specific statutory authorities mean for your specific data categories.
Ask your provider four questions:
- Is the operating entity US-controlled, or does any parent or affiliate fall under US jurisdiction?
- What is your legal obligation when you receive a CLOUD Act warrant for our data?
- Do you notify us before complying, or is notification prohibited?
- Can you contractually guarantee you will not comply with a CLOUD Act request for our data?
Question four is the decisive one. No US-controlled cloud provider can answer it affirmatively. If any claims they can, ask them to put it in writing.
Classify your workloads. Not all data carries the same exposure. Non-personal operational data and dev environments can stay on US hyperscalers with standard safeguards. Business communications and non-regulated personal data warrant HYOK encryption and data minimisation. Health data, financial records, and regulated personal data should go to EU-controlled providers with no US corporate parent.
The “EU region” checkbox is not a compliance answer. It tells you where your data is stored. It does not tell you who has legal jurisdiction over access to it. That is determined by corporate ownership — and it does not change just because you selected Frankfurt in the AWS console.
For a comprehensive framework for working through these decisions, see our sovereign cloud guide.
Frequently Asked Questions
Can the US government access my company’s data if it is stored in an EU data centre?
Yes. Under both the CLOUD Act and FISA Section 702, US authorities can compel US-controlled cloud providers to hand over data regardless of where it is physically stored. Data location in the EU does not override US jurisdictional claims over US-owned providers.
Does the EU-US Data Privacy Framework protect my data from CLOUD Act requests?
No. The DPF addresses the adequacy of commercial data transfers. It does not modify the CLOUD Act or FISA 702. A CLOUD Act warrant can still be issued to any US-controlled provider, and the provider remains legally obligated to comply.
What is the difference between the CLOUD Act and FISA 702?
The CLOUD Act is a law enforcement tool requiring a court-issued warrant for specific data. FISA Section 702 is an intelligence authority enabling bulk collection of foreign nationals’ communications through annual programme-level authorisations, without individualised warrants. Both apply to US-controlled providers regardless of data location.
Did Microsoft really admit it cannot guarantee EU data stays out of US hands?
Yes. Microsoft’s chief legal officer stated before the French Senate, under oath, that Microsoft cannot guarantee EU customer data is protected from US government access. This reflects the legal reality: as a US-controlled entity, Microsoft is subject to the CLOUD Act regardless of its EU Data Boundary programme.
Are Standard Contractual Clauses enough to protect EU data on US cloud providers?
No. The CJEU established in Schrems II that SCCs cannot cure an underlying statutory surveillance law problem. The CLOUD Act and FISA 702 are statutory obligations that override contractual commitments.
What is GDPR Article 48 and why does it matter for CLOUD Act compliance?
Article 48 requires that any foreign authority order for data transfer can only be enforced if based on a recognised international agreement in force between the requesting country and the EU or a Member State. CLOUD Act warrants are unilateral US instruments with no such backing. Complying with a CLOUD Act request therefore constitutes a breach of Article 48.
Could the EU-US Data Privacy Framework be invalidated like Privacy Shield was?
Yes, and it is actively being challenged. The Latombe challenge was appealed to the CJEU on 31 October 2025. Safe Harbor fell to Schrems I in 2015; Privacy Shield fell to Schrems II in 2020. The PCLOB dismissals in January 2025 have further weakened the DPF’s legal basis.
What is a Transfer Impact Assessment and do I need one?
A TIA is required under GDPR for any data processing arrangement involving non-EU providers. It evaluates whether the destination country’s legal regime provides adequate protection for the specific data being transferred. For US providers, the TIA must assess CLOUD Act and FISA 702 exposure as material transfer risks.
Does AWS European Sovereign Cloud eliminate CLOUD Act exposure?
No. AWS ESC is operated by a German legal entity with genuine operational separation, but Amazon.com Inc. remains the US parent. The CLOUD Act applies at the parent level, and the subsidiary’s operational independence does not sever the parent’s statutory obligation to comply with a US court warrant.
Is BYOK or HYOK encryption enough to prevent US government access to my data?
Partially. Both protect data at rest by keeping encryption keys under customer control. However, data must be decrypted in RAM during active processing — a residual access window. HYOK is more protective than BYOK because it keeps keys exclusively under customer control.
What questions should I ask my cloud provider about CLOUD Act exposure?
Ask: (1) Is the operating entity US-controlled, or does any parent or affiliate fall under US jurisdiction? (2) What are your obligations when you receive a CLOUD Act warrant for my data? (3) Do you notify me before complying? (4) Can you contractually guarantee non-compliance with CLOUD Act requests for my data? Most US providers cannot answer question four affirmatively. Any provider that claims they can should be asked to put it in writing.
