EU CADA: Enterprise Sovereignty Compliance for Cloud AI

Authors: Cloud Security Alliance AI Safety Initiative
Published: 2026-06-06

Categories: Cloud Security, Regulatory Compliance, AI Governance, Data Sovereignty

EU CADA: Enterprise Sovereignty Compliance for Cloud AI

Key Takeaways

The European Commission’s Cloud and AI Development Act (CADA), formally proposed on June 3, 2026, introduces the first EU-wide, four-tier sovereignty assurance framework for cloud and AI services, unifying into a single legislative instrument what had previously been fragmented across national sovereign cloud programs and sector-specific regulatory obligations. While CADA is not yet law, its four-tier assurance model codifies procurement expectations already forming in regulated industries, and enterprises with EU public sector contracting exposure or those subject to DORA, NIS2, or EU AI Act obligations cannot afford to wait for trilogue resolution to begin positioning work.

  • On June 3, 2026, the European Commission adopted a legislative proposal for the Cloud and AI Development Act (CADA) as the centerpiece of its European Technological Sovereignty Package, establishing a four-level Union Assurance framework governing which cloud and AI services may handle sensitive public sector and critical infrastructure workloads [1][4].
  • The four assurance levels escalate from data residency requirements (Level 1) through supply-chain independence from third countries (Level 2), to EU-domiciled ownership and control (Level 3), to complete supply-chain transparency with no third-country interference whatsoever (Level 4), which is the baseline required for defense sector workloads [2][7].
  • CADA is a proposal, not current law. The trilogue process between the Commission, Parliament, and Council typically runs twelve to thirty-six months for complex digital legislation; however, the proposal’s four-level framework is already shaping procurement expectations in public sector contracting and regulated industry supply chains regardless of its final legislative form [3][9].
  • The proposal explicitly targets exposure to extraterritorial legislation—most directly, the US CLOUD Act of 2018—as a sovereignty risk that the assurance framework is designed to assess and mitigate, creating a documented compliance tension for US-domiciled cloud and AI providers serving EU public sector customers [2][8].
  • Enterprises in financial services, healthcare, energy, and critical infrastructure that are already subject to DORA, NIS2, and the EU AI Act face de facto Level 2 or higher sovereignty expectations from those existing obligations; CADA does not create new requirements so much as it codifies and formalizes what these sectors are already building toward [1][6].
  • CADA proposes an “open source-first” principle for public procurement of cloud and AI software, which carries direct security governance implications: open-source supply chain risk management, software bill of materials (SBOM) practices, and model provenance verification would, if implemented as proposed, become procurement evaluation criteria—effectively raising them from best practices to contract requirements for vendors operating in EU public sector markets [10].

Background

The Cloud and AI Development Act did not emerge from a vacuum. For nearly a decade, European policymakers have watched the continent’s cloud infrastructure become dominated by providers headquartered outside the EU and subject to the legal jurisdiction of third countries. US-domiciled hyperscalers—primarily Amazon Web Services, Microsoft Azure, and Google Cloud—hold a substantial majority of the EU cloud market by most analyst estimates [4][8], while European providers have not reversed their declining collective market share since 2017. Successive digital strategy initiatives—the European Union Cloud Services (EUCS) certification scheme, the GAIA-X initiative, and various national sovereign cloud programs—have so far not reversed this concentration at scale. The Commission’s accompanying impact assessment attributes this persistence to fragmented national approaches and the absence of a single EU-wide sovereignty assessment standard—a characterization that EUCS and GAIA-X stakeholders may contest, given that both programs remain active [4].

The structural problem motivating CADA goes beyond economics. When a cloud provider is headquartered in a third country, it is subject to that country’s laws regarding data access, national security orders, and export controls. The US Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018 (18 U.S.C. § 2713) requires US-domiciled companies to preserve and disclose data held anywhere in the world in response to valid US legal process—a warrant or equivalent order—regardless of physical location or contractual data-protection terms [15]. While providers may challenge requests that conflict with foreign law through comity motions under 18 U.S.C. § 2703(h), and bilateral executive agreements under the CLOUD Act can modify default jurisdiction rules in countries that have concluded such arrangements with the United States, no US-EU CLOUD Act executive agreement is currently in force. This leaves the legal tension unresolved for EU organizations whose GDPR obligations require protection of personal data from unlawful third-country access while their cloud infrastructure operates on platforms legally compellable by foreign governments. The tension became publicly concrete on June 18, 2025, when Microsoft France’s legal director, Anton Carniaux, testified before a French Senate inquiry into public procurement and digital sovereignty that Microsoft could not guarantee data stored by French public-sector customers in French data center regions would never be transferred to US authorities without French government consent [5].

