Cloud Sovereignty Framework: How the EU Is Finally Making Cloud Sovereignty Measurable

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, there is for the first time a structured, verifiable framework for what a cloud service must deliver to qualify as sovereign. This has concrete consequences for providers, operators, and everyone selecting cloud infrastructure for regulated use cases.

What Was Missing and Why the Framework Is Coming Now

Anyone who searched for a sovereign cloud in recent years faced a problem: every provider called itself sovereign, none 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 US and falls under the scope of the CLOUD Act of 2018.

The US CLOUD Act requires American companies to grant US authorities access to stored data upon request, even when that data is physically located in Europe. This is not a theoretical risk but a structural problem that is not solved by a European subsidiary.

At the same time, regulatory pressure has increased. NIS2, DORA, the Cyber Resilience Act, and for public authorities, GDPR-compliant processing of data with elevated protection requirements. In this environment, the lack of clear, verifiable criteria increasingly became an obstacle for procurement decisions.

The new EU framework addresses exactly this. It builds on the EUCS (EU Cybersecurity Certification Scheme for Cloud Services), developed by ENISA, and defines cloud sovereignty as an independent concept with concrete technical, organizational, and legal requirements.

The Three Dimensions of Cloud Sovereignty According to the EU

The framework distinguishes three dimensions that are considered independently but must all be met together to achieve the highest sovereignty level.

Data Sovereignty

Data sovereignty means that processed and stored data remains exclusively in the EU and is only physically accessible by EU-based entities. This sounds like a given, but it is not. Replication to backup data centers outside the EU, automatic log forwarding to the parent company's central monitoring systems, or support access by non-European personnel. All of this can break data sovereignty without being immediately visible.

Operational Sovereignty

Operational sovereignty goes further: who operates the infrastructure, who has privileged access, and where are the subcontractors based? The framework requires that operations, administration, and support are carried out exclusively by EU-based and EU-controlled entities. A US corporation running its European operations through a subsidiary has a structural problem here, as corporate directives, support processes, and security response teams are often not fully decoupled.

Legal Immunity

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 meet this requirement.

The EUCS and the Sovereign SEAL. What Is the Difference?

The EUCS provides three trust levels: Basic, Substantial, and High. These levels cover classic cybersecurity requirements. Availability, integrity, encryption, incident response. A provider at the High level is technically well-secured, but that says nothing about sovereignty.

The Sovereign Level, informally referred to as SEAL, is an additional label that goes beyond the EUCS High level. It combines all three sovereignty dimensions and requires the provider to:

• have its headquarters and control in the EU
• have no corporate dependencies outside the EU that could enable legal access
• have implemented technical controls that prevent data access even in the case of a third-country authority request, through encryption with keys managed exclusively on the EU side

The SEAL label is therefore not a self-declaration but a certification verifiable by accredited bodies. For public authorities and regulated industries, this will increasingly become a prerequisite in tenders.

EUCS Levels and SEAL Levels at a Glance

To clearly separate the concepts, a two-tier picture helps:

• EUCS describes cybersecurity trust levels for cloud services (Basic → Substantial → High).
• SEAL / Sovereign Level describes sovereignty requirements (data sovereignty, operational sovereignty, legal immunity), typically in addition to a high EUCS level.

EUCS Levels

• EUCS Basic: Entry level with fundamental security requirements. Focus on baseline controls and minimum measures. Suitable for workloads with low protection needs where a standard security level is sufficient.
• EUCS Substantial: Mid-level with significantly higher requirements for technical controls, organizational processes, and their implementation. Fits typical enterprise workloads with medium risk where security must be reliably and repeatably operated.
• EUCS High: Highest EUCS level for highly critical or heavily regulated scenarios. Particularly stringent controls, robust operational processes, and auditability and evidence management are the focus here.

Important: A service can meet EUCS High and still not be "sovereign" if, for example, non-European corporate or legal dependencies exist.

3) SEAL / Sovereign Level (In Detail)

The SEAL (Sovereignty Effectiveness Assurance Level) addresses exactly this gap and supplements EUCS (particularly 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 through SOV-8). For each of these objectives, a SEAL level (typically 0 to 4) is assigned, expressing the maturity or effectiveness of the measures.

The 8 SEAL Assessment Areas (Sovereignty Objectives)

(Each area is assessed separately with a SEAL level.)

