By Jaap van Duijvenbode
Co-Founder and VP Product Strategy & Customer Experience
Summary: The proposed EU Cloud and AI Development Act (CADA) defines cloud sovereignty as four assurance levels rather than a yes-or-no label.
For enterprises, the practical takeaway is to classify data and workloads by the level of control they need, not to apply one sovereignty rule to everything.
From slogan to framework
For years, "sovereign cloud" meant whatever a provider's marketing said it meant. That is changing. On June 3rd, 2026, the European Commission proposed the Cloud and AI Development Act as part of its Tech Sovereignty Package. At its core is a four-level assurance framework for cloud sovereignty, intended for public-sector bodies to apply based on their own risk assessments, with providers recognized after audit.
CADA is still a proposal, with final adoption targeted for late 2027. But the framework is already shaping expectations. In April 2026, the Commission awarded a €180 million sovereign cloud contract to four provider groups using explicit sovereignty criteria, the first EU procurement to do so. Suppliers to the public sector, and regulated industries watching closely, should expect similar criteria to appear in their own contracts.
Sovereignty is about control, not location
Data residency answers one question: where is the data stored? Sovereignty asks several more:
- Legal control: can a foreign authority compel access to the data through the provider's parent company?
- Operational control: who can reach production systems, from where, and under whose supervision?
- Technical control: who holds the encryption keys, and can the platform keep running if a non-EU supplier is cut off?
- Strategic options: can the organization move its data and workloads if circumstances change?
A workload stored in an EU region can still score low on the first two. That is why a graded framework is more useful than a single label.
Match the level to the data
Not every workload needs the highest level of assurance, and treating everything as maximally sensitive is expensive and slows innovation. A practical approach:
- Classify data by consequence. What happens if this information is accessed by a foreign authority, lost, or unavailable for a week?
- Assign an assurance target per class. Public marketing content and sensitive engineering data do not belong at the same level.
- Check the full chain. Sovereignty applies to backups, indexes, AI processing and support access, not just primary storage. An AI assistant that sends document excerpts to a model hosted outside your boundary changes the answer.
- Keep options open. The EU Data Act removes cloud switching fees from January 12th, 2027. Architectures that keep data in open formats and avoid unnecessary lock-in make sovereignty decisions reversible.
What to do now
Use the time before adoption to build a data classification that maps cleanly onto assurance levels. When the framework becomes binding, or when a public-sector customer asks for it, the answer will be a lookup rather than a project.
Want to map your data classes to sovereignty requirements? Talk to our specialists.
Sources