Summary Under the proposed Cloud and AI Development Act (CADA), cloud computing service providers seeking Union assurance levels 2, 3, or 4 must undergo independent third-party audits to demonstrate compliance with strict sovereignty criteria. Preparation is not optional; it requires assembling comprehensive evidence on data residency, software supply chains (including Software Bills of Materials), and third-country control safeguards, while ensuring the chosen auditor meets rigorous independence and competence requirements outlined in Article 20 and Annex III. Unlike Level 1, which relies on self-assessment, higher levels demand a "positive" audit opinion to be recognised across the Union.

Detail

The proposed Cloud and AI Development Act (CADA) establishes a tiered sovereignty framework where the burden of proof escalates with the assurance level. While Union assurance level 1 allows providers to issue an EU statement of conformity via self-assessment (Article 19), providers aiming for levels 2, 3, or 4 must undergo independent third-party audits (Article 20). This distinction is critical for any provider targeting public sector bodies, as Article 30(3) mandates that activities contributing to the preservation of public order must procure services recognised at levels 2, 3, or 4.

The audit is not a generic security review or a standard ISO certification. It is a targeted assessment against specific "audit criteria" set out in Annex II, with the specific evidence required to prove compliance detailed in Annex III. The auditing organisation must issue an audit report containing either a "positive" or "negative" opinion on whether the provider complies with the cumulative criteria for the requested assurance level (Article 20(5)). A "positive" opinion is the gateway to recognition by the national competent authority and subsequent listing in the central repository (Article 22).

1. Selecting an Independent Auditor

The first and most critical step in preparation is selecting an auditing organisation that meets the stringent independence requirements of Article 20(4). You cannot choose just any certification body or cybersecurity firm. The auditor must be demonstrably independent from the cloud computing service provider and any connected legal person.

The regulation imposes specific "cooling-off" and conflict-of-interest rules:

  • Non-Audit Services Ban: The auditor must not have provided non-audit services related to the matters being audited to the provider in the 12-month period before the audit begins, nor commit to providing them in the 12-month period after completion (Article 20(4)(a)(i)).
  • Auditing History: The auditor must not have provided auditing services pursuant to this Regulation to the provider in the 10-year period before the beginning of the audit (Article 20(4)(a)(ii)).
  • Fee Structure: Fees must not be contingent on the result of the audit (Article 20(4)(a)(iii)).
  • Competence and Objectivity: The auditor must have proven expertise, technical competence, and capabilities in auditing cloud computing services, as well as proven objectivity and professional ethics (Article 20(4)(b)–(c)).

If an auditing organisation's independence or technical competence is not beyond doubt, it must abstain or resign from the audit engagement (Article 20(4)). Providers should verify these credentials before engagement to avoid delays or a negative opinion later.

2. Gathering Evidence: The Core of Audit Prep

Annex III of CADA provides a detailed, indicative list of audit evidence that auditing organisations should request. Preparation involves assembling this evidence systematically across several key domains. Failure to provide sufficient and reliable evidence can result in a negative opinion or the inability to obtain recognition.

A. Union Establishment and Infrastructure Location (Annex III, Criteria A & B)

For levels 2, 3, and 4, the provider and relevant subcontractors must be established in the Union, and their infrastructure, assets, and personnel must be located there (Annex II, 2.1(a)–(b)).

  • Establishment Evidence: Provide national company extracts, tax residency documentation, VAT registration, and proof of stable effective presence. This includes lease contracts for EU physical offices, utility bills, and payroll records demonstrating permanent staff located in the Union (Annex III, 1(4)–(5)).
  • Infrastructure Evidence: Submit a precise list of infrastructure locations (street, city, postal code, country) for primary, backup, disaster recovery, and log storage. Include network diagrams and architecture documents illustrating the exclusive use of Union-based infrastructure for data storage and processing (Annex III, 2(1)).
  • Asset Evidence: Provide asset registers, purchase invoices, delivery notes, and maintenance contracts proving that servers, equipment, and operational assets are physically located in the Union (Annex III, 2(2)).

B. Data Localisation and Residency (Annex III, Criterion C)

Customer data, including metadata and telemetry, must remain exclusively within the Union unless the public sector body explicitly requires otherwise (Annex II, 2.1(c)).

  • Data Flow Diagrams: Create clear diagrams showing data flows between the provider, customer data, and third-party services, explicitly demonstrating that data does not leave the Union. The diagram must identify the source and destination of data (Annex III, 3(4)).
  • Access Logs and Policies: Provide privileged access records, backup retention policies, and support access policies. Evidence must show that third parties or subcontractors not meeting the conditions cannot access or process customer data without prior authorisation (Annex III, 3(1)).
  • Contractual Agreements: Supply master service agreements and data processing agreements containing clauses prohibiting data transfer outside the Union without public sector body approval (Annex III, 3(3)).

C. Software Supply Chain Transparency (Annex III, Criterion I)

This is a significant new requirement for sovereignty. Providers must demonstrate transparency and control over their entire software stack.

  • Software Bill of Materials (SBOM): You must make available a complete and up-to-date SBOM for all software components, including open-source software (OSS), and a list of identified dependencies relevant to the service (Annex III, 9(1)–(2)).
  • Dependency List: Provide details on the origin of software (country of origin, developer, jurisdiction) and the degree of reliance on non-EU vendors. For Level 3, evidence must show that no unduly unjustified licensing restrictions are in place for third-country software (Annex III, 9(2)).
  • Remote Feature Controls: Provide test reports, test plans, and change management procedures proving that there are no remote features or mechanisms that could materially tamper with or disrupt the system. This includes evidence that firmware, BIOS, and software updates are controlled and audited to prevent such tampering (Annex III, 9(4)).
  • Migration Plans: If you rely on third-country software, provide documented migration plans in case the vendor fails or a third country imposes restrictions. You must identify alternative solutions and implement switchover plans (Annex III, 9(3)).

