Summary Under the proposed Cloud and AI Development Act (CADA), European banks relying on US hyperscalers face escalating sovereignty and operational continuity risks, particularly for high-criticality functions. While CADA does not yet impose a direct mandate on private entities to procure specific assurance levels, Article 31 explicitly empowers entities in sectors of high criticality (including financial institutions under the NIS2 Directive) to conduct impact assessments mirroring public sector risk assessments. These assessments must evaluate exposure to third-country laws, such as the US CLOUD Act, which can compel data disclosure or service disruption. Crucially, Article 18 establishes a narrow, conditional pathway for third-country providers to qualify for Union Assurance Level 3, requiring six cumulative criteria including equivalent public procurement accessβ€”a high bar for US providers. Consequently, banks must align their cloud strategies with CADA's sovereignty framework (Article 16) and existing DORA due-diligence obligations to mitigate legal and operational risks, treating the current "voluntary" assessment under Article 31 as a forward-looking compliance imperative.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, represents a paradigm shift in how the EU regulates the infrastructure underpinning its digital economy. For European banks, the reliance on US hyperscalers introduces specific, quantifiable risks that CADA seeks to address through a harmonised sovereignty framework and demand-side measures. Unlike the AI Act, which regulates the software logic of AI systems, CADA targets the cloud infrastructure, data-centre location, and provider ownership structures.

Sovereignty Rationale and Third-Country Access Concerns

The core rationale for CADA's sovereignty framework is explicitly articulated in Recital 64 of the proposal. The text highlights that dependence on cloud computing service providers subject to third-country control creates systemic vulnerabilities. Recital 64 states that such dependence may lead to risks such as "misuse (i.e. manipulation, remote access and control, sabotage, weaponisation), access to information (i.e. access to sensitive information, unauthorised communication, technology leakage, data manipulation or exfiltration, espionage) and dependency vulnerabilities (i.e. political and/or economic coercion, for example by using vendor or technology lock-ins, embargos or sanctions, monopoly pricing damaging the financial interest of the Union and Member States)."

Specifically, the proposal addresses the extraterritorial reach of third-country laws. The US CLOUD Act, for instance, mandates that US-based providers disclose data regardless of its physical location, creating a direct conflict with EU data protection principles and the operational autonomy CADA seeks to guarantee. CADA aims to mitigate these risks by establishing a framework where critical data and services remain under the effective supervision of EU authorities, ensuring that service continuity cannot be unilaterally disrupted by third-country actors.

Assurance Levels and Foreign-Law Exposure

CADA introduces a Union cloud computing sovereignty framework consisting of four assurance levels (Article 16). These levels define the cumulative criteria cloud computing services must meet to be recognised as providing a specific level of Union assurance. The criteria are designed to address foreign-law exposure by requiring providers to demonstrate that they are not subject to third-country control that could compromise service continuity or data confidentiality.

  • Union Assurance Level 1: This is the baseline. It requires the provider to be established in the Union, with infrastructure and data remaining exclusively within the Union unless the public sector body explicitly requires otherwise. It also mandates transparency regarding subcontractors and guarantees that no existing laws in a third country require the provider to report software vulnerabilities to third-country authorities prior to exploitation.
  • Union Assurance Levels 2, 3, and 4: These higher levels impose stricter requirements, including independent third-party audits (Article 20), European cybersecurity certification, and, for Levels 3 and 4, requirements that personnel be Union citizens and that the provider and subcontractors not be subject to third-country control.
    • Level 2: Requires a European cybersecurity certificate of at least assurance level 'substantial' (Annex II, 2.1(e)).
    • Level 3: Requires a 'substantial' certificate and, crucially, allows for a derogation where a provider subject to third-country control may still qualify if the Commission adopts an implementing act under Article 18.
    • Level 4: The highest tier, requiring a European cybersecurity certificate of at least assurance level 'high' (Annex II, 4.1(e)) and a strict prohibition on third-country control over the design, development, and evolution of software components.

