Summary As proposed, the Cloud and AI Development Act (CADA) does not create a merged reporting channel with the NIS2 Directive or the Digital Operational Resilience Act (DORA). Instead, CADA introduces a distinct, sovereignty-focused reporting duty under Article 29, requiring Member States and Union entities to submit strategic risk-assessment results directly to the European Commission within three months of completion. These obligations are separate from NIS2's cybersecurity incident reporting and DORA's ICT third-party risk registers. Organizations and authorities must manage parallel compliance tracks: one for technical incidents (NIS2/DORA) and one for public-order sovereignty mapping (CADA).

Detail

The Cloud and AI Development Act (CADA), proposed in COM(2026) 502 final, establishes a framework to strengthen Europe's cloud and AI ecosystem by addressing sovereignty and public order risks. A critical component of this framework is the "Union cloud computing sovereignty framework," which relies on risk assessments to determine the appropriate "Union assurance level" (1–4) for public sector activities. Unlike existing digital resilience laws that focus primarily on technical cybersecurity incidents or financial operational continuity, CADA's reporting duties are designed to map public order risks to specific sovereignty levels.

CADA Article 29: The Sovereignty Risk Assessment Reporting Duty

The primary reporting obligation relevant to this question is found in Article 29 of the CADA proposal. This article mandates that Member States and Union entities carry out risk assessments to identify public sector activities using cloud computing services that contribute to the preservation of public order. These activities include sectors falling under Annex I or II of the NIS2 Directive, as well as areas of national security, internal security, external border management, defence, justice, or law enforcement.

Crucially, Article 29(4) imposes a strict deadline and a specific reporting destination for the results of these assessments. It states:

"Within three months of carrying out the risk assessments referred to in paragraph 1, Member States shall provide the Commission with the results of those risk assessments, indicating where they depart from the implementing acts referred to in paragraph 3."

This reporting duty is directed at the European Commission, not national supervisory authorities. The purpose is to ensure harmonized implementation across the Union and allow the Commission to review whether the identified Union assurance levels adequately address public order concerns. If the Commission concludes that a Member State's assessment is inappropriate, Article 29(5) grants the Commission the power to adopt implementing acts specifying the required Union assurance levels for those public sector activities.

Distinction from NIS2 Incident Reporting

The NIS2 Directive (Directive (EU) 2022/2555) focuses on cybersecurity risk management and incident reporting. Under NIS2, entities in essential and important sectors must report significant cybersecurity incidents to national Competent Authorities or Single Points of Contact (SPCs) within specific timeframes (e.g., an early warning within 24 hours, an incident notification within 72 hours, and a final statement within one month).

CADA's reporting under Article 29 differs fundamentally in three ways:

  1. Recipient: NIS2 reports go to national authorities; CADA risk assessment results go to the European Commission.
  2. Trigger: NIS2 reporting is triggered by a cybersecurity incident or a periodic review of risk management measures. CADA reporting is triggered by the completion of a strategic risk assessment determining the sovereignty level of cloud services used.
  3. Content: NIS2 reports detail the nature, duration, and impact of a cybersecurity breach. CADA reports detail the mapping of public sector activities to Union assurance levels (1–4) based on public order relevance.

While CADA references NIS2 sectors in Article 29(1) to define the scope of activities that may require higher assurance levels, it does not replace NIS2's operational incident reporting. An organization subject to NIS2 must continue to report cybersecurity incidents to its national authority under NIS2 rules, regardless of its CADA compliance status.

Distinction from DORA ICT Third-Party Risk Reporting

The Digital Operational Resilience Act (DORA) applies to the financial sector, imposing strict requirements on ICT third-party risk management. Under DORA, financial entities must maintain an ICT third-party risk management register and report material ICT-related incidents to their relevant competent authorities. DORA also introduces a register of critical ICT third-party service providers at the European level, managed by the European Supervisory Authorities (ESAs).