The Commission’s response, following a public consultation period that closed in July 2025, was CADA—positioned in its preamble as the regulatory endpoint of what it describes as a decade-long sovereignty architecture that began with GDPR and now extends into cloud infrastructure, public procurement, and AI service delivery. The act was adopted on June 3, 2026, as part of a broader European Technological Sovereignty Package that also includes a revised Chips Act, open-source investment provisions, and accelerated data-center permitting measures [4]. The Commission’s stated infrastructure target—tripling EU data-center capacity within five to seven years, supported by an estimated €200 billion in primarily private investment, sufficient to meet the needs of European businesses and public administrations by 2035—reflects the scale of structural change the package envisions [14].

Security Analysis

The Four-Tier Assurance Framework: A Compliance Architecture

The most operationally significant element of CADA is its Union Assurance framework, which establishes four levels of sovereignty-based assessment criteria for cloud and AI services. Unlike binary certification schemes—which either grant or deny approval for a given service—the four-level structure allows public sector bodies to match the sovereignty requirements of a workload to the sensitivity of the data and function involved, rather than applying blanket requirements across all deployments.

Level 1 is the baseline: cloud and AI services must store and process data within EU-located infrastructure. This requirement is already standard practice for EU-regulated personal data and represents the minimum bar for general public sector use. Level 2 adds substantive obligations beyond data residency. Providers must demonstrate independence from third-country legal jurisdiction and provide transparency over their software supply chains—requirements that directly address the CLOUD Act exposure that Level 1’s geographic constraints cannot resolve. A provider might operate data centers in Frankfurt while remaining legally compelled by US government order to disclose data stored there; Level 2 requires the provider to demonstrate that this compulsion either does not apply or has been contractually and structurally mitigated. Level 3 requires providers to be owned and controlled within the EU and to meet additional criteria that the proposal indicates may include personnel citizenship requirements—a threshold that, as written, would exclude US-domiciled hyperscalers operating through their parent corporate structures. Whether separately domiciled EU subsidiaries with locally incorporated governance could satisfy the ownership and control criteria remains a legal question that implementing acts or Commission guidance will need to address. Level 4, reserved for defense and national security workloads, mandates complete transparency and control over the software supply chain with zero interference from any third country, making it the most restrictive tier and effectively requiring fully EU-sovereign provider relationships [2][7].

For enterprise security professionals, this framework does something important: it translates a geopolitical risk question—how exposed is this vendor to foreign government compulsion?—into a structured, evaluable compliance criterion with documented levels and criteria. Enterprises that supply to public sector bodies, operate in defense subcontracting, or provide critical infrastructure services should anticipate that their cloud and AI provider relationships will be assessed through this lens in procurement and audit processes, even before CADA becomes binding law. Germany’s BSI C5 sovereign cloud assurance criteria and France’s SecNumCloud qualification framework, both predating CADA, use structurally similar assurance logic—requiring data residency, operator independence from third-country law, and supply-chain transparency at progressive levels [16][17]. The four-level CADA model reflects procurement expectations already operationalized at the national level rather than representing an entirely new requirement.

Convergence with Existing Regulatory Obligations

The Commission characterizes CADA as codifying rather than creating obligations—a position that, if accurate, simplifies compliance planning considerably. Industry critics, including the Computer & Communications Industry Association, dispute this framing, arguing that CADA introduces discriminatory new obligations not present in existing EU law and risks severe market fragmentation [12]. For practical planning purposes, however, the convergence with DORA and NIS2 requirements is nonetheless real: enterprises in regulated sectors can draw directly on their existing compliance evidence for a significant portion of CADA’s assurance criteria, and treating CADA’s four-level framework as an extension of existing obligations rather than an entirely new regulatory layer is a defensible and efficient approach.

