Digital Sovereignty in the Cloud

Digital sovereignty is not settled by GDPR compliance. What matters is who determines whether, where, and under which law your computations take place — across six levers: compute and infrastructure, industrial ecosystems, platforms, standards, value creation, and structural position. Sovereignty does not arise in any single layer, but from the alignment of all of them.

The GDPR requires that data does not leave EU jurisdiction; the US CLOUD Act allows US authorities to access data held by US-controlled providers — regardless of where it is stored. In June 2025, Microsoft stated before a French court that it could not guarantee sovereignty against the CLOUD Act. A data center in Frankfurt does not resolve this conflict as long as the provider is subject to US law.

The EU SEAL framework defines eight weighted, auditable sovereignty objectives and five tiers — from SEAL 1 (baseline) through SEAL 2 (personal data) and SEAL 3 (critical infrastructure) up to SEAL 5 (national security). The BSI catalog C3A v1.0 of April 27, 2026 operationalizes the framework for Germany with the criteria areas SOV-1 to SOV-6. This makes it possible to objectively assess the sovereignty position of a cloud deployment and to anchor it in tenders.

Encryption only protects if the provider does not hold the keys itself: for sensitive data, customer-held encryption keys instead of a provider KMS are mandatory (C3A SOV-3), complemented by documented exit paths for data and services. At the same time, the EuroStack initiative shows that a European stack genuinely exists — from cloud and compute (OVHcloud, STACKIT, Scaleway) to applications and AI (Mistral, Aleph Alpha).

The EU declaration on digital sovereignty (late 2025) was followed by the EU Cloud and AI Development Act and, in April 2026, by the SEAL framework together with a cloud sovereignty tender worth €180 million and the BSI C3A v1.0. Sovereignty is thus shifting from a marketing term to an auditable category. Beware of sovereignty washing: “data stays in the EU” is no proof if the provider's registered seat brings the CLOUD Act into play.

First, classify workloads by sovereignty criticality (C3A SOV-1); second, audit a baseline against the criteria areas of law, operations, and supply chain. Third, document exit plans for data and service paths; fourth, anchor SEAL tiers as an award criterion in RFPs — for example SEAL 2 for personal data and SEAL 3 for critical infrastructure. Fifth, establish key control: customer-held encryption keys, and no provider KMS for sensitive data.