CADA's reporting duties do not merge with DORA's registers or incident reporting. Article 31 of CADA allows private sector entities within the meaning of NIS2 (which includes many financial entities) to conduct impact assessments similar to those in Article 29, but this is a voluntary or guidance-based mechanism rather than a mandatory centralized reporting channel like DORA's. Furthermore, CADA's focus is on the sovereignty and public order implications of cloud providers, whereas DORA focuses on operational resilience and financial stability. A financial institution must maintain its DORA ICT register and report incidents to its national financial supervisor, while also potentially engaging in CADA's risk assessment processes if it is a public sector body or if it chooses to conduct impact assessments under Article 31. There is no single "digital resilience" report that satisfies both regimes.

No Merged Reporting Channel

The CADA proposal explicitly avoids creating a unified reporting portal for all digital regulations. The financial statement accompanying the proposal indicates that the Commission will establish a central repository for recognized cloud computing services (Article 22) and will receive risk assessment results from Member States (Article 29). However, it does not propose a joint infrastructure with the ESAs (for DORA) or the ENISA-led mechanisms for NIS2. This means that compliance officers must prepare for distinct data collection, formatting, and submission processes for each regulation.

What this means for you

For in-house counsel and compliance officers, the separation of reporting duties implies a need for structured, parallel compliance workflows:

  1. Separate Calendars: Maintain distinct reporting calendars. CADA's Article 29 requires risk assessments to be carried out by the date of entry into force plus one year, and thereafter every two years. The results must be reported to the Commission within three months of completion. This is a strategic, periodic duty, unlike the event-driven nature of NIS2 incident reporting.
  2. Data Segregation: Ensure that data collected for CADA risk assessments (focusing on data sensitivity, public order relevance, and sovereignty levels) is not conflated with data collected for NIS2 incident logs (focusing on breach severity, duration, and affected users) or DORA ICT registers (focusing on contractual dependencies and financial materiality).
  3. Authority Identification: Identify the correct recipients for each report. CADA reports go to the European Commission. NIS2 reports go to national Competent Authorities. DORA reports go to national financial supervisors. Misdirecting these reports could lead to regulatory gaps.
  4. Resource Allocation: Budget for additional administrative costs. The CADA proposal notes that direct compliance costs will be borne by national and local public authorities and businesses. Since there is no merged channel, you cannot leverage a single reporting team to satisfy all three regimes; specialized expertise in sovereignty risk (CADA), cybersecurity incidents (NIS2), and financial operational resilience (DORA) is required.
  5. Public Sector Specifics: If you are a public sector body, Article 29 is mandatory. You must document your risk assessment methodology and be prepared to justify any departure from Commission guidance. Failure to report or providing inaccurate risk assessments could result in the Commission imposing specific assurance levels via implementing acts, potentially forcing costly cloud migrations.

Common misconceptions

Misconception 1: CADA replaces NIS2 or DORA reporting. Reality: CADA complements these acts but does not replace them. The explanatory memorandum states that CADA "complements EU's broader policy framework on cybersecurity and digital resilience." NIS2 remains the primary law for cybersecurity risk management and incident reporting, while DORA remains the primary law for financial ICT resilience. CADA adds a layer of sovereignty and public order risk assessment.

Misconception 2: There is a single EU portal for all digital risk reporting. Reality: As proposed, there is no single portal. CADA establishes a central repository for recognized cloud services (Article 22) and a process for Member States to report risk assessment results to the Commission (Article 29). NIS2 relies on national SPCs, and DORA relies on ESAs and national supervisors. These systems are not integrated in the current proposal.

Misconception 3: CADA reporting is only for cloud providers. Reality: Article 29 places the primary reporting obligation on Member States and Union entities (public sector). Private sector entities in critical sectors (NIS2 entities) may conduct impact assessments under Article 31, but this is not a mandatory reporting duty to the Commission in the same way. The reporting duty under Article 29(4) is specifically for public bodies to inform the Commission of their sovereignty risk mappings.

Misconception 4: CADA risk assessments are technical cybersecurity audits. Reality: CADA risk assessments under Article 29 are strategic evaluations of public order relevance. They determine whether a cloud service should be Union Assurance Level 1, 2, 3, or 4. They consider the sensitivity of data and the impact on public order, not just technical vulnerabilities. This is distinct from the technical penetration testing and incident logging required by NIS2.

Official sources

Related

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