Data mastery, technological independence, and strategic autonomy: three dimensions for assessing digital sovereignty.
In September 2025, Bechtle announced the development of a methodology organized in this way. It planned to implement it within its advisory services, supported by a “proprietary software” solution. Deployment was slated for the first quarter of 2026.
Last week, the IT distributor updated on this “sovereignty index”: it is now in pilot mode in three countries (Germany, Austria, Switzerland). As for the substantive content, no details were provided.
SUSE, by contrast, embraced openness. It published, at the end of January, a self-assessment tool aligned with the Cloud Sovereignty Framework. This document, developed at the initiative of the European Commission, is intended to serve as a reference for EU-wide public procurement of cloud services. It defines 8 objectives and lists the underlying challenges. For each objective, an assurance level is determined on a 5-step scale. In addition, a “sovereignty score” is calculated, weighted by objective.
The sovereignty review, SUSE version
SUSE adopts the structure of the Cloud Sovereignty Framework and derives 32 questions from it. We summarize the main ideas here, preserving, as far as possible, the original wording.
| Objective | Assessment points |
| Strategic sovereignty | – Ultimate decision-making authority localized within the EU – Protections in case a supplier comes under non-EU control – Transparency from suppliers on EU investments and the associated roadmap – Ability to continue operations if a foreign entity requires suspending a service |
| Legal sovereignty | – Localized EU staff providing operational support under EU jurisdiction – Exposure of suppliers to foreign extraterritorial laws that could lead to data disclosures – Existence of legal or technical channels enabling access by authorities outside the EU – Contracts explicitly naming an EU court as the exclusive jurisdiction |
| Data/AI sovereignty | – Ability to independently verify sole control of encryption keys – Local EU storage and processing – Visibility into data and metadata access – AI models and data pipelines developed, trained, and operated by EU entities on EU-located infrastructure |
| Operational sovereignty | – Ability to migrate workloads to European alternatives without lock-in – Access to source code and documentation – Ability to manage and patch the stack without involvement from non-EU suppliers – Contractual support guarantees governed by EU jurisdiction and delivered on-site |
| Supply chain sovereignty | – Ability to obtain a complete SBOM of the cloud environment – Degree of dependence on non-European proprietary technologies in critical paths – Ability to verify under which jurisdiction firmware and embedded code are subject to – Development, packaging and software distribution activities placed under EU jurisdiction – Contractual rights to conduct independent supply-chain audits, including for downstream subcontractors |
| Technological sovereignty | – Open-source core with rights to audit, modify, and redistribute – Use of non-proprietary APIs and publicly governable standards (SUSE cites CNCF and OCI) – Visibility into architecture, data flows, and dependencies – Active supplier contributions to the governance of open-source communities |
| Security/compliance sovereignty | – Security Operations Center and incident response teams operating under EU jurisdiction – Security certifications held by suppliers – The ability for EU entities to perform independent security audits – Ability to apply security patches independently of external vendor timelines |
| Environmental sustainability | – Public disclosure of environmental targets (PUE, carbon, water) by suppliers – Circular economy practices – Energy optimization of the software stack |
The user is supposed to estimate their assurance level by following the 5 levels of the Cloud Sovereignty Framework. These levels are, of course, contextualized for each question. This gives, for example, for the very first item (localization of decision-making):
| Level 0 | All operational decisions (incident response, architecture changes, data management, infrastructure provisioning) are made by personnel located outside the EU. |
| Level 1 | Day-to-day operations are managed by EU-based personnel. But escalations and strategic decisions require the agreement of people located outside the EU. |
| Level 2 | Operational authority lies with an EU-based subsidiary and contractual protections are in place. But the parent company retains a veto right over major decisions. |
| Level 3 | There exists an EU-based entity that is autonomous in decision-making for most operations. Non-EU entities are involved, but in a consulting or minority board-seat capacity. |
| Level 4 | All decision-making authority (C-level, board, operations) resides in EU-based personnel, with on-site governance. |
At Red Hat, a structure further from the Cloud Sovereignty Framework…
Red Hat also offers its own self-assessment service, which it launched in mid-February, based on the work of one of its engineers.
Less “flexible” than SUSE’s tool (you cannot skip questions and come back later), this tool is also structured differently. Specifically, it covers seven areas. For each area, there are 3 questions, and you must answer “yes,” “no,” or “I don’t know.” The result, in addition to the overall score, is a maturity level for each domain, on a 4-step scale determined by the number of “yes” responses. Here are the main lines:
| Objectives | Assessment points |
| Data sovereignty | – Respect for local and sector data residence requirements – Exclusive control of encryption keys – Ability to prevent sensitive data from crossing specific geographic boundaries |
| Technical sovereignty | – Ability to mitigate lock-in risks – Prioritization of open-source standards over proprietary APIs – Ability to migrate critical applications to other clouds |
| Operational sovereignty | – Ability to continue operating critical systems in case external cloud services are unavailable – Internal expertise to manage sovereign infrastructure – Incorporation of geopolitical aspects into disaster-recovery strategies |
| “Sovereignty assurance” | – Ability to independently verify security, integrity, and reliability of systems, data, and infrastructure – Control of where security logs and audit trails are stored – Understanding of sovereignty standards applicable at the national level |
| Open source | – Formal policy favoring open-source software – Ability to maintain software independently of a third-party vendor – Active contribution to major open-source projects important for the business |
| Executive oversight | – Executive sponsorship or steering committee for digital sovereignty initiatives – Explicit integration of digital sovereignty into corporate or IT strategy – Dedicated budget for sovereignty initiatives |
| Managed services | – Ability to constrain cloud deployments to specific regions or data centers – Control and monitoring of cloud-provider administrative access – Testing or validation of the ability to migrate workloads to other clouds |
… but a EU-specific tool in the background
The engineer who created Red Hat’s EU-focused tool also developed a version tailored to the EU. It is clearly inspired by the Cloud Sovereignty Framework, adopting its eight objectives, but applying them differently than SUSE. Here is the summary. The EU-specific elements are in bold. The most significant additions are in bold.
| Objective | Assessment points |
| Strategic sovereignty | – EU-established suppliers with local headquarters on site – Protections in case a supplier comes under non-European control – Suppliers primarily financed by EU-based investors or institutions |
| Legal sovereignty | – Contract explicitly under EU jurisdiction – Suppliers not subject to extraterritorial laws that could disclose data – Explicit designation of EU locations for dispute resolution |
| Data/AI sovereignty | – Exclusive control over encryption keys – Data storage and processing within the EU – Contractual guarantees prohibiting use of data and AI models for training or profiling without consent |
| Operational sovereignty | – Documentation and testing of migration strategies – Ability to operate and restore critical systems without relying on non-EU parties – Local EU administrative and support teams |
| Supply chain sovereignty | – Visibility into the supply chain of critical components – Critical software components essentially sourced from European suppliers or open source – Supplier diversification strategy |
| Technological sovereignty | – Use of open standards and interoperable technologies – Ability to migrate critical workloads without significant modifications – Leveraging open-source technologies and contributing to EU-supported projects |
| Security/compliance sovereignty | – SOCs localized exclusively within the EU – Right to conduct audits and on-demand security assessments of the supplier – Storage of security logs, audit trails, and compliance evidence under EU jurisdiction |
| Environmental sustainability | – Suppliers using renewable energy sourced from within the EU – Assessment of environmental impact of cloud services and carbon reduction strategy – Alignment with EU environmental regulations and sustainability development frameworks |