D. Third-Country Control and Safeguards (Annex III, Criterion G)

If the provider or subcontractors are subject to the control of a third country or a legal entity established in a third country, you must demonstrate robust safeguards. Note that for Level 3, a derogation exists if the Commission has adopted an implementing act identifying the third country as providing sufficient assurances (Article 18 and Annex II, 3.1(g)).

  • Ownership Structure: Provide cap tables, shareholder agreements, and articles of association up to the ultimate owners. This includes identifying any shareholder holding at least 5% of capital or voting rights (Annex III, 7(2)).
  • Governance Evidence: Document decision-making bodies, voting rights, veto rights, and board composition to prove that third-country entities cannot exert control that undermines service delivery or forces compliance with restrictive measures (Annex III, 7(3)).
  • Separation Measures: If you maintain subsidiaries in third countries, provide evidence of effective legal, technical, and organisational separation. This includes proving that third-country subsidiaries have no privileged access to Union production environments (e.g., no IAM or PAM privileges) and no authority to instruct Union staff to disclose data (Annex III, 11).

E. Personnel and Citizenship (Annex III, Criterion D)

For levels 3 and 4, personnel involved in service provision must be Union citizens, and where appropriate, hold national security clearance (Annex II, 3.1(d) & 4.1(d)).

  • Verification Procedures: Provide organisational charts and job descriptions confirming that only Union citizens have access to the service's operation, management, and maintenance. Valid official government-issued documents (e.g., passports) may be required as proof (Annex III, 4(1)).
  • Access Controls: Show audit trails and access control policies verifying that only authorised Union citizens can access systems and data (Annex III, 4(3)).

3. Cooperation and Access

During the audit, you are legally obligated to cooperate fully. Article 20(2) requires providers to give auditing organisations access to all relevant data and premises and to answer oral or written questions. You must not hamper, unduly influence, or undermine the performance of the audit. Failure to provide necessary cooperation can lead to a negative audit opinion or the revocation of recognition by the competent authority (Article 20(7)).

The audit report must be substantiated in writing and include a "positive" or "negative" opinion. If the opinion is negative, it must include operational recommendations and a timeframe to achieve compliance (Article 20(5)). Providers must also submit the audit report and opinion annually for review to ensure continued compliance (Article 20(8)).

What this means for you

For cloud service providers and data centre operators, CADA shifts the burden of proof from marketing claims to verifiable, audited evidence. The "sovereignty" label is not a badge of honour but a compliance requirement backed by independent scrutiny.

  • Immediate Action: If you currently offer services to the public sector, map your infrastructure and data flows against Annex III. Identify gaps in your SBOM, third-country control documentation, and personnel citizenship verification immediately.
  • Auditor Engagement: Start identifying potential auditing organisations early. The pool of qualified, independent auditors may be limited initially. Ensure your chosen auditor understands the specific "sovereignty" criteria, not just standard cybersecurity certifications like ISO 27001. Verify their independence against the 10-year and 12-month rules.
  • Technical Documentation: Your architecture documents must be audit-ready. Network diagrams must explicitly show data boundaries. Your SBOM must be automated and up-to-date; manual processes will likely fail under the scrutiny of an independent auditor.
  • Subcontractor Management: You are responsible for your subcontractors. Ensure your contracts with them require them to provide the same level of evidence (location, citizenship, control) as you must provide. If they cannot, you may not be able to achieve Union assurance levels 2–4.
  • Third-Country Strategy: If you have third-country shareholders or subsidiaries, prepare for a deep dive into your corporate governance. You must prove effective separation and that no third-country law can compel you to compromise service continuity or data confidentiality.

Common misconceptions

"A cybersecurity certificate is enough." No. While a European cybersecurity certificate of at least "substantial" assurance (for Levels 2 and 3) or "high" assurance (for Level 4) is required (Annex II, 2.1(e), 3.1(e), 4.1(e)), it is only one criterion. CADA audits cover sovereignty, data residency, personnel citizenship, and supply chain transparency, which go far beyond technical cybersecurity.

"Open-source software is exempt from scrutiny." No. Annex III, Criterion J requires controls to prevent remote features in open-source software. You must demonstrate that you have tested and documented controls to prevent tampering, even if the code is open. You must also have a plan to migrate if the OSS comes under third-country control.

"If we are EU-owned, we don't need third-country safeguards." If you have any third-country shareholders (even below 5% if they have specific rights) or subsidiaries, you must still demonstrate effective separation and control safeguards. The audit will scrutinise ownership structures up to the ultimate owners (Annex III, 7).

"Self-assessment applies to all levels." Self-assessment is only for Union assurance level 1 (Article 19). Levels 2, 3, and 4 strictly require independent third-party audits. A self-assessment cannot substitute for the "positive" audit opinion required for recognition.

"The auditor can be anyone with a cybersecurity background." The auditor must meet strict independence criteria, including a 10-year look-back on auditing services and a 12-month cooling-off period on non-audit services (Article 20(4)). Many standard certification bodies may be disqualified due to prior consulting relationships.

Related

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