"EU-hosted" is not the same as "sovereign." This distinction, which procurement teams intuitively understand but vendor presentations routinely obscure, sits at the center of every cloud procurement decision involving personal data or regulated information in the European Union. The US CLOUD Act and FISA Section 702 create legal mechanisms through which US authorities can compel access to data held by US-headquartered companies regardless of where that data is physically stored. Understanding how these mechanisms work, where the EU-US Data Privacy Framework provides protection and where it does not, and what questions actually de-risk a vendor selection is now a core procurement competency for any EU organization handling regulated data.
The Legal Mechanisms: Cloud Act and FISA 702
Two US legal instruments create the sovereignty tension that EU procurement teams must navigate.
The CLOUD Act (2018)
The Clarifying Lawful Overseas Use of Data Act, enacted in 2018, clarifies (from the US government's perspective) that US law enforcement can compel US-headquartered technology companies to produce data stored outside the United States, including data stored in EU data centers. The Act applies to any provider of electronic communication services or remote computing services subject to US jurisdiction, which effectively means any company incorporated in the US or with sufficient US nexus.
The CLOUD Act does include a comity analysis provision (Section 2703(h)) that allows providers to challenge an order if compliance would create a material risk of violating the law of a qualifying foreign government. However, this provision has narrow application: it requires an executive agreement between the US and the foreign government, and while the US-UK CLOUD Act agreement exists, no equivalent US-EU agreement is in place. For EU data subjects, the comity provision provides no practical protection.
The operational implication is straightforward. If your cloud provider is a US company or a subsidiary of a US company, data stored in Frankfurt, Dublin, or Amsterdam is legally accessible to US law enforcement through a CLOUD Act order. Physical data residency does not defeat legal jurisdiction.
FISA Section 702
Section 702 of the Foreign Intelligence Surveillance Act authorizes the US government to conduct targeted surveillance of non-US persons located outside the United States through the compelled assistance of US electronic communication service providers. Unlike the CLOUD Act, which is a law enforcement mechanism subject to judicial oversight, FISA 702 operates under the Foreign Intelligence Surveillance Court (FISC) with classified procedures that provide no notice to the affected individuals or organizations.
FISA 702 is the mechanism that the Court of Justice of the European Union addressed in the Schrems II decision (C-311/18, July 2020). The CJEU found that US surveillance law, particularly FISA 702, did not provide adequate protection for EU personal data and invalidated the EU-US Privacy Shield framework as a basis for transatlantic data transfers.
For procurement teams, FISA 702 creates a different and in some ways more concerning exposure than the CLOUD Act. CLOUD Act orders at least require a specific legal process. FISA 702 surveillance can be conducted programmatically, targeting categories of foreign intelligence information rather than specific individuals, and the provider is legally prohibited from disclosing the existence of the surveillance to the affected customers.
The EU-US Data Privacy Framework: What It Covers and What It Does Not
The EU-US Data Privacy Framework (DPF), adopted by the European Commission's adequacy decision in July 2023, was designed to address the Schrems II concerns by establishing safeguards around US government access to EU personal data. Companies that self-certify under the DPF can receive personal data transfers from the EU without additional transfer mechanisms.
However, the DPF has significant limitations that procurement teams must understand.
The DPF addresses personal data transfers, not all data. Regulated data that is not personal data (trade secrets, financial data, security configurations, intellectual property) falls outside the DPF's scope. If your procurement concern extends beyond personal data to broader data sovereignty, the DPF does not resolve it.
The DPF's durability is uncertain. Max Schrems and noyb have signaled intent to challenge the DPF, as they did with Safe Harbor and Privacy Shield. While the framework remains valid as of this writing, basing a long-term procurement strategy on an adequacy decision that may face judicial challenge carries risk. The European Data Protection Board (EDPB) has noted concerns about the practical enforcement of the redress mechanism established under Executive Order 14086.
The DPF does not eliminate FISA 702. The DPF's safeguards (proportionality requirements, the Data Protection Review Court) are intended to constrain US surveillance, not eliminate it. US intelligence agencies retain the legal authority to conduct targeted surveillance under FISA 702. The DPF adds procedural constraints and a redress mechanism, but it does not provide the "essentially equivalent" protection standard that the CJEU articulated in Schrems II.
The DPF applies to self-certified companies. Not all US technology providers participate in the DPF. And even for participants, the self-certification covers specific data processing activities, not all data the company handles. Procurement teams should verify not just that a vendor is DPF-certified but that the specific services being procured are within the scope of the certification.
GDPR Articles 44-49: The Transfer Safeguard Framework
Beyond the DPF, GDPR provides a framework of transfer safeguards under Articles 44-49 that procurement teams should evaluate.
Article 46: Standard Contractual Clauses (SCCs). The European Commission's updated SCCs (adopted June 2021) remain the most commonly used transfer mechanism. However, the Schrems II ruling requires that SCCs be supplemented with additional safeguards if the law of the recipient country does not provide adequate protection. For transfers to US-based providers not covered by the DPF, this supplementary measures assessment is mandatory.
Article 47: Binding Corporate Rules (BCRs). BCRs provide a transfer mechanism for intra-group transfers. They require approval from a supervisory authority and are operationally intensive to implement. They do not resolve the FISA 702 exposure but do demonstrate governance commitment.
Article 49: Derogations. The derogations under Article 49 (explicit consent, contractual necessity, important reasons of public interest) are intended for occasional transfers, not systematic data processing arrangements. Relying on Article 49 derogations for a cloud services contract is not a defensible long-term position.
The practical question for procurement teams is: given the available transfer mechanisms and their limitations, what additional safeguards should we require from providers to manage the residual sovereignty risk?
The Procurement Decision Framework: Five Questions
A defensible sovereignty assessment in procurement should produce explicit, evidence-backed answers to five questions. These questions go beyond the standard vendor security questionnaire and address the specific sovereignty risks created by US legal instruments.
Question 1: Who can be legally compelled to produce the data?
Determine the provider's corporate structure and jurisdictional nexus. A US-incorporated company with an EU subsidiary that operates EU data centers is still subject to CLOUD Act orders. An EU-incorporated company with no US parent, no US operations, and no US ownership is not. The question is not where the data sits but where the legal compulsion runs.
For providers with complex corporate structures, trace the ownership chain. A company incorporated in the Netherlands but owned by a US parent may be reachable through the parent's CLOUD Act obligations. Document the jurisdictional analysis and the legal opinion supporting your conclusion.
Question 2: Who has technical access to the data?
Legal compulsion only matters if it can be operationally executed. Map the provider's technical access model: which personnel can access customer data, from which locations, under what authorization controls, and whether access is logged and auditable.
Focus on three access vectors: administrative access for operations and support, access through automated systems (backup, monitoring, analytics), and access through the provider's supply chain (subprocessors with data access). If US-based personnel can access EU-hosted data through any of these vectors, the data is technically reachable regardless of where it resides.
Question 3: Who controls encryption keys and break-glass mechanisms?
Encryption provides meaningful sovereignty protection only when the customer controls the keys. Evaluate the provider's key management model: are encryption keys held by the provider, by a third party, or by the customer? If the customer holds the keys, can the provider access data through any break-glass or emergency access mechanism? Is the key management architecture documented and independently audited?
Customer-managed keys (also called hold-your-own-key or BYOK) with genuine customer-side control is one of the strongest technical safeguards against compelled access. But the implementation details matter enormously. A "customer-managed key" that the provider can recover through a support process is not customer-managed in any meaningful sense.
Question 4: How is subprocessor exposure governed?
Modern cloud services depend on subprocessors: CDN providers, monitoring services, support tools, backup systems. Each subprocessor that handles customer data extends the sovereignty chain. Evaluate the provider's subprocessor list, the jurisdictional exposure each subprocessor creates, and the contractual controls governing subprocessor data access.
Under GDPR Article 28, the controller must authorize subprocessor engagement and the processor must impose equivalent data protection obligations on subprocessors. In practice, many cloud contracts include broad subprocessor authorization that limits the customer's practical ability to manage sovereignty risk in the subprocessor chain.
Question 5: How are government access requests handled?
Request the provider's policy and process for handling government access requests. A defensible policy should include: legal review of every request before compliance, challenge of requests that appear overbroad or jurisdictionally inappropriate, notification to the customer when legally permitted, transparency reporting on the volume and nature of requests received, and a clear escalation process when requests create a conflict between US law and GDPR obligations.
The absence of a clear, documented government access request policy is itself a procurement risk signal. If a provider cannot articulate how it handles the CLOUD Act/FISA tension, it has not thought through the problem.
Practical Procurement Criteria
Based on the five-question framework, procurement teams should evaluate providers against these operational criteria:
Corporate structure and jurisdiction. Strongly prefer providers incorporated in the EU or EEA with no US parent company or controlling shareholder. Where US-nexus providers are considered, require a detailed jurisdictional analysis documenting the CLOUD Act and FISA exposure.
Data processing location. Require that all data processing (not just storage) occurs within EU/EEA borders. This includes backup processing, analytics, monitoring, and support activities. Processing location commitments should be contractual, not marketing statements.
Personnel access controls. Require that only EU-based personnel can access customer data, with documented access control policies, access logging, and regular access reviews. Any exception (e.g., follow-the-sun support involving non-EU personnel) should be explicitly documented and risk-accepted.
Encryption and key management. Prefer providers offering customer-managed encryption keys with genuine customer-side control. Where provider-managed keys are used, require documentation of the key management architecture and confirmation that key access would be required to comply with a CLOUD Act order.
Contractual provisions. Include sovereignty-specific contractual provisions: notification obligations for government access requests (to the extent legally permitted), data portability and exit assistance, subprocessor change notification with opt-out rights, and audit rights covering sovereignty-relevant controls.
Exit readiness. Assess the practical feasibility of migrating away from the provider. Sovereignty risk is manageable when you have a credible exit path. Lock-in (through proprietary formats, integration complexity, or contractual barriers) transforms manageable sovereignty risk into structural dependency. This connects to the broader third-party exit strategy discipline that DORA mandates for financial entities.
Sector-Specific Considerations
The sovereignty risk tolerance varies by sector and data type. Financial services entities subject to DORA face specific concentration risk requirements and outsourcing governance obligations that intersect with sovereignty considerations. Healthcare entities handling patient data face the GDPR's special category data provisions (Article 9) in addition to general transfer requirements. Public sector entities may face national security classification requirements that create absolute sovereignty obligations beyond what GDPR alone requires.
For organizations subject to NIS2, the supply chain security requirements under Article 21(2)(d) extend the sovereignty analysis beyond the direct cloud provider to the provider's own supply chain. A cloud provider with EU-sovereign infrastructure but US-based subprocessors for critical functions may not satisfy the supply chain risk management expectations that NIS2 establishes.
The Procurement vs. Architecture Distinction
This post addresses the procurement decision framework: how to evaluate and select providers given sovereignty constraints. A related but distinct question is how to architect your systems to minimize sovereignty exposure regardless of which providers you select. The architectural patterns for EU data sovereignty are covered separately because the procurement decision and the architecture decision involve different stakeholders, different constraints, and different timelines.
The procurement decision determines which providers you will work with and under what contractual and governance terms. The architecture decision determines how you structure data flows, encryption boundaries, and processing patterns to minimize the sovereignty risk that remains after the procurement decision is made. Both decisions matter, and they should be made in coordination rather than in isolation.
Key Takeaways
- Data residency is necessary but not sufficient for sovereignty. The CLOUD Act enables US authorities to compel data production from US companies regardless of where data is stored. Physical location alone does not resolve the legal jurisdiction question.
- The EU-US Data Privacy Framework has limitations procurement teams must understand. It covers personal data transfers, its durability is uncertain, it does not eliminate FISA 702, and it applies only to self-certified companies within the scope of their certification.
- Evaluate providers against five sovereignty questions: legal compulsion exposure, technical access model, encryption key control, subprocessor governance, and government access request handling. If any answer is unclear, risk is being accepted implicitly.
- Prefer EU-incorporated providers with no US corporate nexus for regulated data processing. Where US-nexus providers are necessary, require detailed jurisdictional analysis and enhanced contractual protections.
- Treat exit readiness as a sovereignty control. The ability to migrate away from a provider is what makes residual sovereignty risk manageable rather than structural.
The organizations that manage sovereignty risk effectively treat it as a structured procurement decision supported by technical and legal analysis, not as a checkbox on a vendor assessment form. The five-question framework above provides the structure. The discipline to demand evidence-backed answers provides the confidence that the procurement decision will hold under customer scrutiny, regulatory examination, and the evolving EU-US data governance landscape.