Cloud sovereignty is a term that has appeared in tenders, strategy papers and press releases for years. Often without a clear definition. The EU has now changed that. With the new Cloud Sovereignty Framework, for the first time there is a structured, verifiable framework for what a cloud service must provide in order to be considered sovereign. This has concrete consequences for providers, operators and anyone who selects cloud infrastructure for regulated use cases.
Anyone looking for a sovereign cloud in recent years was faced with a problem: every provider called itself sovereign, but no one had to prove it. European subsidiaries of American hyperscalers marketed their data centers in Frankfurt or Dublin as "EU-sovereign", even though the parent company is based in the USA and falls under the scope of the CLOUD Act of 2018.
The US CLOUD Act obliges American companies to grant US authorities access to stored data upon request, even if this data is physically located in Europe. This is not a theoretical risk, but a structural problem that is not solved by a European branch.
At the same time, regulatory pressure has increased. NIS2, DORA, the Cyber Resilience Act and, for public authorities, the GDPR-compliant processing of data with increased protection requirements. In this environment, the lack of clear, verifiable criteria has increasingly become an obstacle to procurement decisions.
This is precisely where the new EU framework comes in. It builds on the EUCS (EU Cybersecurity Certification Scheme for Cloud Services), which was developed by ENISA, and defines cloud sovereignty as an independent concept with specific technical, organizational and legal requirements.
The framework distinguishes between three dimensions, which are considered independently of each other, but all three must be fulfilled in order to achieve the highest level of sovereignty.
Data sovereignty means that the processed and stored data remains exclusively in the EU and can only be physically accessed by EU-based bodies. This sounds like a matter of course, but it is not. Replication in backup data centers outside the EU, automatic log forwarding to central monitoring systems of the parent company or support access by non-European personnel. All of this can break data sovereignty without it being visible at first glance.
Operational sovereignty goes further: who operates the infrastructure, who has privileged access and where are the subcontractors located? The framework requires that operation, administration and support are carried out exclusively by EU-based and EU-controlled entities. A US group that runs its European operations via a subsidiary has a structural problem here, as group instructions, support processes and security response teams are often not completely decoupled.
This is the toughest requirement: the cloud provider must not be subject to any non-European jurisdiction that could allow authorities to access customer data. This includes US, British or other third-country laws with extraterritorial scope. Only European-controlled companies without a US parent company or US stock exchange listing can structurally fulfill this requirement.
The EUCS provides for three confidence levels: Basic, Substantial and High. These levels cover classic cybersecurity requirements. Availability, integrity, encryption, incident response. A provider at High level is technically well secured, but that says nothing about sovereignty.
The sovereign level, also known informally as SEAL, is an additional label that goes beyond the EUCS high level. It combines all three dimensions of sovereignty and requires that the provider:
The SEAL label is therefore not a self-declaration, but a certification that can be verified by accredited bodies. In the future, this will become a prerequisite for public authorities and regulated industries when tendering for contracts.
A two-level picture helps to clearly separate the terms:
Important: A service can fulfill EUCS High and still not be "sovereign" if, for example, there are non-European group or legal dependencies.
The SEAL (Sovereignty Effectiveness Assurance Level) addresses precisely this gap and supplements EUCS (especially EUCS High) with sovereignty criteria. In the framework, a cloud service is not assessed "once overall", but along 8 sovereignty objectives (Sovereignty Objectives, often referred to as SOV-1 to SOV-8). A SEAL level (typically 0 to 4) is assigned for each of these objectives, which expresses the degree of maturity or effectiveness of the measures.
(Each area is assessed separately with a SEAL level)
Typical core elements that can be found in many SOV objectives are
AWS, Microsoft Azure and Google Cloud have all announced or already introduced European data centers, European subsidiaries and in some cases dedicated "Sovereign Cloud" offerings. Nevertheless, they cannot structurally reach the sovereign level because the parent company is based in the USA, is subject to US stock exchange law and is therefore subject to the CLOUD Act.
Individual attempts to circumvent this, for example through joint ventures with European partners such as the project between Thales and Google or T-Systems and Microsoft, are technically costly and organizationally complex. They reduce the risk, but do not completely solve the structural problem. The framework sets the bar in such a way that genuine decoupling is necessary, not just contractual protection.
This is not hidden protectionism, but a factual consequence of the requirements. Anyone who has to prove legal immunity from the CLOUD Act can only do so if there is no US corporation in the background.
Anyone seeking certification must provide evidence of specific technical measures. The most important ones:
Encryption: Data must be encrypted both at-rest and in-transit. This is standard - but the decisive factor is who controls the keys.
Key management: Cryptographic keys may only be managed by EU-based bodies. An external key management service of the provider, to which only the customer has access (Bring Your Own Key / Hold Your Own Key), can fulfill this requirement - if it is operated by a sovereign entity.
Access controls: Privileged access to production systems must be fully logged, restricted to EU personnel and secured against unscheduled access by technical measures. Break-glass processes must be documented and auditable.
Subcontractors: Any subcontractor that could potentially have access to customer data must meet the same requirements as the main provider. No silent sub-processors from third countries.
Logging and auditing: Complete, tamper-proof logs of all data access - not just at application level, but right down to infrastructure level.
A common misunderstanding: GDPR compliance is not the same as cloud sovereignty. The GDPR regulates how personal data may be processed. It says nothing about whether a provider is exposed to non-European legal access.
A service can be fully GDPR-compliant. processing agreement, data protection impact assessment, standard contractual clauses and still be structurally vulnerable to a US authority being able to demand access to the data on the basis of the CLOUD Act. The framework makes this difference explicit. Sovereignty is a separate dimension that goes beyond data protection law.
The framework has direct consequences for operators and users of Kubernetes-based PaaS platforms. A platform that is operated on non-sovereign infrastructure inherits its weaknesses - regardless of how well its own application layer is secured. Sovereign by design means that the infrastructure layer on which the platform runs already fulfills the requirements of the framework.
This is the approach taken by lowcloud: a fully European-controlled platform that runs on infrastructure that is structurally suitable for the sovereign level. For development teams, this means that they can work cloud-natively. With the familiar Kubernetes workflows, without compromising sovereignty.
The EU Cloud Sovereignty Framework now also provides a formal framework for this approach. Instead of "we are hosted in Germany", in future there will be verifiable criteria against which providers must be measured.
The framework has initially been published as an orientation framework. The final adoption of the EUCS by the EU member states is still pending. There have been political tensions here in the past, particularly around the question of whether the sovereign level effectively excludes US hyperscalers. It does and this is not politically uncontroversial.
Nevertheless, the direction is clear. Authorities and companies in regulated industries will increasingly ask for certified sovereign cloud services in tenders. Those who rely on sovereign infrastructure now are prepared for these requirements - those who wait will have to migrate later under time pressure.