How does CADA transparency reduce vendor lock-in concerns for buyers?

As proposed, the Cloud and AI Development Act (CADA) would significantly reduce vendor lock-in concerns by mandating a central, public repository of cloud

Summary As proposed, the Cloud and AI Development Act (CADA) would significantly reduce vendor lock-in concerns by mandating a central, public repository of cloud services formally recognised for meeting specific Union assurance levels. Article 22(4) requires this repository to be publicly available and regularly updated, enabling buyers to transparently identify alternative, compliant providers. This visibility directly supports multi-cloud strategies, lowers the barrier to switching, and informs procurement decisions by replacing information asymmetry with a single source of truth for sovereign cloud offerings.

Detail

The proposed Cloud and AI Development Act (CADA) addresses the structural issue of vendor lock-in not by banning proprietary contracts or mandating specific technologies, but by solving the "imperfect information" problem that currently traps buyers. In the current market, organisations—particularly in the public sector or regulated industries—often face a limited pool of known providers when they require sovereign or highly trusted cloud services. Without a centralised, auditable view of which providers meet specific sovereignty, security, and data localisation criteria, buyers remain dependent on incumbent providers because the cost and risk of verifying an alternative are prohibitively high.

CADA introduces a mechanism to make the market for trusted cloud services transparent, predictable, and comparable. The cornerstone of this transparency is the central repository of cloud computing services.

The Central Repository as a Market Enabler

Under Article 22(1), the Commission would establish and maintain a dedicated repository of cloud computing services that have been recognised in accordance with Article 17. Recognition under Article 17 means a provider has undergone a rigorous process—either a conformity self-assessment for Union assurance level 1, or an independent third-party audit for levels 2, 3, and 4—to prove it meets the strict sovereignty, data localisation, and cybersecurity criteria set out in Annex II of the proposal.

Crucially, Article 22(4) states:

"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 public availability is the key lever against lock-in. By making the list of recognised services transparent, CADA ensures that buyers do not have to rely on a single provider's marketing claims or opaque contractual assurances to know if a service is compliant. Instead, they can consult a single source of truth to identify all providers that have been formally vetted and recognised for a specific assurance level.

How Transparency Reduces Lock-in

Vendor lock-in is driven by three main factors: high switching costs, lack of interoperability, and information asymmetry. CADA's transparency measures directly attack the third factor, which in turn mitigates the first two.

Identifying Alternatives: Before CADA, a buyer needing a "sovereign cloud" might only know of one or two providers who claim to meet national security standards. With the central repository, a buyer can instantly see all providers recognised at Union assurance level 2, 3, or 4. This expands the addressable market for buyers and forces providers to compete on quality and price, not just on incumbency. A comparable public register helps buyers identify alternative recognised services that they might otherwise overlook, breaking the monopoly of information held by large incumbents.
Informing Multi-Vendor Strategies: Article 29(9) explicitly encourages Member States and Union entities to consider whether a multi-vendor or multi-cloud strategy is appropriate as part of their risk assessments. A multi-cloud strategy is a primary technical defence against lock-in, as it distributes risk across providers. However, implementing a multi-cloud strategy is complex if you cannot easily identify other compliant providers. The repository simplifies this by listing all viable alternatives, making multi-cloud architectures a practical, rather than theoretical, option.
Facilitating Switching: Article 23 imposes transparency obligations on providers to report material changes that might affect their recognised status. If a provider's status changes (e.g., an audit opinion is revoked), this is published in the repository. This early warning system allows buyers to plan migrations before a disruption occurs, rather than being forced into a reactive, costly emergency switch. Furthermore, the existence of a known list of alternatives means buyers can negotiate exit clauses and data portability terms with greater leverage, knowing they have pre-vetted options to move to.

The Role of Assurance Levels in Standardising Comparisons

The repository does not just list providers; it categorises them by Union assurance levels (1 through 4). These levels represent a harmonised understanding of trust and sovereignty across the EU.

Level 1: Requires establishment in the Union, data staying in the Union, and basic cybersecurity standards. Recognised via self-assessment.
Levels 2–4: Require independent third-party audits, stricter data localisation, personnel screening (for levels 3 and 4), and separation from third-country control.

