Summary The proposed Cloud and AI Development Act (CADA) complements rather than replaces the Digital Operational Resilience Act (DORA) for cloud computing service providers (CSPs). While DORA imposes strict technical cybersecurity and operational resilience obligations on CSPs serving financial entities, CADA introduces a horizontal sovereignty framework requiring public sector bodies and critical private entities to procure cloud services that meet specific "Union assurance levels." CSPs must therefore navigate two parallel regimes: DORA's sector-specific ICT risk management duties and CADA's broader requirements for data localization, personnel citizenship, and third-country control assessments. As proposed, CADA would fill "long-standing gaps in sovereignty and non-technical risks" that DORA does not address.
Detail
The European Commission's proposal for the Cloud and AI Development Act (CADA), COM(2026) 502 final, explicitly positions itself as a complement to existing EU digital legislation, including the Digital Operational Resilience Act (DORA). Understanding the interaction between these two instruments is critical for CSPs operating in the EU, particularly those serving both financial institutions and public sector bodies. The distinction lies in their scope: DORA is a sectoral instrument focused on technical resilience, while CADA is a horizontal instrument focused on strategic autonomy and sovereignty.
DORA's Sectoral Scope: Technical Resilience
As noted in the CADA explanatory memorandum, the Digital Operational Resilience Act (DORA) "shapes compliance obligations for cloud computing service providers" but has a distinct, sectoral scope. The memorandum clarifies that DORA "indirectly covers cloud computing service providers if they provide services to specified financial entities or if their role is significant enough in terms of operational resilience." Specifically, DORA targets "critical third-party service providers" in the financial sector.
Under DORA, these CSPs must:
- Implement robust ICT risk management frameworks.
- Conduct regular incident response testing.
- Allow for direct oversight and access by EU financial supervisory authorities.
However, the CADA proposal clarifies that DORA "does not contain measures to boost the uptake and use of such services and is fully focused on technical cybersecurity as opposed to broader sovereignty considerations." DORA ensures that financial systems remain operational and secure against cyber threats, but it does not mandate that the underlying cloud infrastructure be sovereign, EU-controlled, or free from third-country legal extraterritorial reach.
The CADA explanatory memorandum explicitly states that the proposal "supports the objectives of the Digital Operational Resilience Act (DORA)." It notes that DORA "shapes compliance obligations for cloud computing service providers" and "indirectly covers cloud computing service providers if they provide services to specified financial entities or if their role is significant enough in terms of operational resilience." Crucially, the memorandum adds that DORA "has a sectoral scope and is specific to the financial sector." It further explains that while DORA requires financial institutions to carry out due diligence on their cloud providers, it "does not contain measures to boost the uptake and use of such services and is fully focused on technical cybersecurity as opposed to broader sovereignty considerations."
CADA's Horizontal Scope: Sovereignty and Assurance Levels
In contrast, CADA establishes a "Union cloud computing sovereignty framework" designed to mitigate strategic dependencies on non-European providers. This framework applies horizontally across the public sector and, by extension, to private sector entities operating in critical sectors.
CADA introduces four "Union assurance levels" (Levels 1–4), each with cumulative criteria that CSPs must meet to be recognized. These criteria go beyond technical cybersecurity to address:
- Data Localization: Customer data must remain exclusively within the Union (with limited exceptions).
- Personnel Requirements: Higher assurance levels (3 and 4) may require personnel to be Union citizens or hold national security clearances.
- Third-Country Control: CSPs subject to the control of third-country entities must demonstrate effective legal, technical, and organizational separation to prevent unauthorized access or service disruption by foreign governments.
- Software Supply Chain: Requirements for Software Bills of Materials (SBOMs) and source code auditability.
The CADA explanatory memorandum emphasizes that "certification under the Cybersecurity Act can address technical cybersecurity criteria but is not suited for addressing sovereignty concerns that go beyond these technical elements." This distinction is central to the interaction with DORA: DORA (and the Cybersecurity Act) ensures the cloud is secure; CADA ensures the cloud is sovereign.
The Interaction: Parallel Obligations
For a CSP serving a financial entity that is also a public sector body (or a private entity in a critical sector under CADA Article 31), these obligations run in parallel.
- DORA Obligations: The CSP must comply with DORA's ICT risk management, incident reporting, and audit rights granted to financial supervisors. This is a condition of doing business with financial institutions.
- CADA Obligations: If the CSP wishes to serve public sector bodies or private entities in critical sectors (as defined in Annex I of the NIS2 Directive) that have determined a need for higher assurance, the CSP must undergo independent third-party audits to obtain a "positive" audit opinion for Union Assurance Levels 2, 3, or 4.
The CADA explanatory memorandum states that CADA "supports the objectives of DORA" but fills "long-standing gaps in sovereignty and non-technical risks." Certification under the Cybersecurity Act (which feeds into DORA compliance) addresses technical criteria but is "not suited for addressing sovereignty concerns that go beyond these technical elements."
Article 31: Private Sector Impact Assessments
A key bridge between the two regimes is CADA Article 31. While CADA's mandatory procurement rules (Article 30) apply strictly to public sector bodies, Article 31 allows private sector entities referred to in Annex I of the NIS2 Directive (which includes major financial institutions) to "carry out similar assessments as those set out in Article 29."
This means financial institutions, already subject to DORA, can voluntarily conduct impact assessments to determine if their cloud services need to meet higher CADA assurance levels to protect public order or critical operations. If they do, they will likely procure services that have already been recognized under CADA's framework. This creates a market incentive for CSPs to achieve CADA recognition even if they are not directly procured by the government, as their financial sector clients may demand it.
Article 31(1) states: "Entities referred to in Annex I of Directive (EU) 2022/2555 who are not public sector bodies may carry out similar assessments as those set out in Article 29." This provision explicitly links the private sector's critical infrastructure status (under NIS2) to the CADA sovereignty framework, allowing financial entities to apply the same risk-based logic used by public bodies to determine their required assurance level.
Penalties and Enforcement
The enforcement mechanisms differ:
- DORA: Penalties are imposed by national competent authorities responsible for financial supervision. Fines can be significant, based on the global turnover of the CSP.
- CADA: Member States must lay down rules on penalties for infringements of the sovereignty framework (Article 24). These penalties must be "effective, proportionate and dissuasive." Additionally, recipients of cloud services have the right to seek compensation from CSPs for damages suffered due to infringements of CADA obligations.
What this means for you
For in-house counsel and compliance officers at CSPs or financial institutions, the overlap between CADA and DORA requires a dual-track compliance strategy.
1. Map Your Client Base to Both Regimes
- If you serve financial entities: You are likely subject to DORA as a critical ICT third-party provider. Ensure your ICT risk management, incident reporting, and audit rights protocols are fully aligned with DORA's technical requirements.
- If you serve public sector bodies or critical private entities (NIS2): You must prepare for CADA's sovereignty requirements. You cannot rely solely on DORA compliance to meet public procurement requirements.
2. Prepare for Independent Audits
CADA requires independent third-party audits for Union Assurance Levels 2, 3, and 4 (Article 20). Unlike DORA's supervisory oversight, CADA mandates that you contract an independent auditing organization. You must be prepared to provide:
- Evidence of data localization (logs, network diagrams).
- Proof of personnel citizenship and security clearances (for Levels 3 and 4).
- Documentation of separation from third-country controllers (ownership structures, governance documents).
- Software Bills of Materials (SBOMs) and source code audit rights.
3. Leverage Article 31 for Financial Clients
Financial institutions are encouraged to use CADA Article 31 to conduct impact assessments. As a CSP, you should proactively offer CADA assurance level certifications to your financial clients. This demonstrates that your service not only meets DORA's technical resilience standards but also mitigates sovereignty risks, making you a more attractive partner in a landscape increasingly wary of third-country dependencies.
4. Monitor Delegated Acts
The specific criteria for Union Assurance Levels and the detailed rules for audits are to be defined in delegated and implementing acts. Stay alert for these secondary legislations, as they will provide the granular evidence requirements (Annex III) that your auditors will use.
Common misconceptions
Misconception 1: CADA replaces DORA for financial institutions. Reality: CADA does not replace DORA. DORA remains the primary regulation for ICT operational resilience in the financial sector. CADA adds a layer of sovereignty and trust requirements. A CSP serving a bank must comply with both if the bank requires sovereign cloud services.
Misconception 2: DORA compliance ensures CADA recognition. Reality: DORA focuses on technical cybersecurity and operational continuity. CADA's assurance levels include non-technical criteria such as data localization, personnel citizenship, and freedom from third-country control. A CSP can be DORA-compliant but fail to meet CADA Assurance Level 3 because its data is processed outside the EU or its parent company is subject to foreign national security laws.
Misconception 3: CADA only applies to government agencies. Reality: While mandatory procurement rules (Article 30) apply to public sector bodies, CADA Article 31 explicitly allows private sector entities in critical sectors (including finance) to conduct similar impact assessments. This creates a strong market pull for CADA-certified services across the critical infrastructure landscape, not just in government.
Misconception 4: The "sovereign cloud" concept is new and unrelated to existing security standards. Reality: CADA builds on existing frameworks like the European Cybersecurity Certification Scheme for Cloud Services (EUCS). However, CADA goes further by embedding sovereignty (control, data location, personnel) into the certification criteria, whereas EUCS and DORA focus primarily on technical security and resilience.
Official sources
Related
- How does CADA interact with NIS2 for telecom providers?
- How does CADA affect payment service providers?
- CADA vs the European Electronic Communications Code: How do they interact?
- How does CADA reduce research dependence on non-EU cloud providers?
- How does CADA affect hospitals and healthcare providers?
This is general information about a draft EU regulation, not legal advice.