On 3 June 2026 the European Commission proposed the Cloud and AI Development Act (CADA), part of its Technological Sovereignty Package. As of publishing, this is still a proposal. But it is already shifting the conversations between European cybersecurity leaders and the technology partners they rely on, putting new emphasis on security data that stays under European control, within European jurisdiction.
CADA grades cloud and AI services across four sovereignty levels and steers sensitive workloads towards providers that can keep data under European control. It sits alongside the Chips Act 2.0 and the EU Open Source Strategy in a package aimed at reducing Europe's reliance on technology it does not govern.
It grades cloud and AI services across four sovereignty levels and steers sensitive workloads towards providers that can show European control and independence from foreign law. It does not ask only whether your controls work. It asks whether you can show, at the level the workload demands, that control sits in trusted hands.
In practice, that comes down to three questions:
One thing to keep in mind: This package is still a proposal. It needs agreement from all 27 member states and the European Parliament before it becomes law. This is likely to involve a national transposition process where each member state adopts its own interpretation of the EU-wide regulation.
The assurance levels are written for public sector bodies, but the obligation does not stop with them. The moment a public body procures at a given level, that requirement flows down the chain — to the suppliers it buys from, the integrators it relies on, and the service providers that run security on its behalf.
Any organisation that supplies, integrates with, or operates on behalf of a public body inherits the requirement through the contract, even though it never runs a sovereignty assessment itself. In practice that pulls in private organisations across the regulated sectors — energy, healthcare, public administration, and the critical infrastructure around them — together with the technology vendors and service providers they depend on.
If you sell into, partner with, or process data for the European public sector, the safe assumption is that CADA reaches you, whether or not the text names you directly.
For years, security spend focused exclusively Oton prevention, detection, and response. Cloud-first vendors and hyperscalers stepped in with more controls, bigger platforms, and increasingly complex technologies to fill the gap.
Over time, this has led to a trade-off. As cloud-first platforms get bigger, they gain more and more control over their customers' commercial model and technical infrastructure. Cloud dependency risk happens when security outcomes depend more on vendor decisions than on operator control. It is the price of more than a decade of cloud-first security tooling, and it shows up in three places:
CADA grades services across four sovereignty levels and steers sensitive workloads towards providers that can show European control, it asks you to demonstrate that control sits in trusted hands and stays there.
The new regulation sets out a single EU sovereignty framework of four assurance levels that public sector bodies apply according to the sensitivity of individual workloads, with providers recognised at a given level by member states after an audit. The more sensitive the workload, the higher the level it calls for.
The effect is that the levels rise with the stakes. A single organisation does not describe itself as a "Level 3-CADA compliant". It describes specific processes according to their risk profile and context. The workloads run by energy, healthcare, and public bodies sit towards the top of that scale, where the field narrows to providers that can show European control end-to-end.
As the central system of record for your security stack your Security Information and Event Management (SIEM) platform is where CADA's three questions are answered.
Sovereign control starts with a physical fact: where your security data sits, and whose law can compel access to it. SIEM runs on-prem, hybrid, or air-gapped, with the same behaviour in every mode, under European jurisdiction end-to-end and no third-country dependency in the supply chain. There is no foreign-law subpoena exposure to explain to a regulator or a board.
Many cloud SIEM vendors already offer "sovereign cloud" services. This is usually a region or a contractual wrapper on a platform that is still cloud-first by design and operated by a provider headquartered under another jurisdiction. But a reassuring clause is not the same as sovereign control, and it is not what CADA's upper assurance levels ask for.
NIS2 made leadership personally accountable for demonstrating that the right measures were in place and operating. CADA adds the sovereignty dimension on top: it is not enough to show that controls work, you must show they work within trusted European control.
A SIEM that you operate inside your own environment gives you a continuous, audit-ready account of who accessed what data, when, under what authorisation. This is evidence you hold, rather than evidence you request from a vendor. When something goes wrong, or when an auditor walks in, you are not waiting on someone else to hand you your own proof.
The business outcome for security leaders that prioritise sovereignty are clear: shorter audit cycles, fewer findings, and a sovereignty claim you can stand behind.
A sovereign deployment is only worth choosing if it survives the next renewal, the next traffic spike, and the next budget round. A SIEM priced by node rather than by ingestion keeps spend anchored to the infrastructure you run, not the data you generate. This removes the dynamic where coverage and compliance become commercial decisions. Equally, a platform with an active on-prem roadmap means staying off the cloud remains a supported direction, not a legacy position your vendor is quietly winding down.
This results in a cost model your finance director can forecast across a multi-year horizon, and the freedom to hold the sovereign choice you made without it growing harder to justify each cycle.
You do not need the final text to begin. The useful work now is to put CADA's questions to the security stack you already run:
Some of these questions will lead to uncomfortable answers; those are the gaps CADA is designed to close. Security leaders who proactively adopt sovereignty will be rewarded with simpler audit preparations, more efficient operations, and a more confident compliance posture.
While CADA is technically a compliance regime, in practice it is something more fundamental: a test of whether you hold sovereign control of your security operation, and whether you can prove it when it counts. It builds on the readiness NIS2 already asked of you, and it points where European procurement is heading regardless of when, or in exactly what form, the proposal becomes law.
As sovereignty moves from a clause in a contract to a property of the architecture itself, the organisations best placed are not those with the largest security budgets. They are the ones that can show where their data lives, who can reach it, and that control stays in trusted hands when an incident or an auditor arrives.
For most organisations, that proof is built or lost at the SIEM — the system that holds the logs, the access evidence, and the audit trail. Deciding now whether yours can answer CADA's questions on your terms is the difference between meeting the moment and scrambling to catch up to it.