Summary Under the proposed Cloud and AI Development Act (CADA), the European Commission would establish and maintain a central repository of cloud computing services recognised as meeting the Union assurance levels. As set out in Article 22, this public register would list services recognised at levels 1 through 4, giving procurement officers a transparent, single source for verifying a provider's sovereignty status. It is designed to streamline public procurement so that buyers can identify recognised, sovereign-ready services without repeating due diligence each time.
Detail
As proposed, the central repository is a cornerstone of CADA's sovereignty framework, intended to solve the problem of imperfect information in the cloud market. Public authorities currently struggle to verify whether a provider genuinely meets sovereignty or cybersecurity standards. CADA would address this with a harmonised, EU-wide register.
Legal basis and scope Article 22(1) would require the Commission to establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17. Recognition is the gateway to the repository: a service does not appear simply because a provider claims to be sovereign. It must go through the formal Article 17 process — a self-assessment (EU statement of conformity) for level 1, or an independent third-party audit for levels 2, 3 and 4 — and be recognised through the national competent authority of establishment.
Who registers the services? Article 22(2) provides that the national competent authority of establishment that recognised a service under Article 17 shall register that service in the central repository. The entry is therefore backed by official oversight rather than self-declaration alone.
Transparency and public access Article 22(4) states that the central repository shall be publicly available and regularly updated by the Commission and the national competent authorities of establishment on a dedicated and easily accessible website. This openness is meant to help public procurement officers and private-sector entities alike make informed decisions and to support European providers competing against larger non-EU incumbents.
Handling non-compliance and revocations The repository would also serve as a warning record. Article 22(3) specifies that the revocation of an audit report and audit 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 retention helps buyers stay aware of past compliance failures and discourages providers from quietly rebranding to bury earlier deficiencies.
Integration with the assurance levels The repository ties directly to the four Union assurance levels, whose cumulative criteria are set out in Annex II of CADA. As proposed:
- Level 1: verified via self-assessment (EU statement of conformity).
- Levels 2, 3 and 4: verified via independent audit, with increasingly strict criteria.
A procurement officer would be able to see which level a service holds. This matters because CADA's demand-side rules require risk-based procurement: Article 30 would require contracting authorities whose activities contribute to the preservation of public order (in NIS2 Annex I or II sectors, or in national security, internal security, border management, defence, justice or law enforcement) to procure only services recognised at level 2, 3 or 4, while other public bodies use at least level 1.
What this means for you
For public-sector procurement officers, the central repository would change vendor qualification. Instead of drafting bespoke questionnaires to test sovereignty claims, you could rely on the Commission's register as primary evidence.
- Simplified due diligence: When preparing a cloud tender, you could reference the repository. A service's presence at a stated Union assurance level serves as evidence of recognition against the Annex II criteria, reducing administrative burden.
- Risk-based procurement: You would still conduct risk assessments under Article 29 to determine the assurance level your activities require. The repository then lets you align procurement with that level — for example, excluding services not listed at level 4 where your risk assessment demands it.
- Monitoring and enforcement: The repository would be a living record. If a provider's audit or recognition is revoked, that fact is published and remains for five years. Establish internal processes to recheck the repository for services you use or plan to procure.
- Level playing field for European providers: Relying on the repository supports the EU's goal of a stronger cloud ecosystem and highlights providers that have invested in meeting sovereignty standards.
Common misconceptions
Misconception 1: The repository lists all cloud providers in the EU. No. It lists only services that have gone through the Article 17 recognition process. Many providers will not appear. Absence does not make a provider unlawful, but an unlisted service cannot be used for public-sector procurements that require a specific Union assurance level.
Misconception 2: Providers self-list their services. Incorrect. Providers apply for recognition, but registration in the repository is performed by the national competent authority of establishment (Article 22(2)), adding official verification.
Misconception 3: A listing guarantees future compliance. A listing reflects status at recognition. Providers face transparency obligations to report material changes (Article 23), and a revocation of an audit opinion or of recognition is published in the repository for five years (Article 22(3)). Treat a listing as a current snapshot, not a permanent guarantee.
Misconception 4: The repository replaces the need for risk assessments. No. It helps you identify recognised vendors, but it does not tell you which level you need. You remain required to carry out risk assessments under Article 29 to determine the appropriate level; the repository helps you execute the procurement once that requirement is set.
Related
- What is a sovereign cloud under CADA?
- Does CADA affect private companies that buy cloud services?
- Why was the Cloud and AI Development Act (CADA) proposed?
- Why is the EU dependent on non-EU cloud providers?
- Why does CADA have two legal bases (Articles 114 and 173(3) TFEU)?
This is general information about a draft EU regulation, not legal advice.