Does FISA Section 702 Apply to Data Hosted by US Cloud Providers in Europe?

Key Points:

• Yes. FISA Section 702 applies to data hosted by US cloud providers in Europe. The hook is jurisdiction over the provider, not the location of the hardware: if a US-headquartered company (or a subsidiary it controls) can access the data, a 702 directive can compel it, whether the disk is in Frankfurt, Dublin or Virginia.
• Section 702 targets non-US persons located outside the United States, which means EU customers of US providers are exactly the population it is written for. That is the opposite of the intuition most engineers have about 702 being a US-domestic surveillance power.
• FISA 702 and the CLOUD Act are two separate exposures. The CLOUD Act is a law-enforcement production power (18 U.S.C. §2713) reachable with a warrant and subject to comity challenges; 702 is a foreign-intelligence collection programme run through directives to "electronic communication service providers" with no notice to the customer.
• Sovereign programmes reduce exposure but do not end the legal question. AWS European Sovereign Cloud, the Microsoft EU Data Boundary and Google Sovereign Cloud's partner-operated models change the contracting entity, the staffing and sometimes the operator, and only a model where no US-controlled entity can technically access plaintext meaningfully narrows 702's reach.
• The architectural answer is control plus keys: customer-held encryption keys outside the provider's reach, EU contracting entities, EU-only operations staff, and a deployment layer that keeps your workloads in your own account. Qovery installs into your own AWS, GCP, Azure or Scaleway account, or on an existing Kubernetes cluster at a European provider or on-prem, so no third-party SaaS tenancy ever holds your data.

A year ago a CTO told me his data was "fully in Europe" because he had picked the Frankfurt region. I asked him one question: who signs your contract, and could that company's US parent be ordered to hand over your data? He did not have the answer. That gap, between "our data is in Frankfurt" and "our provider is under US jurisdiction", is where most European data-residency plans quietly fall apart.

I run an infrastructure company, not a law firm, so treat this as engineering guidance and run your shortlist past your DPO or counsel before you sign anything. But the engineering reality here is clear enough to act on, and it starts with a yes.

Does FISA Section 702 apply to data hosted by US cloud providers in Europe?

Yes. Section 702 can reach data held by a US-headquartered cloud provider in an EU region, because the statute attaches to the provider's status as a US "electronic communication service provider" and its ability to access the data, not to the physical location of the server. An EU region, an EU data centre and EU-resident data all leave that answer unchanged.

The mechanism is simple once you see it. Under 50 U.S.C. §1881a, the Attorney General and the Director of National Intelligence issue annual certifications, the Foreign Intelligence Surveillance Court approves the procedures, and directives then go to providers compelling assistance in acquiring communications. The directive follows the company, not the country the disk sits in.

A few points that change how you read this:

• Who 702 targets: non-US persons reasonably believed to be located outside the United States. That is precisely the profile of a European company and its users. If you assumed 702 was a US-domestic power, flip that assumption.
• The carve-out most people cling to: 702 cannot intentionally target US persons or anyone known to be inside the US. For an EU customer that is weak comfort, not strong protection, because you are not the protected class.
• The control test, stated plainly: if a US parent, or a subsidiary it controls, holds the keys or can produce your plaintext, location is not a defence.
• The scope boundary: 702 does not reach a provider with no US nexus and no US-controlled access to your data. That is why the jurisdiction of the contracting entity is the first procurement question, not the last.

The three tables later in this article (legal instruments, sovereign programmes, and an eight-question procurement checklist) are built to be used, not just read. Start with the answer above, then use them to pressure-test your own stack.

What is FISA Section 702 and what can it actually compel a cloud provider to do?

Section 702 of the Foreign Intelligence Surveillance Act authorises warrantless collection of the communications of non-US persons abroad, carried out by compelling assistance from US "electronic communication service providers" under certifications approved by the FISA Court. For a cloud provider, that means a directive to hand over or facilitate access to specified accounts or selectors, with a gag on disclosure.

What the statute actually contains (50 U.S.C. §1881a):

• Annual certifications from the AG and DNI, plus targeting and minimisation procedures. The FISA Court approves the procedures, not each individual target, which is a key difference from a traditional warrant.
• A definition of "electronic communication service provider" that is broad, and that the 2024 reauthorisation debate tried to widen further. The scope of that term was one of the most contested parts of the last fight (Congressional Research Service, Section 702 and RISAA).
• Two collection modes: "upstream" collection from the internet backbone, and "downstream" (PRISM-style) collection from providers. Cloud customers are exposed primarily through the second.
• Content, not just metadata. 702 reaches communications content, which includes files and messages stored with the provider, not merely billing or connection records.