Because these criteria are harmonised, a buyer can compare providers "apples-to-apples." If a buyer requires Level 3 assurance for a specific workload, they can filter the repository for all Level 3 providers. This standardisation removes the need for buyers to conduct bespoke, resource-intensive due diligence on every potential vendor, significantly lowering the barrier to switching.

Interaction with Public Procurement

For public sector buyers, the impact is even more direct. Article 30(2) and Article 30(3) mandate that contracting authorities must procure cloud services that have been recognised under Article 17. Specifically, activities contributing to public order must use services recognised at Level 2, 3, or 4.

Without the repository, public procurers would struggle to identify compliant bidders, potentially leading to single-source contracts or restricted tenders that reinforce lock-in. With the repository, procurers can issue open tenders referencing the specific assurance level, knowing that all bidders listed in the repository are pre-verified. This creates a competitive bidding environment where multiple providers can compete, driving down costs and improving service quality.

What this means for you

For CTOs and Architects: You can use the central repository as a primary input for your cloud architecture and vendor strategy. When designing a multi-cloud or hybrid-cloud architecture, you should monitor the repository to identify providers that meet your specific assurance requirements. This allows you to:

Design for Portability: By knowing which providers meet the same assurance levels, you can architect your workloads to be portable between them, using standardised interfaces and data formats.
Reduce Due Diligence Burden: Instead of conducting deep-dive security and sovereignty audits on every new vendor, you can rely on the repository's recognition status as a baseline verification, focusing your internal audits on integration and operational specifics.
Plan for Resilience: Use the repository to identify backup providers. If your primary provider faces issues (e.g., audit failures, service disruptions), you will have a pre-identified list of alternative providers that meet your compliance requirements, enabling faster failover or migration.

For SMEs and Buyers:

Level the Playing Field: The transparency of the repository helps smaller providers gain visibility. As an SME buyer, you are no longer forced to choose from a handful of hyperscalers. You can discover smaller, specialised European providers that may offer better pricing, service, or niche capabilities, provided they are recognised in the repository.
Negotiate Better Terms: Knowing you have alternatives reduces your dependency on any single vendor. This leverage can be used to negotiate better contract terms, including clearer exit clauses, data portability guarantees, and competitive pricing.
Simplify Compliance: If you are subject to sector-specific regulations that require sovereign cloud services, the repository simplifies compliance. You can select providers from the list knowing they have already been assessed against the CADA criteria, reducing your legal and operational risk.

Actionable Steps:

Monitor the Proposal: Keep track of the legislative progress of CADA. While it is a proposal, the framework is likely to influence market behaviour and procurement standards even before full adoption.
Audit Your Current Stack: Assess your current cloud providers against the proposed Union assurance levels. Identify gaps where your current provider may not meet the transparency or sovereignty criteria that will be required.
Engage with the Market: Start identifying alternative providers that are positioning themselves for recognition under CADA. Engage in early discussions about data portability and multi-cloud integration.

Common misconceptions

Misconception 1: The repository guarantees service quality or performance. The central repository lists providers that have been recognised for meeting specific sovereignty, security, and data localisation criteria. It does not rate providers on performance, latency, price, or customer support quality. Buyers must still conduct their own technical evaluations to ensure a provider meets their operational needs.

Misconception 2: CADA bans vendor lock-in or proprietary contracts. CADA does not prohibit proprietary contracts or technical lock-in. Instead, it reduces the risk of lock-in by increasing market transparency and facilitating switching. It assumes that if buyers can easily find and verify alternatives, providers will compete more fairly, and buyers will be less trapped by information asymmetry.

Misconception 3: All cloud providers will be listed in the repository. Only providers that have actively sought and received recognition under Article 17 will be listed. Providers that do not meet the Union assurance levels, or those that choose not to undergo the audit/recognition process, will not appear in the repository. This means the repository is a list of compliant providers, not a comprehensive directory of all cloud services.

Misconception 4: The repository replaces the need for due diligence. While the repository provides a baseline of trust regarding sovereignty and security, it does not replace the need for commercial, technical, and operational due diligence. Buyers must still evaluate providers on factors such as service level agreements (SLAs), pricing models, integration capabilities, and customer support.

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