CADA Compliance Order: NIS2, DORA, Risk Assessments & Recognition

Summary As proposed, the Cloud and AI Development Act (CADA) does not replace existing cybersecurity or data protection laws but builds upon them. Cloud service providers (CSPs) and data centre operators must first secure compliance with baseline technical regimes like NIS2 and DORA, as these form the foundational requirements for CADA's higher assurance levels. Only after these technical baselines are met should providers pursue formal recognition under Article 17 to become eligible for public sector procurement. Simultaneously, public sector bodies must conduct risk assessments under Article 29 within one year of the regulation's entry into force (and every two years thereafter) to determine which assurance levels are required. Crucially, recognition under Article 17 must precede procurement eligibility; a provider cannot be awarded a contract requiring a specific assurance level without first being listed in the central repository.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, introduces a "Union cloud computing sovereignty framework" that operates in tandem with, rather than in isolation from, the EU's existing digital regulatory landscape. For cloud service providers (CSPs) and data centre operators, the path to market access—particularly for the public sector—is not a single step but a sequential, cumulative process. Understanding the correct order of operations is critical to avoiding regulatory gaps, preventing wasted audit efforts, and ensuring eligibility for public procurement.

1. The Foundation: NIS2, DORA, and Cybersecurity Baselines

Before a provider can even consider applying for CADA recognition, they must secure their technical cybersecurity posture. CADA is explicitly designed to complement, not replace, existing cybersecurity frameworks. The explanatory memorandum states that the proposal "complements the Cybersecurity Act's focus on cloud cybersecurity with sovereignty considerations" and that "certification under the Cybersecurity Act can address technical cybersecurity criteria but is not suited for addressing sovereignty concerns."

NIS2 Directive: The Directive on Security of Network and Information Systems (NIS2) establishes the mandatory cybersecurity risk management baseline for cloud computing service providers and data centres. CADA relies on this foundation. For instance, Annex II of the proposal requires providers to demonstrate compliance with "state-of-the-art cybersecurity standards." Without meeting NIS2 requirements, a provider cannot satisfy the technical prerequisites for even the lowest Union assurance level.
DORA: For providers serving the financial sector, the Digital Operational Resilience Act (DORA) imposes specific ICT risk management and incident response testing obligations. CADA supports DORA's objectives but does not supersede them. DORA compliance remains a separate, mandatory prerequisite for financial entities, and CADA's sovereignty criteria operate alongside these sector-specific rules.
GDPR and the Data Act: Data protection remains governed by the GDPR. CADA's sovereignty criteria, particularly regarding data localisation and access by third countries, operate alongside GDPR restrictions on third-country transfers. The Data Act's provisions on switching and interoperability enable users to embrace European services, acting as an enabler for CADA's goals, but do not replace the need for GDPR compliance.

Sequencing Insight: Do not start with CADA recognition. First, audit your compliance with NIS2, DORA (if applicable), and GDPR. These are the "technical" floors upon which CADA's "sovereignty" building blocks are stacked. Attempting a CADA audit without these baselines in place will likely result in a "negative" audit opinion under Article 20.

2. The CADA Sovereignty Framework: Union Assurance Levels

Once technical baselines are secured, providers must navigate the four-tier sovereignty framework established by Article 16 and detailed in Annex II. These levels dictate the degree of control, data localisation, and personnel citizenship required.

Level 1: Requires the provider to be established in the Union, with infrastructure and assets located in the Union (unless explicitly required otherwise by the public sector body). Data must remain exclusively within the Union. This level allows for self-assessment and the issuance of an EU statement of conformity.
Levels 2, 3, and 4: These higher levels introduce stricter requirements, including mandatory independent third-party audits, potential Union citizenship requirements for personnel, and prohibitions on third-country control.
- Level 2: Requires a European cybersecurity certificate of at least assurance level 'substantial' (not 'high', which is reserved for Level 4). It also mandates that personnel screening requirements be met if the public sector body determines them necessary.
- Level 3: Requires personnel to be Union citizens (conditional on public sector requirements) and mandates a cybersecurity certificate of at least 'substantial'. It also introduces a derogation mechanism under Article 18 for third-country control, provided the Commission has adopted an implementing act for that specific third country.
- Level 4: The highest tier, requiring a cybersecurity certificate of at least assurance level 'high'. It mandates that the provider and subcontractors are not subject to the control of a third country (with no derogation available) and that sensitive data remains exclusively within the Union at all times.

The criteria become progressively more stringent. For example, Level 4 requires that the audited provider and subcontractors are not subject to the control of a third country, and that sensitive data remains exclusively within the Union at all times.

3. Recognition Under Article 17: The Gateway to Procurement

To sell to public sector bodies, a CSP must be formally recognised as offering a specific Union assurance level. This process is governed by Article 17 of CADA.