The Digital Operational Resilience Act (DORA), applicable from January 17, 2025 [23], requires financial services firms to maintain ICT third-party risk management programs encompassing concentration risk assessment, exit strategy planning, and in some cases supervisory access to audit ICT service providers. The concentration risk provisions specifically target dependence on systemically important third-party providers—a category that effectively describes the major US hyperscalers given their market share. NIS2, effective October 2024 for essential and important entities across energy, transport, banking, healthcare, digital infrastructure, and public administration, mandates supply-chain security risk assessments for technology vendor relationships that map directly onto CADA’s supply-chain transparency criteria at Level 2. The EU AI Act, whose high-risk AI obligations for Annex III systems activate August 2, 2026, establishes risk management system requirements for high-risk AI providers under Article 9 that are broad enough that competent authorities may reasonably interpret infrastructure jurisdiction—and associated extraterritorial access risk—as a required component of the compliance evidence base for providers deploying AI in consequential contexts, including biometric identification, critical infrastructure management, employment screening, and credit decisioning [13]. Organizations should seek legal counsel on whether their specific supervisory authority interprets Article 9’s requirements this way. Taken together, these three frameworks already require financial sector firms, critical infrastructure operators, and high-risk AI deployers to document provider legal jurisdiction, supply-chain control, and extraterritorial legal exposure as part of their compliance evidence. CADA’s Level 2 criteria map precisely onto what these organizations should already be building.

The convergence creates both compliance efficiency and timeline complexity that security teams must manage simultaneously. The efficiency gain is that organizations with mature DORA or NIS2 compliance programs are already producing evidence directly relevant to CADA’s assurance levels, and may need relatively modest additional effort to align their vendor assessment methodology to the CADA framework’s specific criteria. The complexity arises from the interaction of legislative timelines: DORA and NIS2 are operative law with active enforcement, the EU AI Act’s high-risk provisions activate in two months, and CADA is a proposal that will not be binding for at least twelve months after trilogue concludes—and potentially considerably longer. Security teams must manage compliance evidence for regulations at different stages of the legislative cycle simultaneously, using CADA as a directional signal rather than a mandatory standard while treating its predecessor frameworks as operative obligations with immediate enforcement consequences.

Open-Source Mandate and Cloud AI Supply Chain Risk

CADA introduces an “open source-first” principle for public procurement of cloud and AI software, articulating what the proposal describes as a “public money, public code” logic under which software developed or procured by public administrations should, where technically feasible and secure, be available as open-source code [10]. The mandate reflects a coherent EU policy argument: open-source software allows public bodies to audit code, avoid vendor lock-in, and maintain supply-chain transparency that is structurally easier to demonstrate than in proprietary systems—all of which are sovereignty concerns that CADA’s assurance framework is designed to address.

The security implications of this mandate are not straightforward, and enterprise security teams operating in or supplying to public sector markets need to engage with them carefully. Open-source-first procurement does not mean all-open-source procurement; the proposal includes feasibility and security carve-outs that allow proprietary components where open alternatives are inadequate. However, vendors responding to EU public sector procurement will increasingly be evaluated on their ability to offer open-source components, provide SBOM documentation, and demonstrate supply-chain transparency in ways that auditors can independently verify without proprietary access restrictions.

For cloud AI specifically, the open-source mandate intersects with a supply chain security challenge that has grown significantly over 2025 and 2026: the compromise of open-source AI model repositories, package registries, and dependency chains as a vector for supply-chain attack, a threat trend documented across multiple ENISA threat landscape assessments [18]. Organizations moving toward open-source AI components to satisfy CADA’s procurement preferences must simultaneously mature their SBOM practices, model provenance verification, and dependency monitoring to avoid trading vendor lock-in risk for attack surface expansion. A dependency on an open-source foundation model with unverified provenance or unmonitored update channels carries different but comparably serious risks to dependence on a US-headquartered proprietary provider subject to CLOUD Act compulsion. The mandate thus creates compliance value in one dimension and introduces supply chain risk in another, and the most defensible posture is to treat SBOM documentation and model provenance controls as prerequisites for any open-source AI adoption undertaken in response to CADA’s procurement principles.

Recommendations

Immediate Actions

Enterprise security and compliance teams should initiate a cloud AI sovereignty assessment immediately, mapping current cloud and AI provider relationships to CADA’s four assurance levels using the framework’s published criteria. This assessment is most urgent for organizations in financial services, healthcare, defense subcontracting, and critical infrastructure, where Level 2-or-above sovereign cloud posture is already implied by DORA, NIS2, and EU AI Act obligations currently in effect. The assessment should document each major cloud and AI provider’s headquarters jurisdiction, applicable extraterritorial laws, available contractual sovereignty commitments, and the provider’s self-declared assurance level against CADA criteria, treating CLOUD Act exposure as a risk requiring explicit documentation in vendor risk registers rather than a theoretical concern.

