Frameworks for digital sovereignty in cloud infrastructures
Digital sovereignty of the Sovereign Cloud Stack
From the outset, the Sovereign Cloud Stack (SCS) initiative has focused on defining digital sovereignty as more than just data control. Inspired by the Definition of the 2018 Digital Summit Based on extensive discussions about the needs of infrastructure users, the SCS project defined four key areas of digital sovereignty in which the requirements were systematically summarised:
- Data sovereignty (SCS-1):
The ability to store and process data securely and to maintain control over who it is shared with. Security, control mechanisms and legal safeguards are fundamental requirements for ensuring this.
- Supplier changeability (SCS-2):
Avoiding lock-in effects caused by the use of services or APIs that are only available from one (or very few) providers, making it difficult to switch or federate infrastructure providers.
- Technological sovereignty (SCS-3):
The ability to freely use, study, adapt and further develop cloud technologies. This benefits providers and thus indirectly also users – and directly those who operate their own infrastructure if they consider this to be advantageous.
- Operational competence (SCS-4):
Documentation and transparency in the context of operational tools and processes, with the aim of building the capabilities needed to reliably operate an infrastructure platform. This also enables smaller players to successfully operate cloud platforms for their own needs or for external customers.
This definition was adopted in 2022 in the Cloud Report and in the magazine „Data protection and data security“ published and was instrumental in the strategic discussions in the Sovereign Cloud Stack project. Although it has not been officially adopted by any standardisation organisation, it has undoubtedly inspired others to think beyond data sovereignty – for example, the GovStack project. The definition has been used in many discussions, both on stage and off, and has proven to be extremely effective and sustainable.
The current geopolitical situation is increasingly motivating organisations to carefully examine their resilience and dependencies. Some of these discussions are getting out of hand – for example, through attempts to cause confusion by claiming that digital sovereignty is not clearly defined, or through providers trying to portray their existing offerings as „sovereign“ („sovereign washing“) by offering minimal protection measures against foreign data access.
Organisations interested in genuine IT resilience should not be misled by such marketing strategies.
EU Commission
A few days ago, the European Commission published its Cloud sovereignty framework published, which takes a broad view of sovereignty. The EuroStack initiative has a comparison with their own definition. Overall, this is good news – even if the multitude of different perspectives may seem confusing at first glance, they complement each other well. This will be explained in more detail in the next section.
Comparison of the sovereignty categories of the European Commission, the SCS and EuroStack
The following table compares the European Commission's sovereignty objectives with the SCS sovereignty categories.
| Sovereignty objectives of the European Commission | Description | SCS |
|---|---|---|
| SOV-1: Strategic Sovereignty (15 %) | EU authority with protection against change of control, financing from EU funds, investment and job creation in the EU, participation in EU initiatives, and resilience to service interruption requests | SCS enables local providers to operate, but does not have a corresponding sovereignty category. |
| SOV-2: Legal and judicial sovereignty (10 %) | Applicable law, protection from the application of non-EU law, international regulations, location of intellectual property | This is part of the SCS definition of data sovereignty (SCS-1), which excludes data access based on legal systems that are not recognised by the EU. |
| SOV-3: Data and AI sovereignty (10 %) | Control over data and encryption keys lies with the customer (not the provider); transparency in data access and the option of permanent deletion; data storage and processing exclusively within the EU, without recourse to non-European systems; AI models under EU control, based on European technology stacks. | Local providers should have appropriate processes in place to ensure secure operation. The software from the SCS ecosystem supports this, for example, with data encryption functions and the integration of hardware security modules (HSM). Data sovereignty (SCS-1) forms the basis for this, without which the other categories in the SCS taxonomy are only effective to a limited extent. |
| SOV-4: Operational sovereignty (20 %) | Avoiding vendor lock-in by supporting migration to other EU vendors; operational skills of EU personnel; talent pool; operational support from suppliers subject to EU law; full availability of technical documentation, source code and operational know-how for long-term autonomy; location of critical suppliers. | The operational skills (SCS-4) of the SCS pursue very similar goals – but go one step further by considering transparency not only for providers but also for users. The avoidance of provider dependencies is addressed in the SCS taxonomy by the category Provider Switching Capability (SCS-2), which requires the provision of standardised APIs and system behaviour. |
| SOV-5: Supply chain sovereignty (20 %) | Location of hardware assembly, origin of firmware, location and legal framework of software development, architecture, packaging, distribution and governance; dependence on non-EU suppliers or proprietary technologies; transparency in the supply chain with inspection and audit rights. | SCS expressly supports the development and use of open hardware, but does not aim to intervene in hardware production itself. With its category of technological sovereignty (SCS-3), SCS uses only openly developed open-source code in its reference implementations. This open development model and the corresponding licences ensure broad empowerment of users. SCS does not consider the geographical location of contributors or governance structures to be relevant, as long as the code is openly developed open-source code. |
| SOV-6: Technological sovereignty (15 %) | Possibility of integration with other technology via well-documented, non-proprietary APIs or protocols, ideally based on widely used standards; open-source availability of the software; architectural documentation; independence in terms of HPC (high-performance computing) capabilities. | Standardised and widely used interfaces and protocols are a key component in meeting the requirements of Provider Switching Capability (SCS-2). The use of open-source software, in turn, is crucial for implementing technological sovereignty (SCS-3) in the SCS model. SCS attaches great importance to open-source software being developed openly in order to avoid control by individual providers – a risk that has already led to open-source releases being discontinued several times in the industry. |
| SOV-7: Security and compliance sovereignty (10 %) | Certifications (e.g. ISO, ENISA), compliance with GDPR, NIS, DORA, etc.; Security Operations Centres and Incident Response Teams under EU jurisdiction; security monitoring, control by customers or EU authorities, EU-compliant reporting of security incidents, patch management capabilities, and support for EU security audits. | Some SCS providers have ISO and BSI certifications. The software from the SCS ecosystem supports timely security updates by using CI (continuous integration) systems and publishes security alerts for critical vulnerabilities. This is part of SCS's data sovereignty approach (SCS-1). |
| SOV-8: Environmental sustainability (5 %) | Energy-efficient infrastructure (e.g. PUE), circular economy, recording of CO₂ emissions and water consumption. | This area is not covered by SCS itself – however, SCS supports the sister project. ECO:DIGIT, which deals with the resource consumption of cloud infrastructures as part of the environmental impact of software applications. |
Compared to the EuroStack commentary, SCS places a much stronger focus on open source, while the principle of „Buy European!“ plays a lesser role.
Compared to the US market, the structure of the European market favours smaller providers; European players are therefore at a disadvantage, particularly in platform markets with pronounced network effects. However, this disadvantage can be offset by close cooperation – and by far the most effective way to do this is through cooperation in the open source sector.
Open-source software developed openly naturally gives its users and contributors a high degree of control and influence – making the geographical location of the contributors or even the headquarters of the supporting organisation a secondary issue. The situation is different for open-source projects that are controlled by a single provider, and of course for proprietary software. Nevertheless, we would like to see more contributions to open source from European developers – especially from large companies, as we see a clear difference between Europe and the US in this regard.
In open source communities, influence is gained through active contributions; a good governance model (as typically promoted by open source foundations) emphasises meritocracy and the recognition of achievement within the community. The risk of a hostile takeover of governance is correspondingly low in such projects. With increasing European participation, it is to be expected that more open source projects will also be formally managed from Europe in the future.
When analysing digital sovereignty in the context of infrastructure solutions, SCS systematically considers the issue from the perspective of user organisations: What dependencies and associated risks exist for users? Heavy dependence on a single provider weakens resilience, even if that provider is European (and therefore subject to lower geopolitical risks). The ability to switch providers (SCS-2) and the strong focus on open source (SCS-3) and open operations (SCS-4) are direct consequences of this approach. Within the European Commission, this user focus has not been developed with the same clarity. In summary, it can be said that the EU Commission's sovereignty framework is largely based on the SCS categories and represents a very comprehensive concept overall. While SCS does not explicitly cover strategic and environmental aspects, it places greater emphasis on empowering user organisations. Given the original starting point of the debate – namely „sovereign washing“ marketing strategies – these are relatively minor differences, and the high degree of substantive agreement is very encouraging overall.
A turning point?
There has been much talk about digital sovereignty this year – with the quality of the discourse varying greatly. As there has been no official definition from a recognised institution to date, interested parties have been able to deliberately unsettle the market – which has significantly slowed down the spread of truly sovereign solutions. The European Commission's definition is now changing that.
We can expect strong criticism from these interested parties – for example, the argument that sticking to all these goals will slow down digitalisation, innovation and competitiveness in Europe. But that is a good sign: it shows that the Commission is on the right track. Or, to quote Mahatma Gandhi, probably incorrectly attributed quote To say: It shows that the sovereignty movement has left behind the phase of being ignored.
However, the European Commission's Cloud Sovereignty Framework will only be effective if it is specifically applied and implemented.
The current procurement procedure of the Directorate-General for Digital and Communications (DG DIGIT) follows precisely this approach: In its Procurement procedure worth over 180 million euros the focus is on digital sovereignty, with minimum requirements for achieving the sovereignty goals set out in the framework.
The contract can be awarded to up to four providers, which increases resilience, even if explicit compatibility between them is not required. This is an extremely positive development for all those communities, organisations and companies that have invested time and resources in recent years in building sovereign structures – in infrastructure expertise, open source projects and, more generally, in platforms that empower users rather than locking them in. There is justified hope that their work will now finally be recognised. It is to be expected that other public institutions pursuing similar goals to the European Commission, as well as private companies with high resilience requirements, will follow suit – by referring to the framework, placing greater emphasis on resilience criteria and anchoring minimum requirements in their tenders. The time when Europe could ignore the new geopolitical realities should finally be over! If that happens, we could look back on this moment as the point at which a new market for truly sovereign IT infrastructure platforms emerged, a real „turning point“ moment. And we very much hope that this will be the case.