• SOV-1 Strategic Sovereignty: Control over governance, ownership, strategic direction, "who decides."
• SOV-2 Legal Sovereignty: Exposure to non-EU law and ability to prevent third-country access.
• SOV-3 Operational Sovereignty: Operational and support capability within the EU, including emergency and escalation capability.
• SOV-4 Data/Control Sovereignty: Demonstrable control over data location, data flows, and processing (including side channels such as telemetry).
• SOV-5 Supply Chain Sovereignty: Transparency and manageability of critical supply chain and sub-processor dependencies.
• SOV-6 Technological Sovereignty: Avoidance of critical technical lock-ins, traceability, and replaceability of central components.
• SOV-7 Security and Compliance Sovereignty: Security controls, evidence, audits, and EU-compliant implementation in practice.
• SOV-8 Environmental/Sustainability Aspects: Energy efficiency, controlled footprint, and measurable sustainability requirements.

What the SEAL Levels Practically Express (0–4)

• SEAL-0: No relevant sovereignty demonstrable.
• SEAL-1: Basic fulfillment (EU law/rules formally addressed), but strong non-EU dependencies.
• SEAL-2: Material sovereignty measures in place, but still relevant external dependencies.
• SEAL-3: High degree of EU control and operational independence, external influences strongly limited.
• SEAL-4: Very high to complete digital sovereignty in this target area, with minimal critical non-EU dependencies.

Typical core elements found across many SOV objectives include:

• Data Sovereignty: Data processing and storage in the EU. No hidden data outflows via telemetry, support tools, or subsystems.
• Operational Sovereignty: Operations, administration, and support by EU-based, EU-controlled entities. Subcontractor rules are strict and must be fully transparent.
• Legal Immunity: Minimization or exclusion of third-country legal access (e.g., extraterritorial access laws). This is why pure "EU region" offerings from US hyperscalers structurally hit their limits.
• Key Sovereignty (Practical Lever): Encryption is not enough. What matters is that key management is implemented so that third parties cannot force access because the keys are controlled on the EU side.

What This Means for Hyperscalers

AWS, Microsoft Azure, and Google Cloud all have European data centers, European subsidiaries, and have announced or already launched dedicated "Sovereign Cloud" offerings. Nevertheless, they structurally cannot achieve the Sovereign Level because the parent company in each case is based in the US, is subject to US securities law, and thus to the CLOUD Act.

Individual attempts to work around this, for example through joint ventures with European partners such as the project between Thales and Google or T-Systems and Microsoft, are technically demanding and organizationally complex. They reduce the risk but do not fully resolve the structural problem. The framework sets the bar so that genuine decoupling is necessary, not just contractual safeguards.

This is not hidden protectionism but a factual consequence of the stated requirements. Anyone who must demonstrate legal immunity from the CLOUD Act can only do so when no US corporation stands in the background.

Technical Requirements in Detail

Anyone pursuing certification must demonstrate concrete 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 entities. An external key management service from the provider, accessible only to the customer (Bring Your Own Key / Hold Your Own Key), can meet this requirement – if it is itself operated in a sovereign manner.

Access Controls: Privileged access to production systems must be fully logged, restricted to EU personnel, and secured by technical measures against unscheduled access. Break-glass processes must be documented and auditable.

Subcontractors: Every 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 only at the application level but down to the infrastructure level.

What Cloud Sovereignty Is Not. The Distinction from GDPR

A common misconception: 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. Data processing agreement, data protection impact assessment, standard contractual clauses – and still be structurally vulnerable to a US authority demanding access to data based on the CLOUD Act. The framework makes this distinction explicit. Sovereignty is a separate dimension that goes beyond data protection law.

Relevance for Kubernetes PaaS Platforms

For operators and users of Kubernetes-based PaaS platforms, the framework has direct consequences. A platform operated on non-sovereign infrastructure inherits its weaknesses – no matter how well the application layer itself is secured. Sovereign by design means that the infrastructure layer on which the platform runs already meets the framework's requirements.

This is the approach lowcloud takes: a fully European-controlled platform running on infrastructure that is structurally suitable for the Sovereign Level. For development teams, this means they can work cloud-native. With familiar Kubernetes workflows, without making sovereignty compromises.

The EU Cloud Sovereignty Framework now also gives this approach a formal framework. Instead of "we are hosted in Germany," there will be verifiable criteria in the future against which providers must be measured.

Outlook: What Comes Next

The framework was initially published as an orientation framework. The final adoption of the EUCS by EU member states is still pending. There have been political tensions in the past, particularly around the question of whether the Sovereign Level effectively excludes US hyperscalers. It does, and this is politically controversial.

Nevertheless: the direction is clear. Public authorities and companies in regulated industries will increasingly ask for certified sovereign cloud services in tenders. Those who invest in sovereign infrastructure now are prepared for these requirements – those who wait will have to migrate under time pressure later.

If you want to know what a Kubernetes PaaS platform on sovereign infrastructure looks like in practice and what it means for your stack, check out how lowcloud implements it. Without vendor lock-in, without compromises on sovereignty.