CADA Article 29 vs Article 30

Summary Under the proposed Cloud and AI Development Act (CADA), Article 29 and Article 30 form a mandatory two-step compliance loop for public sector cloud procurement. Article 29 is the diagnostic phase: it obliges Member States and Union entities to conduct risk assessments to identify which activities contribute to the preservation of "public order" and determine the appropriate Union Assurance Level (2, 3, or 4). Article 30 is the execution phase: it translates those findings into binding procurement rules. All public bodies must procure at least Union Assurance Level 1 as a baseline, but those identified in Article 29 as having public order relevance are legally restricted to procuring only services recognized at Levels 2, 3, or 4.

Detail

The Cloud and AI Development Act (CADA), as proposed in COM(2026) 502 final, establishes a harmonized sovereignty framework to reduce the EU's dependence on third-country cloud providers. For legal counsel and compliance officers, the interaction between Article 29 (Risk assessments) and Article 30 (Public procurement) constitutes the operational core of this framework. While Article 29 serves as a strategic planning and diagnostic tool, Article 30 acts as the binding purchasing constraint.

Article 29: The Diagnostic Phase (Risk Assessment)

Article 29 establishes the obligation for Member States and Union entities to map their cloud usage against sovereignty risks. It is not a procurement rule itself but a prerequisite that determines the minimum sovereignty standard required for specific activities.

• Who must act: Member States and Union entities (e.g., EU institutions, agencies, and bodies).
• The Obligation: They must carry out risk assessments to identify public sector activities that use or will use cloud computing services.
• The Focus: The assessment must specifically identify activities that contribute to the preservation of public order. This explicitly includes sectors falling under Annex I or II of Directive (EU) 2022/2555 (NIS2), as well as areas of national security, internal security, external border management, defence, justice, or law enforcement (including the prevention, investigation, detection, and prosecution of criminal offences).
• The Output: The risk assessment determines which Union Assurance Level (2, 3, or 4) is appropriate for the identified activities. It evaluates the sensitivity, criticality, and magnitude of the data processed, the risk of unlawful third-country access, and the risk of service disruption.
• Timeline: Assessments must be completed by the date of entry into force plus one year, and thereafter every two years, or whenever necessary.
• Commission Oversight: If the Commission concludes that a Member State's identified assurance level is inappropriate or does not adequately address public order concerns, it may adopt implementing acts to specify the required levels (Article 29(5)).

Article 30: The Execution Phase (Procurement Rules)

Article 30 translates the findings of Article 29 into mandatory procurement requirements. It dictates what a contracting authority is legally allowed to buy based on the risk classification derived from the Article 29 assessment.

• Who must act: Contracting authorities (public sector bodies) procuring cloud computing services for their exclusive use.
• The Baseline Rule (Level 1): For all public sector bodies whose activities have not been identified as contributing to the preservation of public order under the Article 29 risk assessment, the minimum requirement is to use cloud services recognized as offering Union Assurance Level 1 (Article 30(2)). This establishes a Union-wide baseline of sovereignty.
• The Public Order Rule (Levels 2–4): For contracting authorities whose activities have been identified as having public order relevance (via Article 29), they must only procure cloud computing services that have been recognized as having Union Assurance Levels 2, 3, or 4 (Article 30(3)).
• Derogations: Article 30(4) allows for exceptional derogations from these rules on an exceptional basis and where duly justified. This applies if:
  • The subject matter cannot be supplied by recognized services available in the central repository (Article 22) and no adequate alternative exists;
  • A similar procurement process within the previous year yielded no suitable tenders; or
  • Applying the requirements would require the contracting authority to procure services at disproportionate cost.

Key Differences: Article 29 vs Article 30

What this means for you

For in-house counsel, procurement officers, and compliance teams in the public sector, the distinction between these articles creates a strict, non-negotiable workflow:

1. Verify the Risk Assessment (Article 29) First: Before drafting any tender for cloud services, confirm that your organization's risk assessment is up-to-date. Has your specific activity been classified as having "public order relevance"?
   • If Yes: You are legally barred from procuring Level 1 services. You must procure Level 2, 3, or 4 services.
   • If No: You must still procure at least Level 1 services. You cannot use unassured cloud services.
2. Check the Central Repository (Article 22): Article 30 requires procurement from services recognized in the central repository. You cannot rely on a provider's self-declared sovereignty or marketing claims. You must verify the provider's recognition status in the Commission-maintained repository before awarding a contract.
3. Plan for Migration (Article 29(6)): If a risk assessment determines that your current cloud provider does not meet the required assurance level (e.g., you are currently on an unassured service or Level 1 but need Level 3), you must migrate within a reasonable transition period that shall not exceed 12 months. This creates a hard deadline for contract renegotiation or vendor switching.
4. Monitor for Commission Interventions: Be aware that under Article 29(5), the Commission can override a Member State's risk assessment if it deems the chosen assurance level insufficient. Compliance officers should monitor for implementing acts that may raise the bar for specific sectors, potentially forcing a re-evaluation of procurement strategies.
5. Document Derogations Rigorously: If you believe you qualify for a derogation under Article 30(4) (e.g., no Level 2 provider exists for a specific niche), you must document the justification rigorously. The burden of proof for "disproportionate cost" or "absence of adequate alternatives" lies with the contracting authority. Failure to document this could lead to legal challenges or penalties under Article 24.

Common misconceptions

"Article 30 applies to private companies." Incorrect. Article 30 explicitly applies to contracting authorities (public sector). Private sector entities are addressed in Article 31, which allows them to carry out similar impact assessments voluntarily, but does not impose mandatory procurement rules on them in the same way. Private entities in high-criticality sectors may face delegated acts requiring impact assessments, but the strict procurement mandate of Article 30 is public-sector specific.

"Level 1 is optional if we have low-risk data." Incorrect. Article 30(2) establishes Level 1 as the minimum baseline for all public sector bodies, regardless of risk level. Even if your activity is not deemed to have public order relevance, you cannot use unassured cloud services. Level 1 is the floor, not an option.

"We can choose between Level 2, 3, and 4 freely." Incorrect. The choice is dictated by the Article 29 risk assessment. If your risk assessment determines that Level 3 is required due to the sensitivity of the data (e.g., national security or law enforcement), you cannot choose to procure a Level 2 service. The assessment drives the procurement requirement; the procurement rule enforces it.

"Article 29 is a one-time exercise." Incorrect. Article 29(1) mandates assessments every two years, or whenever necessary. Compliance officers must establish a recurring process to review and update these assessments, as changes in technology, threat landscapes, or data sensitivity may alter the required assurance level.

"CADA replaces the AI Act's risk rules." No. CADA addresses the infrastructure sovereignty (where the cloud is, who controls it), while the AI Act addresses the system safety and fundamental rights (what the AI does). A public body using a high-risk AI system must comply with the AI Act for the system's safety, and CADA for the cloud infrastructure's sovereignty.

Official sources

• EU AI Act (Regulation (EU) 2024/1689)

Related

• CADA Risk Assessment vs. Sovereignty Tiers: How Article 29 Links to the Four Levels
• CADA Article 29: Purpose, Risk Assessment & Public Order
• CADA Risk Assessment vs. Impact Assessment: Article 29 vs. Article 31
• CADA Risk Assessment: A Step-by-Step Guide to Article 29
• What is a CADA risk assessment under Article 29?

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