Data control
Where does customer data sit — including metadata and telemetry? Who can access it, with which privileges, and is that access logged without gaps? Encryption only counts once key management is settled.
The EU Cloud & AI Development Act — CADA for short — turns a strategic debate into an auditable requirement: four cumulative Union assurance levels, from data location all the way to effective control over every software component. We get your cloud estate, your evidence and your contracts onto those levels.
Figures from the explanatory memorandum of the Cloud & AI Development Act, Commission proposal COM(2026) 502 final of 3 June 2026. The act is going through the legislative procedure — criteria and deadlines may still change.
For years, “sovereign” was a promise made in vendor decks. The Cloud & AI Development Act (CADA) turns it into a list of criteria an auditing organisation can tick off — and a condition for who gets public contracts at all.
CADA shifts the test: no longer only where data sits, but who can dispose of it, of the operation and of the software when it matters. Public bodies must determine one of the four CADA levels per use case and may only procure recognised services; critical entities under the NIS2 Directive can apply the same logic. Sovereignty becomes something you document, audit and secure contractually — which is exactly where we come in.
Talking about data centre locations covers a third of the topic. The other two decide the higher CADA levels.
Where does customer data sit — including metadata and telemetry? Who can access it, with which privileges, and is that access logged without gaps? Encryption only counts once key management is settled.
Who actually runs the service? From level 2, staff location and support paths count; from level 3, the nationality of operational personnel and — where classified information is involved — national security clearance.
Who supplies the code, and who may still change it tomorrow? The highest level requires proof of effective control over design, maintenance, security fixes and evolution of every relevant software component.
Each level of the Cloud & AI Development Act contains the previous one and tightens it. Pick a level — the matrix shows which criterion is new at that point.
From here an independent auditing organisation checks. New: personnel and support exclusively from the Union, a European cybersecurity certificate of at least “substantial”, a ban on using operational data to train third-country AI, plus a complete SBOM with source code audits for third-country components.
new at this levelcarries over unchanged
Data residency is a good start — and covers exactly the lowest CADA level. This comparison prevents a lot of misunderstandings in tenders.
Three questions, a first orientation. The binding assignment comes from the risk assessment under Article 29 of the Cloud & AI Development Act.
This estimate replaces neither legal advice nor a formal risk assessment. It shows the corridor you are likely in — the defensible evidence is something we build together.
Six building blocks along the Cloud & AI Development Act — bookable individually, designed so every piece of evidence counts more than once.
We map your cloud estate and assess it along the three dimensions: data, operations, technology. Including the questions that rarely appear in vendor questionnaires — metadata flows, support paths, ownership structure.
Outcome: Sovereignty profile per workload with a provisional level assignment
We compare today's situation with the target level, quantify the gap and prioritise by effort, dependency and contract term. Not a maximum programme, but an order of work you can actually deliver.
Outcome: Prioritised action plan with effort, sequence and ownership
We build the SBOM pipeline level 2 requires, flag third-country components, define how source code audits are handled and document remote features that must be disabled.
Outcome: Audit-ready supply chain documentation that also serves the CRA
A documented migration plan for a supplier failure is not only a level 2 criterion, it is outsourcing governance in practice. We do not just write it — we test it with you.
Outcome: A tested exit plan instead of a statement of intent in the annex
We phrase sovereignty requirements so they are linked to the subject matter, documented and therefore challenge-proof — from data localisation including telemetry to audit rights and separation clauses.
Outcome: Defensible contract clauses and workable award criteria
We prepare you for the audit that is coming: BSI C5 as the established attestation, BSI C3A for the sovereignty dimension, and the groundwork for a future European cloud certification scheme.
Outcome: An evidence pack that stands up to independent third-party review
The sovereignty framework of the Cloud & AI Development Act reaches into regulations you already comply with — and largely asks for the same evidence.
Level assignment follows the sector logic of the NIS2 Directive. If you are already classified there, you know your scope.
View serviceDORARegister duties, exit strategies and concentration risk under DORA cover a substantial share of the sovereignty evidence.
View serviceCRAThe SBOM duty is substantively the same one the Cyber Resilience Act already brings. One build-out, two regimes served.
View serviceBSI C5A C5 attestation delivers much of the evidence an auditing organisation wants to see for levels 2 to 4.
View serviceBSI C3AThe C3A criteria catalogue addresses exactly the control questions the European framework will ask.
View serviceEU AI ActRemotely hosted and operated AI systems expressly count as cloud services — so the level logic applies to managed AI too.
View serviceSix steps that pay off regardless of how the CADA legislative procedure ends — because NIS2, DORA and the CRA already ask for the same evidence.
Not just “which service, which region”, but: who owns the provider, where does operational staff sit, which subcontractors are in the stack?
Assign your use cases to the four levels as a dry run. Within hours it shows which workloads would have no compliant provider today.
Location lists, access logs, data flow diagrams, SBOM: the evidence in Annex III is remarkably concrete — and incomplete in most organisations.
Data localisation including metadata, support paths, separation from third-country group entities, audit rights. That belongs in the next negotiation round, not the one after.
A plan never rehearsed is worth no more in an audit than a statement of intent. One exercise a year is enough to make the difference.
Bundle the evidence, name the owners, document the audit trail — so the first tender does not turn into a scramble for proof.
What decision-makers ask us most often about CADA and cloud sovereignty.
No. The Commission tabled the proposal on 3 June 2026; it is going through the ordinary legislative procedure. Under the draft, the regulation enters into force on the twentieth day after publication in the Official Journal and applies one year later. Criteria and deadlines may still change — the preparation for them does not.
Public bodies and Union entities are directly obliged. Entities in scope of the NIS2 Directive may carry out comparable assessments voluntarily, and the Commission can later make this binding for certain highly critical sectors. Beyond that, the framework sets a market standard: what tenders demand tends to end up in private supplier questionnaires too.
It helps considerably but does not cover the framework in full. C5 addresses information security in cloud operations; the sovereignty framework adds ownership, control, personnel location and the software supply chain. For the control dimension, the BSI C3A criteria catalogue is the closer match.
A European certification scheme specifically for cloud services has not been adopted to date; negotiations are considered blocked. The proposal solves this with a transitional rule: as long as no Union scheme exists, national schemes apply, and where those are missing too, the provider must demonstrate the highest standards under Union law. In practice: build national attestations now, design for European compatibility.
For a mid-sized cloud estate we plan two to four weeks up to the sovereignty profile, depending on how solid your contract and operations documentation already is. The gap analysis builds on it directly.
As a rule, no — and certainly not in haste. What makes sense is to sort your own workloads, improve the evidence base and build a negotiating position for the next contract cycle. Switching is one option among several, not the starting point.
Primary sources on the Cloud & AI Development Act — and our knowledge pages if you want to go deeper.
Thirty minutes, your actual portfolio, an honest read: we mirror your cloud estate against the four Union assurance levels of the Cloud & AI Development Act and name the gaps you can close today.