Security teams should simultaneously review their AI inventories for EU AI Act Annex III scope. For any AI system categorized as high-risk—biometric identification, critical infrastructure management, employment screening, credit decisioning—the infrastructure provider’s sovereignty level is a component of the risk management documentation required under Article 9 before those obligations take effect on August 2, 2026. Organizations that have not yet linked their AI system inventory to cloud infrastructure assessments face a gap likely to be scrutinized in regulatory reviews as EU AI Act high-risk obligations take effect.

Short-Term Mitigations

Over the next three to six months, organizations with significant public sector contracting exposure should engage procurement, legal, and security teams in a formal CADA readiness review, treating the proposal’s assurance levels as prospective procurement requirements even though they are not yet binding. Public sector contracts renewing during the trilogue window may contain sovereignty-related terms that reference the CADA framework or its national predecessors, and organizations that can demonstrate alignment to Level 2 criteria will be meaningfully better positioned in these processes. Legal teams should pay particular attention to whether existing cloud and AI contracts contain provisions governing third-country access requests, audit rights over software supply chains, and exit and data portability obligations—CADA’s framework will inform how regulators and procurement bodies read these provisions.

For cloud AI vendors and system integrators, CADA’s open-source mandate warrants early engagement with SBOM tooling and model provenance practices. Vendors that can demonstrate transparent software supply chains through SBOM documentation, code signing, and model provenance attestation will satisfy sovereignty-adjacent requirements already appearing in EU public sector RFPs independent of CADA’s legislative status. Beginning this work now rather than after final publication substantially reduces the compliance runway required at adoption.

Strategic Considerations

The CADA proposal reflects a sustained EU policy trajectory toward formal sovereignty assessment, one that has been building across successive digital strategy initiatives since GDPR. While specific provisions may be modified in trilogue—and informed observers have questioned whether CADA will succeed in reversing EU cloud market concentration where prior initiatives have not [11]—the directional commitment to sovereignty-based cloud procurement criteria appears structurally embedded in EU digital policy. Boards and senior leadership teams at enterprises with significant EU public sector or regulated industry exposure should be briefed on CADA’s market implications as a strategic planning input, not merely a compliance tracking item.

Organizations currently operating under a single cloud strategy for all EU workloads should evaluate whether a hybrid or multi-cloud architecture that places sovereignty-sensitive workloads on Level 2-or-above capable infrastructure—while retaining flexibility for commercial applications—would reduce prospective compliance exposure. This architectural decision carries significant operational, cost, and security engineering implications, and the time to model it is during the twelve-to-thirty-six-month trilogue window rather than in response to a finalized regulation with a compressed compliance deadline. The historical precedent from GDPR, which prompted significant late-stage architectural rework for organizations that waited for finalization to begin planning, is instructive.

CSA Resource Alignment

CSA publishes the AICM, CCM, STAR for AI, and MAESTRO frameworks referenced throughout this section. Organizations should evaluate these alongside other established assurance frameworks, including Germany’s BSI C5 [16], France’s SecNumCloud [17], the EUCS certification scheme, and ISO/IEC 27001 with cloud security extensions.

CADA’s four-tier assurance framework maps directly onto several existing CSA frameworks that provide implementation structure for the sovereignty requirements it introduces, and enterprise teams can accelerate their readiness programs by incorporating CSA’s published guidance into the control vocabulary for CADA compliance preparation.

The AI Controls Matrix (AICM), which addresses supply-chain transparency, model provenance, infrastructure jurisdiction, and third-party AI risk across eighteen control domains, covers compliance obligations that CADA’s Level 2 and Level 3 assurance criteria imply [19]. Organizations building CADA-readiness programs should evaluate the AICM as a control mapping reference, since it integrates AI-specific obligations with cloud security controls in a unified framework applicable to providers across all layers of the AI deployment stack: cloud service providers, model providers, application providers, and AI customers.

The Cloud Controls Matrix (CCM), which provides a structured control vocabulary for infrastructure-layer compliance that maps to ISO/IEC 27001, SOC 2, and other established audit standards [20], covers supply chain management and infrastructure security domains that address data residency, multi-jurisdictional risk, and provider auditing requirements. These translate directly into CADA Level 1 and Level 2 assessment evidence. Organizations with existing CCM-based compliance programs have a direct path to incorporating CADA sovereignty criteria without building a parallel evidence structure.