These assurance levels are designed to ensure that cloud services used for critical functions are resilient to foreign-law interference. The distinction between 'substantial' (Levels 2 and 3) and 'high' (Level 4) cybersecurity certification is a key differentiator in the risk profile.

The Article 18 Derogation: A High Bar for US Providers

A critical mechanism for US hyperscalers to participate in the sovereign cloud market is Article 18, titled "Associated third countries." This article allows the Commission to adopt implementing acts identifying third countries where cloud computing service providers subject to that country's control may be audited against the criteria for Union Assurance Level 3.

However, the path to qualification is narrow. Article 18(1) requires the third country to fulfill six cumulative criteria:

  1. It is subject to a relevant adequacy decision under Article 45 of the GDPR (18(1)(a)).
  2. It has no measures enabling control over the provider that conflicts with lawful access rules under Article 32 of the Data Act (Regulation (EU) 2023/2854) (18(1)(b)).
  3. It has no measures to compel service degradation, disruption, or compliance with restrictive measures (sanctions/embargoes) unless legitimate under EU law (18(1)(c)).
  4. It has no measures to impede the provision of state-of-the-art technologies (18(1)(d)).
  5. It maintains an open market to Union cloud computing services (18(1)(e)).
  6. It grants equivalent levels of access to public procurement procedures of cloud computing services subject to the control of a Union Member State or entity (18(1)(f)).

The omission of criteria (e) and (f) in previous analyses is significant. The requirement for "equivalent access to public procurement" is a major hurdle for US providers, as the US market does not currently offer reciprocal access to its government cloud procurement to EU entities on an equivalent basis. Until such an implementing act is adopted, US providers generally cannot qualify for Level 3, effectively limiting them to Level 1 or Level 2 (if they can meet the 'substantial' certification and other criteria without the third-country control derogation).

Obligations for Financial Sector Entities: Article 31

While CADA's mandatory procurement requirements for specific assurance levels primarily apply to public sector bodies (Article 30), private sector entities in sectors of high criticality, such as financial institutions, are not exempt from its influence. Article 31 explicitly addresses private sector entities referred to in Annex I of Directive (EU) 2022/2555 (NIS2), which includes financial institutions.

Article 31(1) states that these entities "may carry out similar assessments as those set out in Article 29." Article 29 requires public sector bodies to conduct risk assessments to determine the appropriate Union assurance level for their cloud computing services based on the sensitivity and criticality of the data and the impact on public order. For banks, this means they should conduct impact assessments to evaluate their exposure to third-country laws and service disruption risks.

Crucially, Article 31(3) empowers the Commission to adopt delegated acts specifying the need for impact assessments and risk mitigation measures for private sector entities operating in sectors of high criticality if specific circumstances warrant it. While the current text uses the permissive "may," the existence of this delegated power creates a regulatory expectation. Banks should not treat this as a purely voluntary option but as a forward-looking compliance requirement. The risk of future mandatory assessment is high, given the systemic importance of the financial sector.

Overlap with DORA and the Data Act

European banks are already subject to the Digital Operational Resilience Act (DORA), which imposes strict due-diligence obligations on third-party cloud service providers. DORA requires financial entities to assess and manage ICT risks, including those arising from cloud services. CADA complements DORA by providing a harmonised sovereignty framework that addresses non-technical risks, such as geopolitical dependencies and third-country law exposure, which DORA does not explicitly cover.

The Explanatory Memorandum (Section 1, "Consistency with existing policy provisions") clarifies that CADA is consistent with the Data Act, which focuses on switching and interoperability. The Data Act is an enabler for CADA, allowing users to switch providers, but it does not build the road towards a sovereign EU cloud sector. CADA fills this gap.

The combination of DORA and CADA means that banks must not only ensure the technical resilience and security of their cloud providers but also evaluate their sovereignty profile. Using a US hyperscaler without assessing its compliance with CADA's assurance criteria could lead to failures in both DORA due-diligence requirements (regarding operational continuity and third-party risk) and CADA's expected risk mitigation measures.