What a customer sees is nothing. There is no notice, there are non-disclosure obligations, and the only visibility comes afterwards in aggregate transparency reporting. The number of 702 targets has climbed year over year and now runs well into the hundreds of thousands, per the ODNI Annual Statistical Transparency Report; I am deliberately not quoting a single headline figure because the report breaks it down several ways and the trend is the point.

One timely wrinkle you should know in October 2026: the statute itself lapsed. Section 702 expired at midnight on 12 June 2026 after the House declined to extend it, the first statutory lapse of this authority (EFF). That does not mean the surveillance stopped. The FISA Court approved the current certifications in March 2026, and under the transition rules that collection continues until those certifications expire, around March 2027 (Brennan Center resource page). So the programme is live, it has a review horizon, and a future reauthorisation could change the "electronic communication service provider" definition again. Build for the regime existing, not for it being gone.

How is FISA 702 different from the US CLOUD Act, and which one should worry you more?

They are different powers with different triggers, and for most European teams FISA 702 is the harder one to mitigate contractually. The CLOUD Act is criminal-law production you can sometimes challenge in court; 702 is intelligence collection with no customer notice and no meaningful customer-side remedy.

The shared root cause is what makes "our servers are in Frankfurt" answer neither: both reach data in the possession, custody or control of a US-jurisdiction entity. The CLOUD Act made that explicit for stored-communications production, requiring a US provider to produce data it controls regardless of where it is stored, and the DOJ's own CLOUD Act materials explain the comity analysis and executive agreements that can soften it.

Where they diverge:

• Defences. The CLOUD Act allows a comity analysis, executive agreements between governments, and a provider motion to quash. Section 702 offers the customer none of those.
• Redress. The EU-US Data Privacy Framework leans on Executive Order 14086 and the new Data Protection Review Court as the redress mechanism for signals-intelligence collection. The standing criticism is that this court sits inside the executive branch rather than the judiciary, which is one of the points the Latombe challenge pressed (more on that below).
• The others teams confuse with these two: FISA business records (Section 215), National Security Letters, and Executive Order 12333 bulk collection abroad. Each has a different trigger and a different blast radius.

Here is how the main instruments line up.

For the engineer the takeaway is blunt: you can sometimes litigate a CLOUD Act demand. You cannot litigate a 702 directive. So 702 is the exposure you solve with architecture, not with contract language.

Does an EU region, EU data residency or an EU subsidiary put you outside FISA 702?

No. Region selection, EU-resident data and an EU-incorporated subsidiary of a US parent do not remove 702 exposure, because the question the statute asks is whether a US-jurisdiction entity can access the data. The only levers that genuinely move the needle are the identity of the controlling entity and whether anyone under US jurisdiction can produce your plaintext.

Three things teams constantly conflate, kept separate:

• Data residency: where the bytes physically sit. Useful for latency and for some sector rules, close to useless against 702 on its own.
• Data sovereignty: which law governs and which entity operates the service.
• Jurisdictional immunity: the state where no US-controlled entity can be compelled because none can access the data. This is the only one 702 actually respects.

The EU-subsidiary argument usually fails on the details. A US parent controls its EU subsidiary, group-level administrators often retain access, and shared identity, support and telemetry systems cross the border even when the primary data store does not. "The data lives in our German GmbH" is not the same claim as "no person under US jurisdiction can read it".

Encryption deserves an honest answer rather than a slogan, because the type of key custody is what decides whether encryption helps here:

• Provider-managed keys: the provider can decrypt. No barrier to a directive.
• Customer-managed keys inside the provider's KMS: better operationally, but the key still lives in a system the US-jurisdiction provider operates, so the access path is narrower, not closed.
• External key stores and customer-held keys outside the provider (for example AWS KMS External Key Store) plus confidential computing: these are the first measures that can actually remove the provider's ability to produce plaintext, and even then you have to verify the operational paths around them.

The place most residency claims break is support and telemetry: global support tenancy access, diagnostic data flowing out, and backup or disaster-recovery regions outside the EU. That is exactly the reasoning EU regulators apply. Schrems II requires supplementary measures where the importer is subject to problematic surveillance law (EDPB Recommendations 01/2020), and the EDPS found the European Commission's own use of Microsoft 365 non-compliant on transfer safeguards and purpose limitation (EDPS decision, March 2024). If a regulator says that about the Commission's own deployment, your Transfer Impact Assessment cannot wave the question away.

