An Operational Definition for Digital Sovereignty

The ambiguity of ‘digital sovereignty’

The EU Tech Sovereignty Package, with the Cloud and AI Development Act at its centre, is expected to arrive on 27 May into a political environment in which digital sovereignty has become one of the most heavily contested phrases in European policy. The concern it expresses is genuine and widely shared. The difficulty is that the concept has accommodated so many different interpretations that it no longer functions as a precise policy objective. 

Data centres on European soil are sovereign. A European holding company wrapping a US software stack is sovereign. A contractual clause asserting jurisdictional compliance while the underlying system remains proprietary and practically immovable is, according to some participants in this debate, also sovereignty.

For the hospitals, energy utilities, financial institutions and public administrations that live with technology dependencies every day, this ambiguity creates a practical problem. If sovereignty can describe all of these arrangements, what exactly is the legislation supposed to deliver for them?

Measuring resilience through choice

There is a more testable frame, and it is one that IT leaders can apply directly: choice. Not the theoretical choice available at the moment of procurement, but the operational choice available when circumstances change. Recent research in the SUSE Navigating Digital Resilience 2026 report backs this up: IT leaders increasingly define resilience not just as “uptime,” but as the ability to maintain control and pivot when technology or geopolitical landscapes shift. Real choice in enterprise IT has two components: 

• The first is exit velocity:  how quickly, at what cost, and with what operational disruption can you leave a provider your organization has chosen to exit, and can you break free from influences of a single vendor?
• The second is pivotability: as circumstances change geopolitically, commercially or operationally, how easily can you adapt your infrastructure without rebuilding from the ground up?

These are the questions that CIOs in hospitals, energy utilities and public administrations raise with us directly. The answer, in most cases, is that exit velocity is low and pivotability is limited. Not because organisations lack the legal authority to switch vendors, but because the architecture of the systems they are running makes movement prohibitively expensive in practice. The contracts can be terminated. The migration cannot be completed in any reasonable timeframe or at any manageable cost.

The role of open architecture and SEAL levels

This is the dependency that sovereignty policy is designed to address. And it is a dependency that geography and jurisdictional compliance alone cannot resolve. An organisation can satisfy every geographic criterion and still find itself structurally unable to leave a provider, because the software infrastructure it depends on is proprietary, non-interoperable and practically irreplaceable. The sovereignty claim is technically accurate, but the organisation’s operational position has not changed. This is why a staggering 94% of IT leaders now consider open source as “very or extremely important” to their resilience strategy. It addresses the issue at the level of architecture rather than contract.

Open source software and open standards address this at the level of architecture rather than contract. When the code is open, it can be audited by the organisation running it, maintained by any qualified provider, and replaced without the original vendor’s cooperation. Exit velocity improves not because a vendor has made a promise, but because the architecture makes movement structurally possible.

Evaluating your infrastructure with the Cloud Sovereignty Framework

The European Commission’s own Cloud Sovereignty Framework begins to capture this distinction through its Sovereignty Effectiveness Assurance Levels. At SEAL-1 and SEAL-2, EU law formally applies and data is protected through legal and contractual mechanisms, but the underlying technology remains the provider’s proprietary stack. Organisations operating at these levels retain jurisdiction without gaining genuine operational independence. It is only from SEAL-3 onwards, where open architecture becomes a requirement, that exit velocity begins to improve in any meaningful way. At SEAL-4, where open source is the standard, the choice that sovereignty policy promises becomes structurally real. To understand where your infrastructure sits today, you can utilise this Cloud Sovereignty Framework Assessment to evaluate your current assurance level.

Building institutional capacity for the future

CAIDA should provide much needed clarity on how this framework will set an easy-to-follow standard. The criteria for its highest assurance levels should explicitly prioritize system architecture. A truly future-proof strategy must look beyond simple data residency to these deeper architectural requirements. Geography is a condition for digital sovereignty in a few cases. It is not, on its own, a sufficient one.

Closing the expertise gap

One further point not directly linked to the architecture deserves emphasis: Open source and open standards create the legal right to exit. It does not automatically create the institutional capability to exercise that right. Organisations need access to qualified, EU-based support to make use of the freedoms open source provides. Mandate and operational capacity need to develop together, or the rights the policy establishes will remain theoretical for the very organisations it was designed to protect. This is a critical gap: the research shows that 1 in 4 organisations cite a lack of internal expertise as their primary barrier to sovereignty. Mandate and operational capacity must develop together.

CAIDA will ultimately be judged not by how many times it mentions the word “sovereignty” but by whether the IT leaders responsible for European critical infrastructure have meaningfully more operational choice in 2027 than they do today. That is a test with an observable answer, and it is the right one to apply.

The blueprint is ready

Defining digital sovereignty is only the first step. To move from theory to implementation, we must understand how the regulatory landscape in Europe is shifting to support these goals.