STAR for AI, CSA’s third-party assurance program for AI systems, provides a structured vehicle for demonstrating sovereignty-relevant compliance to customers, regulators, and procurement counterparties [21]. As CADA’s assurance framework matures toward a formal certification scheme during the trilogue process, STAR for AI assessments—particularly those addressing infrastructure jurisdiction, supply-chain control, and extraterritorial legal exposure—provide the kind of structured, independently validated compliance evidence that public sector procurement bodies will require. Organizations seeking to credibly claim Level 2 assurance to EU public sector customers should consider aligning their STAR for AI assessment scope to include the sovereignty criteria CADA formalizes.

The MAESTRO threat modeling framework, CSA’s AI Safety Initiative tool for agentic AI system risk characterization, provides a complementary lens for cloud AI deployments operating under sovereignty constraints [22]. Multi-cloud and hybrid architectures, which many organizations will adopt to satisfy different sovereignty levels across their workload portfolio, introduce complex cross-boundary orchestration patterns that MAESTRO helps characterize and assess. Security teams designing sovereign-compliant AI architectures should apply MAESTRO’s threat model to the boundary conditions between sovereignty levels—for example, where an agentic AI system spans Level 1 infrastructure for general compute and Level 3 infrastructure for sensitive model hosting—to identify data exfiltration paths, jurisdiction-crossing agent behaviors, and trust boundary violations that sovereignty separation is meant to prevent.

References

[1] European Commission. “Cloud and AI Development Act.” Digital Strategy, European Commission, 2026.

[2] European Commission. “Proposal for the Cloud and AI Development Act (CADA).” Digital Strategy Library, European Commission, June 3, 2026.

[3] European Parliament. “Cloud and AI Development Act — Legislative Train Schedule.” European Parliament Legislative Train, 2026.

[4] European Commission. “Commission Proposes Tech Sovereignty Package to Strengthen Europe’s Digital Autonomy and Resilience.” Press Corner, European Commission, June 3, 2026.

[5] The Register. “Microsoft Admits It Cannot Guarantee French Government Data Will Stay in France.” The Register, July 25, 2025.

[6] Wilson Sonsini. “European Commission Publishes Proposal for Act to Reduce Reliance on Foreign Cloud and AI.” Wilson Sonsini Goodrich & Rosati, June 2026.

[7] Grosswald. “European Commission Tables Cloud and AI Development Act, Ring-Fencing Defence Procurement.” Grosswald, June 2026.

[8] Tech Jacks Solutions. “EU Proposes Cloud and AI Development Act: What CADA’s Sovereignty Framework Means for US Providers in Public Sector.” Tech Jacks Solutions, June 2026.

[9] European Parliament Research Service. “Cloud and AI Development Act — EPRS Briefing.” European Parliament Research Service, 2025.

[10] SUSE Communities. “The EU Cloud and AI Development Act: What It Gets Right, and What It Still Needs.” SUSE Communities, June 2026.

[11] Julien Simon. “The EU Cloud and AI Development Act (CADA): A Last Shot at Cloud Sovereignty, or Another Expensive Debacle?.” Medium, February 2026.

[12] Computer & Communications Industry Association. “Discriminatory EU Cloud and AI Development Act Risks Severe Market Fragmentation.” CCIA, June 3, 2026.

[13] European Parliament. “EU AI Act: First Regulation on Artificial Intelligence.” European Parliament Topics, 2024.

[14] Fierce Network. “Sovereignty Plays Starring Role in EU Plan to Triple Data Center Capacity.” Fierce Network, June 2026.

[15] US Congress. “Clarifying Lawful Overseas Use of Data Act (CLOUD Act), S.2383, 115th Congress.” Congress.gov, enacted March 23, 2018.

[16] Bundesamt für Sicherheit in der Informationstechnik. “Cloud Computing Compliance Criteria Catalogue (C5).” Federal Office for Information Security (BSI), Germany, 2020.

[17] Agence nationale de la sécurité des systèmes d’information. “SecNumCloud Qualification Scheme.” ANSSI, France, 2022.

[18] European Union Agency for Cybersecurity. “ENISA Threat Landscape 2025.” ENISA, October 2025.

[19] Cloud Security Alliance. “AI Controls Matrix (AICM).” Cloud Security Alliance, 2025.

[20] Cloud Security Alliance. “Cloud Controls Matrix (CCM).” Cloud Security Alliance, 2024.

[21] Cloud Security Alliance. “STAR for AI.” Cloud Security Alliance, 2025.

[22] Cloud Security Alliance. “MAESTRO: Multi-Agent Environment Security Threat Reasoning and Orchestration.” Cloud Security Alliance AI Safety Initiative, 2024.

[23] Official Journal of the European Union. “Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector (DORA).” EUR-Lex, 2022.

← Back to Research Index