The practical conclusion fits on one line: if your threat model includes US intelligence access, choose a provider with no US nexus, or hold the keys yourself in a system the provider cannot reach.

What do AWS, Microsoft and Google sovereign cloud programmes change about FISA 702 exposure?

They change the contracting entity, the operating staff and the data boundary, which reduces practical exposure and satisfies many regulatory checklists, and none of them is a published guarantee that a US parent could never be compelled. Read the governance model and the signing entity, not the launch blog post. Credit where it is due: these are real, expensive investments with detailed public documentation, not marketing veneer.

• AWS European Sovereign Cloud. AWS launched it in January 2026 with a first region in Brandenburg, Germany, backing it with a planned investment of more than 7.8 billion euros (AWS launch announcement; investment detail). It runs under a dedicated European parent and German subsidiaries led by EU citizens, operated exclusively by EU residents, physically and logically separate from other AWS regions. This is the most structurally serious hyperscaler answer to the jurisdiction question I have seen. The residual question is whether a dedicated governance structure fully severs ultimate parent control, which is a legal judgment, not a technical one.
• Microsoft EU Data Boundary. Microsoft documents which categories of customer data stay in the EU, and documents the support, telemetry and troubleshooting flows that remain exceptions (Microsoft EU Data Boundary docs). Microsoft also publishes a commitment to challenge government orders for customer data. The documented exceptions are the part to read closely, because that is where access paths survive.
• Google Sovereign Cloud. Google offers tiers, including partner-operated models: a T-Systems-operated German sovereign cloud, and S3NS in France, a Thales subsidiary (Google Sovereign Cloud). In the newer Thales-operated German model, Thales is set to hold the root of trust and keys with Google having no access to the operation (Thales / Google Cloud announcement). The further the keys and operations sit from the US parent, the lower the 702 exposure.
• European providers with no US parent, named fairly because for some of you jurisdictional immunity is the hard requirement: OVHcloud and Scaleway in France (several of their services carry ANSSI SecNumCloud qualification), Exoscale in Switzerland, and Hetzner, IONOS and StackIT in Germany. On the pure jurisdiction axis, several of these are stronger than anything a US hyperscaler can structurally offer, and stronger on that axis than anything in Qovery's own remit.

The honest tradeoff: hyperscaler managed-service depth and raw capacity against sovereign jurisdiction. Many teams split the difference, keeping sensitive workloads on a jurisdictionally clean provider and general workloads on a hyperscaler. The big three still hold roughly 70% of the European cloud market while European-headquartered providers sit near 15% (Synergy Research), so this is a deliberate choice against the default, and it needs an owner.

Checked October 2026. These classifications reflect each provider's published documentation and are an engineering read, not a legal opinion. "Designed so no" means the published model is built to prevent US-controlled plaintext access; whether it fully defeats a 702 directive is a legal question for your counsel. Certification scope varies by service, so confirm the exact service you will use carries the certification you need.

How do you reduce FISA 702 exposure in your architecture, not just in your contract?

Reduce exposure by removing the technical ability of any US-jurisdiction entity to produce your plaintext, then prove it in an audit trail. Contract clauses matter, but 702 is answered by key custody, entity choice and keeping your workloads inside accounts you control.

The control hierarchy, ordered by how much it actually reduces exposure:

1. EU provider with no US parent. The cleanest answer when jurisdiction is the requirement.
2. Customer-held keys outside the provider, so the operator cannot decrypt even if compelled.
3. Confidential computing and external key management on a hyperscaler, which narrow the access path without always closing it.
4. EU-only staffing and data-boundary commitments, which constrain the human and operational paths.
5. Contractual pledges alone, which are the weakest layer and the one most teams over-rely on.

The audit list most teams fail, because they check the compute region and stop:

• Control-plane region, CI runner location, container registry region.
• Secrets store location, log and APM destination, backup and DR region.
• And the one everyone skips: exactly who at each vendor can read your tenant.

Here is the quiet 702 problem almost nobody puts in their TIA. You pick an EU region for compute, then push your build artefacts, environment variables and secrets into a SaaS deployment platform whose control plane is a US-operated multi-tenant service. Your containers run in Frankfurt; your secrets and config live in a US company's tenancy. You solved data residency for the compute and reopened the jurisdiction question for the most sensitive material you have. If your deployment tool is a US SaaS, your 702 answer is incomplete no matter where your pods run.