The Process: A CSP submits an application for recognition to the national competent authority of its establishment.
- For Level 1, the provider submits an EU statement of conformity based on a self-assessment. Notably, for SMEs, this statement is directly and automatically recognised in all Member States without prior national recognition.
- For Levels 2, 3, and 4, the provider must submit an audit report and a 'positive' audit opinion from an independent auditing organisation, as detailed in Article 20.
Timeline: The evaluating national competent authority has 60 days to assess the evidence. It may then notify other Member States for a 60-day review period. If no reasoned objections are raised, the service is recognised throughout the Union.
Central Repository: Recognised services are registered in a central repository maintained by the Commission (Article 22). Only services listed here can be procured by public sector bodies under the mandatory rules.

Sequencing Insight: Recognition is a prerequisite for procurement. You cannot bid for contracts requiring Level 2 assurance without first undergoing the independent audit and obtaining recognition under Article 17. This process can be lengthy, so providers should initiate audits early, once NIS2/GDPR baselines are secure.

4. Public Sector Obligations: Article 29 Risk Assessments

While providers focus on recognition, public sector bodies (contracting authorities) have parallel obligations. Article 29 requires Member States and Union entities to carry out risk assessments to determine which assurance level is appropriate for their activities.

Timing: These assessments must be carried out one year after the entry into force of the regulation, and thereafter every two years, or whenever necessary.
Scope: The assessments identify public sector activities that contribute to the preservation of public order, particularly in sectors falling under Annex I or II of NIS2, and in areas of national security, defence, justice, or law enforcement.
Outcome: The risk assessment determines whether a service must be procured at Level 1 (for general activities) or Levels 2, 3, or 4 (for activities with public order relevance).

Sequencing Insight: Public sector buyers must complete their Article 29 assessments before they can legally issue tenders requiring specific assurance levels. Providers should monitor these national risk assessments to understand which assurance levels will be in demand.

5. Procurement and Added Value

Once recognition is secured and risk assessments are complete, procurement proceeds under Article 30. Contracting authorities whose activities are identified as contributing to public order must only procure services recognised at Levels 2, 3, or 4. For all other activities, Level 1 is the minimum requirement.

Additionally, Article 32 allows contracting authorities to include "Union added value" criteria in tenders. This includes evaluating the tenderer's contribution to strengthening the digital supply chain in the Union, such as using hardware designed or manufactured in the Union. While not decisive for the award, this can account for up to 15 points in the evaluation, incentivising providers to highlight their European footprint.

What this means for you

For cloud service providers and data centre operators, the compliance roadmap is sequential and cumulative:

Audit and Remediate (Months 1–6): Conduct a gap analysis against NIS2, DORA (if applicable), and GDPR. Implement necessary technical controls. You cannot achieve CADA recognition without these foundations.
Select Your Target Assurance Level (Months 6–9): Determine which Union assurance level(s) you can realistically achieve. Level 1 requires self-assessment and documentation. Levels 2–4 require significant operational changes, such as ensuring no third-country control, localising all support staff, and potentially restricting personnel to Union citizens.
Engage Auditors (Months 9–12): For Levels 2–4, contract an independent auditing organisation early. The audit process under Article 20 is rigorous, requiring evidence on supply chain transparency, software bill of materials (SBOM), and separation from third-country subsidiaries.
Apply for Recognition (Months 12–18): Submit your application under Article 17. Be prepared for the 60-day assessment and potential 60-day review by other Member States. Ensure your documentation is flawless to avoid delays.
Monitor Public Sector Demand: Track the risk assessments conducted by Member States under Article 29. Align your marketing and sales efforts with the assurance levels that public sector bodies are mandating for their critical infrastructure.

Common misconceptions

"CADA replaces NIS2." Incorrect. CADA builds on NIS2. NIS2 sets the technical cybersecurity baseline; CADA adds sovereignty, data localisation, and control criteria. Compliance with both is mandatory.
"I can self-certify for Level 3." Incorrect. Only Level 1 allows for self-assessment and an EU statement of conformity. Levels 2, 3, and 4 require independent third-party audits and formal recognition by national competent authorities.
"Article 29 risk assessments are optional for public sector bodies." Incorrect. Article 29 mandates that Member States and Union entities carry out these assessments within one year of entry into force. Failure to do so may leave public sector bodies without the legal basis to procure higher-assurance services, creating market uncertainty.
"Recognition in one Member State is enough." Correct, but with a caveat. Recognition by the competent authority of establishment is valid across the Union (Article 17). However, the central repository ensures transparency, and objections from other Member States during the review period can delay or block recognition.
"CADA is just about data centres." Incorrect. While data centres are a key component, CADA also proposes the cloud sovereignty framework, the Cloud and AI Leadership Initiatives, public-sector adoption measures and a public-sector cloud federation.

Official sources

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

CADA Compliance Order