What this means for you

For in-house counsel and compliance officers at European banks, CADA introduces a new layer of regulatory scrutiny regarding cloud provider selection and management.

  1. Conduct Sovereignty Risk Assessments Immediately: Although Article 31(1) currently uses "may," the strategic imperative is clear. Initiate internal assessments to determine the sovereignty risks associated with your current cloud providers, particularly US hyperscalers. Evaluate exposure to third-country laws like the CLOUD Act and assess the potential for service disruption. Document these assessments as part of your DORA risk management framework.
  2. Map Cloud Services to Assurance Levels: Understand the criteria for Union Assurance Levels 1-4 (Article 16). If your bank processes high-criticality data, consider whether your current providers can meet the requirements for higher assurance levels. Note that Level 3 requires a specific Commission implementing act under Article 18, which is not yet in place for the US. If not, explore multi-cloud strategies or sovereign cloud alternatives that comply with CADA's criteria.
  3. Integrate CADA into DORA Compliance: Update your DORA due-diligence frameworks to include CADA's sovereignty criteria. Ensure that your cloud provider contracts address third-country law exposure, service continuity, and data confidentiality in line with CADA's expectations. The "operational autonomy" requirement in CADA is a new dimension for DORA risk assessments.
  4. Monitor Regulatory Developments: CADA is a proposal, and its final text may change. Stay informed about the Commission's potential delegated acts under Article 31(3), which could mandate specific impact assessments and mitigation measures for financial entities. The "may" in the current text is a placeholder for future mandatory obligations.
  5. Prepare for Audits and Reporting: If the Commission mandates impact assessments, you may need to report your findings and mitigation strategies. Ensure your internal processes can document and evidence your sovereignty risk management efforts.

Common misconceptions

  • Misconception: CADA only applies to public sector bodies.
    • Reality: While mandatory procurement requirements for specific assurance levels apply to public sector bodies (Article 30), Article 31 explicitly addresses private sector entities in sectors of high criticality, including financial institutions. These entities are encouraged to conduct similar risk assessments and may be subject to mandated impact assessments via delegated acts under Article 31(3).
  • Misconception: US hyperscalers are banned under CADA.
    • Reality: CADA does not ban US hyperscalers. However, it establishes a framework where services controlled by third-country entities may face restrictions or additional scrutiny, particularly for high-assurance levels. US providers can potentially qualify for Union Assurance Level 3 if the Commission determines the third country provides sufficient safeguards under Article 18, but this requires six cumulative criteria, including equivalent public procurement access, which is currently a significant hurdle.
  • Misconception: DORA covers all cloud risks, so CADA is redundant.
    • Reality: DORA focuses on technical cybersecurity and operational resilience. CADA addresses non-technical sovereignty risks, such as geopolitical dependencies and third-country law exposure. The two regulations are complementary, and banks must comply with both to ensure comprehensive risk management. The Data Act further complements this by enabling switching, but CADA provides the sovereignty framework.
  • Misconception: Assurance Level 1 is sufficient for all banking operations.
    • Reality: Assurance Level 1 is the minimum requirement for public sector bodies not involved in public order preservation (Article 30(2)). For banks processing high-criticality data, higher assurance levels (2, 3, or 4) may be necessary to adequately mitigate sovereignty risks, as determined by their internal impact assessments under Article 31. The "public order" relevance of financial stability often pushes banks toward higher assurance levels.
  • Misconception: The AI Act covers the same ground as CADA.
    • Reality: The AI Act regulates the AI system itself, not the cloud infrastructure. Recital 10 of CADA clarifies that the definition of "cloud computing service" encompasses the delivery of AI systems but explicitly excludes the "AI system itself and its underlying model." CADA governs the sovereign cloud beneath the AI layer.

Official sources

Related

This is general information about a draft EU regulation, not legal advice.