Two more measures that EU regulators actually credit, under the Schrems II supplementary-measures logic rather than as GDPR box-ticking: data minimisation and pseudonymisation, so that even compelled access yields less. And keep portability real so that a legal change is a cluster move rather than a rewrite: Kubernetes-native workloads, no hard dependency on one provider's proprietary services, and the EU Data Act switching-charge phase-out from 12 January 2027 as procurement bargaining power.

This is where Qovery fits, stated without overreach. Qovery is cloud-agnostic and Kubernetes-native, and it installs into your own AWS, GCP, Azure or Scaleway account, or on top of an existing or self-managed Kubernetes cluster at a European provider or on-prem, which is how teams run it on OVHcloud, Exoscale, IONOS, Hetzner or in their own data centre. Your workloads, your data and your cloud bill stay in your name, and no third-party SaaS tenancy ever holds them. The verified capabilities I will stand behind: git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

The limits, just as plainly: Qovery does not change which law applies to your underlying cloud provider, it does not hold your data, and it does not replace a Transfer Impact Assessment or your DPA review. If you run on an EU provider, Qovery helps you keep it that way and move cleanly if the law shifts. It does not make a US cloud provider immune to 702.

What does FISA 702 mean for GDPR compliance and your Transfer Impact Assessment?

Under GDPR Chapter V, 702 exposure is a factor you must assess and document, not a bar you can ignore. The EU-US Data Privacy Framework gives you an adequacy basis for transfers to certified US companies, it is under live legal challenge, and regulators expect a documented assessment plus supplementary measures where risk remains.

The chain in plain terms:

• July 2020: the CJEU's Schrems II judgment invalidated Privacy Shield, citing Section 702 and EO 12333, and required supplementary measures for transfers that continue (Case C-311/18).
• 10 July 2023: the Commission adopted the EU-US Data Privacy Framework adequacy decision, built on EO 14086 safeguards and the Data Protection Review Court.
• 3 September 2025: the EU General Court dismissed the Latombe challenge (Case T-553/23) and upheld the Framework at first instance (IAPP coverage). Latombe has appealed to the Court of Justice (Case C-703/25 P), so the Framework stands today but is not yet past final challenge. Verify the current status before you rely on it long-term.

What the Framework does and does not do: it covers certified US organisations and provides EO 14086 safeguards and the Data Protection Review Court as redress. It does not stop 702 collection; it constrains it and offers after-the-fact redress. So an adequacy decision is a lawful transfer basis, not a reason to skip the technical measures.

A usable Transfer Impact Assessment names the entities and their jurisdictions, the specific laws in scope (702, the CLOUD Act, EO 12333), the categories of data, the technical and organisational measures in place, the residual risk, and the person who signed off. Sector overlays raise the bar further: DORA for financial entities (applicable since 17 January 2025), the EU AI Act obligations phasing in through 2026 and 2027, ANSSI SecNumCloud in France, BSI C5 in Germany, and HDS for French health data.

Enforcement is not theoretical. The Irish DPC fined Meta 1.2 billion euros in May 2023 for continuing EU-US transfers on safeguards that did not meet the Schrems II standard (DPC decision). The one-line rule I give my own team: document the assessment, reduce the technical access path, and keep the exit option open.

What should you ask a cloud provider about FISA 702 before you sign?

Ask these eight questions in writing. A provider that cannot answer all eight in a contract annex or a published document has not answered your 702 question. Each is written to paste straight into an RFP or a vendor assessment.

1. Which legal entity signs the contract, where is it incorporated, and is any parent or affiliate subject to US jurisdiction?
2. Do you consider yourself an "electronic communication service provider" under FISA 702, have you ever received a 702 directive, and what does your transparency report disclose?
3. Can any employee or affiliate under US jurisdiction technically access my plaintext data, including through support, telemetry or hardware management?
4. Can I hold encryption keys outside your infrastructure, and what functionality do I lose if I do?
5. Where do your support and operations staff sit, and is EU-only support contractually available and auditable?
6. Can you give me a full subprocessor list with locations, including monitoring, telemetry and hardware-management vendors?
7. What is your documented policy on challenging government access orders, and will you notify me where legally permitted?
8. What is the exit plan: how do I move my data and workloads out, in what timeframe, and at what cost in euros?