Summary Under the proposed Cloud and AI Development Act (CADA), the Commission would establish a central repository of cloud computing services recognised at the Union assurance levels (Article 22). This publicly available, regularly updated database would let public-sector buyers verify a provider's sovereignty status, compare assurance levels, and procure with less individual due diligence. Providers would have to keep their status accurate and report material changes (Article 23) to stay listed.
Detail
CADA would move cloud sovereignty away from marketing claims toward auditable, harmonised criteria. The transparency mechanism at the centre of this is the central repository, established under Article 22.
The central repository (Article 22)
As proposed, the Commission "shall establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17." The national competent authority of establishment that recognised a service would register it in the repository (Article 22(2)). Recognition confirms that a service meets one of the four Union assurance levels (1 to 4), from baseline establishment requirements to stringent controls on personnel, data localisation and third-country influence.
The repository is not an internal register. Under Article 22(4), it "shall be publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website." Any public sector body — from a small municipality to a national agency — could rely on the same verified information without auditing every potential vendor itself.
The repository lists services that have undergone either a conformity self-assessment (level 1) or an independent third-party audit (levels 2, 3 and 4). By listing only recognised services, it filters out providers that have not demonstrated compliance with the Annex II criteria.
Linking transparency to trust (Article 23)
A static list would go stale, so CADA imposes transparency obligations on providers under Article 23. Under Article 23(1), a recognised provider must notify both the auditing organisation and the national competent authority of establishment "as soon as possible" on becoming aware of any information or material change in circumstances that may affect the audit report, the positive audit opinion (under Article 20) or the recognition (under Article 17).
The proposal does not give an exhaustive list of "material changes," but the assurance criteria suggest they include changes in ownership or control, shifts in infrastructure location, changes to subcontractor arrangements, or any event exposing the service to third-country control or data-access risk.
The update process is structured:
- Notification: the provider notifies the auditor and competent authority (Article 23(1)).
- Assessment: the auditing organisation assesses whether the audit report or opinion needs amending or revoking (Article 23(2)); if it amends or revokes them, it notifies the competent authority.
- Verification and update: the national competent authority of establishment assesses whether its recognition needs amending or revoking; if revoked, it notifies the other Member States and the Commission (Article 23(3)).
This keeps the repository reflecting the current sovereignty posture, not just status at the last annual review.
How buyers use the repository
For public sector bodies, the repository turns sovereignty into a practical procurement tool. Under Article 30, contracting authorities must procure services meeting specific Union assurance levels based on their Article 29 risk assessments. A buyer needing, for example, level 3 can consult the repository to find providers holding that recognition — avoiding verifying complex legal and technical criteria from scratch.
The repository also supports Union-wide effect of recognition: once a service is recognised by the competent authority of establishment under Article 17, it is recognised throughout the Union (Article 17(7)), and the repository makes that cross-border validity visible, helping European providers scale across the Single Market.
Revocation and public record
The repository serves a warning function. Article 22(3) provides that the revocation of an audit report and opinion by an auditing organisation, or the revocation of a recognition by a competent authority, "shall be published in the central repository and shall remain available there for five years." This record lets buyers gauge the stability of a provider's sovereignty claims over time.
What this means for you
If you are a cloud provider or data-centre operator aiming to serve the European public sector, the central repository would be your sovereignty storefront — and being listed would, in practice, be necessary to compete for public-order procurements.
- Prepare for public scrutiny. Your status would be visible to competitors, customers and regulators. Deficiencies could lead to revocation and a public five-year record.
- Establish internal monitoring. Build processes to detect "material changes" — shareholder structure, subcontractor locations, infrastructure configuration — because delayed notification under Article 23 can cost you recognition.
- Coordinate with auditors. For levels 2–4, give your auditing organisation timely information so it can update the audit opinion.
- Verify your listing. Once recognised, monitor the repository to ensure your details are accurate, since inaccurate public data can harm your reputation and procurement chances.
Common misconceptions
Misconception 1: The repository lists all cloud providers in the EU. Reality: It lists only services that have been formally recognised at a Union assurance level. Providers that have not applied, or whose applications were rejected, would not appear. It is a list of recognised services, not a market directory.
Misconception 2: Listing guarantees a public contract. Reality: Recognition is a precondition for procurement in certain sectors, not a guarantee of award. Authorities still evaluate tenders on technical and financial criteria, including the non-price "Union added value" criteria under Article 32.
Misconception 3: The repository is static and needs no ongoing effort. Reality: It is dynamic. Under Article 23, providers must report material changes; failing to do so when circumstances change can lead to revocation and potential penalties under Article 24.
Related
- Why is cloud sovereignty important for critical infrastructure? CADA
- Why is sovereignty described as layered or nuanced in CADA?
- CADA Sovereignty: Why Assessment is Per Service, Not Per Provider
- Why is sovereignty a competitiveness issue, not just a security one? | CADA
- Why data residency is not enough for cloud sovereignty under CADA
This is general information about a draft EU regulation, not legal advice.