Cloud Sovereignty Framework: Wie die EU Cloud-Souveränität endlich messbar macht

Cloud-Souveränität ist ein Begriff, der in Ausschreibungen, Strategiepapieren und Pressemitteilungen seit Jahren auftaucht. Oft ohne klare Definition. Die EU hat das jetzt geändert. Mit dem neuen Cloud Sovereignty Framework gibt es erstmals einen strukturierten, prüfbaren Rahmen dafür, was ein Cloud-Dienst leisten muss, um als souverän zu gelten. Das hat konkrete Folgen für Anbieter, Betreiber und alle, die Cloud-Infrastruktur für regulierte Anwendungsfälle auswählen.

Was bisher fehlte und warum das Framework jetzt kommt

Wer in den letzten Jahren nach einer souveränen Cloud gesucht hat, stand vor einem Problem: Jeder Anbieter nannte sich souverän, keiner musste das belegen. Europäische Tochtergesellschaften amerikanischer Hyperscaler vermarkteten ihre Rechenzentren in Frankfurt oder Dublin als "EU-souverän", obwohl der Mutterkonzern in den USA sitzt und unter dem Geltungsbereich des CLOUD Act von 2018 steht.

Der US CLOUD Act verpflichtet amerikanische Unternehmen, US-Behörden auf Anfrage Zugang zu gespeicherten Daten zu gewähren, auch wenn diese Daten physisch in Europa liegen. Das ist kein theoretisches Risiko, sondern ein strukturelles Problem, das durch eine europäische Niederlassung nicht gelöst wird.

Gleichzeitig ist der regulatorische Druck gestiegen. NIS2, DORA, der Cyber Resilience Act und für Behörden die DSGVO-konforme Verarbeitung von Daten mit erhöhtem Schutzbedarf. In diesem Umfeld wurde der Mangel an klaren, überprüfbaren Kriterien zunehmend zum Hemmnis für Beschaffungsentscheidungen.

Das neue EU-Framework setzt genau hier an. Es baut auf dem EUCS (EU Cybersecurity Certification Scheme for Cloud Services) auf, das von ENISA entwickelt wurde, und definiert Cloud-Souveränität als eigenständiges Konzept mit konkreten technischen, organisatorischen und rechtlichen Anforderungen.

Die drei Dimensionen von Cloud-Souveränität laut EU

Das Framework unterscheidet drei Dimensionen, die unabhängig voneinander betrachtet werden, aber alle drei zusammen erfüllt sein müssen, um das höchste Souveränitätsniveau zu erreichen.

Datenhoheit

Datenhoheit bedeutet, dass die verarbeiteten und gespeicherten Daten ausschließlich in der EU verbleiben und nur von EU-ansässigen Stellen physisch zugänglich sind. Wichtig: Datenhoheit ist nicht dasselbe wie Datenresidenz – der Unterschied ist entscheidend. Das klingt nach einer Selbstverständlichkeit, ist es aber nicht. Replikation in Backup-Rechenzentren außerhalb der EU, automatische Log-Weiterleitungen in zentrale Monitoring-Systeme des Mutterkonzerns oder Support-Zugänge durch außereuropäisches Personal. All das kann Datenhoheit brechen, ohne dass es auf den ersten Blick sichtbar ist.

Betriebshoheit

Betriebshoheit geht weiter: Wer betreibt die Infrastruktur, wer hat privilegierten Zugriff, und wo sitzen die Subauftragnehmer? Das Framework verlangt, dass Betrieb, Administration und Support ausschließlich durch EU-ansässige und EU-kontrollierte Stellen erfolgen. Ein US-Konzern, der seinen europäischen Betrieb über eine Tochtergesellschaft führt, hat hier strukturell ein Problem, denn Konzernweisungen, Supportprozesse und Security-Response-Teams sind oft nicht vollständig entkoppelt.

Rechtliche Immunität

Das ist die härteste Anforderung: Der Cloud-Anbieter darf keiner außereuropäischen Rechtsprechung unterliegen, die Behörden den Zugriff auf Kundendaten erlauben könnte. Das schließt US-amerikanische, britische oder andere Drittstaatengesetze mit extraterritorialem Geltungsbereich ein. Nur europäisch kontrollierte Unternehmen ohne US-Konzernmutter oder US-Börsennotierung können diese Anforderung strukturell erfüllen.

Das EUCS und das Sovereign-SEAL. Was ist der Unterschied?

Das EUCS sieht drei Vertrauensniveaus vor: Basic, Substantial und High. Diese Niveaus decken klassische Cybersecurity-Anforderungen ab. Verfügbarkeit, Integrität, Verschlüsselung, Incident Response. Ein Anbieter auf High-Niveau ist technisch gut abgesichert, aber das sagt noch nichts über Souveränität aus.

Das Sovereign-Level, informell auch als SEAL bezeichnet, ist ein zusätzliches Label, das über das EUCS-High-Niveau hinausgeht. Es kombiniert alle drei Souveränitätsdimensionen und setzt voraus, dass der Anbieter:

• seinen Hauptsitz und seine Kontrolle in der EU hat
• keine Konzernabhängigkeiten außerhalb der EU hat, die Rechtszugriffe ermöglichen könnten
• technische Kontrollen implementiert hat, die auch im Falle einer Behördenanfrage aus Drittstaaten keinen Datenzugang ermöglichen, durch Verschlüsselung mit ausschließlich EU-seitig verwalteten Schlüsseln

Das SEAL-Label ist damit keine Selbstauskunft, sondern eine durch akkreditierte Stellen prüfbare Zertifizierung. Für Behörden und regulierte Branchen wird das perspektivisch zur Voraussetzung bei Ausschreibungen werden.

EUCS-Niveaus und SEAL-Level im Überblick

Um die Begriffe sauber zu trennen, hilft ein zweistufiges Bild:

• EUCS beschreibt Cybersecurity-Vertrauensniveaus für Cloud-Services (Basic → Substantial → High).
• SEAL / Sovereign Level beschreibt Souveränitätsanforderungen (Datenhoheit, Betriebshoheit, rechtliche Immunität), typischerweise zusätzlich zu einem hohen EUCS-Niveau.

EUCS Niveaus

• EUCS Basic: Einstiegsniveau mit grundlegenden Sicherheitsanforderungen. Fokus auf Basiskontrollen und Mindestmaßnahmen. Geeignet für Workloads mit niedrigem Schutzbedarf, bei denen ein Standard-Sicherheitsniveau ausreicht.
• EUCS Substantial: Mittleres Niveau mit deutlich höheren Anforderungen an technische Kontrollen, organisatorische Prozesse und deren Umsetzung. Passt zu typischen Unternehmens-Workloads mit mittlerem Risiko, bei denen Security verlässlich und wiederholbar betrieben werden muss.
• EUCS High: Höchstes EUCS-Niveau für hoch kritische bzw. stark regulierte Szenarien. Hier stehen besonders strenge Kontrollen, robuste Betriebsprozesse sowie Auditierbarkeit und Nachweisführung im Vordergrund.

Wichtig: Ein Dienst kann EUCS High erfüllen und trotzdem nicht „souverän" sein, wenn zum Beispiel außereuropäische Konzern- oder Rechtsabhängigkeiten bestehen.

3) SEAL / Sovereign Level (detaillierter)

Das SEAL (Sovereignty Effectiveness Assurance Level) adressiert genau diese Lücke und ergänzt EUCS (insbesondere EUCS High) um Souveränitätskriterien. Im Framework wird ein Cloud-Service dabei nicht „einmal insgesamt" bewertet, sondern entlang von 8 Souveränitätszielen (Sovereignty Objectives, oft als SOV-1 bis SOV-8 bezeichnet). Für jedes dieser Ziele wird ein SEAL-Level (typischerweise 0 bis 4) vergeben, das den Reifegrad bzw. die Wirksamkeit der Maßnahmen ausdrückt.

Die 8 SEAL-Bewertungsbereiche (Sovereignty Objectives)

(Jeder Bereich wird separat mit einem SEAL-Level bewertet.)

• SOV-1 Strategische Souveränität: Kontrolle über Governance, Eigentum, strategische Ausrichtung, „wer entscheidet".
• SOV-2 Rechtliche Souveränität: Exponiertheit gegenüber Nicht-EU-Recht und Fähigkeit, Drittstaaten-Zugriffe zu verhindern.
• SOV-3 Operative Souveränität: Betriebs- und Supportfähigkeit innerhalb der EU, inklusive Notfall- und Eskalationsfähigkeit.
• SOV-4 Daten-/Kontrollsouveränität: Nachweisbare Kontrolle über Datenlokation, Datenflüsse und Verarbeitung (inklusive Nebenkanäle wie Telemetrie).
• SOV-5 Lieferketten-Souveränität: Transparenz und Beherrschbarkeit kritischer Lieferketten- und Subprozessor-Abhängigkeiten.
• SOV-6 Technologische Souveränität: Vermeidung kritischer technischer Lock-ins, Nachvollziehbarkeit und Austauschbarkeit zentraler Komponenten.
• SOV-7 Sicherheits- und Compliance-Souveränität: Security-Kontrollen, Nachweise, Audits und EU-konforme Umsetzung in der Praxis.
• SOV-8 Umwelt-/Nachhaltigkeitsaspekte: Energieeffizienz, kontrollierter Footprint und messbare Nachhaltigkeitsanforderungen.

Was die SEAL-Level praktisch ausdrücken (0–4)

• SEAL-0: Keine relevante Souveränität nachweisbar.
• SEAL-1: Grundlegende Erfüllung (EU-Recht/Regeln formal adressiert), aber starke Nicht-EU-Abhängigkeiten.
• SEAL-2: Materielle Souveränitätsmaßnahmen vorhanden, aber noch relevante externe Abhängigkeiten.
• SEAL-3: Hoher Grad an EU-Kontrolle und operativer Unabhängigkeit, externe Einflüsse stark begrenzt.
• SEAL-4: Sehr hohe bis vollständige digitale Souveränität in diesem Zielbereich, mit minimalen kritischen Nicht-EU-Abhängigkeiten.

Typische Kernelemente, die sich in vielen SOV-Zielen wiederfinden, sind:

• Datenhoheit: Datenverarbeitung und -speicherung in der EU. Keine verdeckten Datenabflüsse über Telemetrie, Support-Tools oder Subsysteme.
• Betriebshoheit: Betrieb, Administration und Support durch EU-ansässige, EU-kontrollierte Stellen. Subauftragnehmer-Regeln sind streng und müssen vollständig transparent sein.
• Rechtliche Immunität: Minimierung bzw. Ausschluss von Drittstaaten-Rechtszugriffen (z. B. extraterritoriale Zugriffsgesetze). Das ist der Grund, warum reine „EU-Region"-Angebote von US-Hyperscalern strukturell an Grenzen stoßen.
• Schlüsselhoheit (praktischer Hebel): Verschlüsselung ist nicht genug. Entscheidend ist, dass Key Management so umgesetzt ist, dass Dritte keinen Zugriff erzwingen können, weil die Schlüssel EU-seitig kontrolliert werden.

Was das für Hyperscaler bedeutet

AWS, Microsoft Azure und Google Cloud haben alle europäische Rechenzentren, europäische Tochterunternehmen und teils dedizierte "Sovereign Cloud"-Angebote angekündigt oder bereits eingeführt. Trotzdem können sie das Sovereign-Level strukturell nicht erreichen, weil die Konzernmutter jeweils in den USA sitzt, US-Börsenrecht unterliegt und damit dem CLOUD Act.

Einzelne Versuche, das zu umgehen , zum Beispiel durch Joint Ventures mit europäischen Partnern wie das Projekt zwischen Thales und Google oder T-Systems und Microsoft sind technisch aufwendig und organisatorisch komplex. Sie reduzieren das Risiko, lösen das strukturelle Problem aber nicht vollständig. Das Framework legt die Messlatte so, dass echte Entkopplung notwendig ist, nicht nur vertragliche Absicherung.

Das ist kein versteckter Protektionismus, sondern eine sachliche Konsequenz aus den gestellten Anforderungen. Wer rechtliche Immunität gegenüber dem CLOUD Act nachweisen muss, kann das eben nur dann, wenn kein US-Konzern im Hintergrund steht.

Technische Anforderungen im Detail

Wer die Zertifizierung anstrebt, muss konkrete technische Maßnahmen nachweisen. Die wichtigsten:

Verschlüsselung: Daten müssen sowohl at-rest als auch in-transit verschlüsselt sein. Das ist Standard – aber entscheidend ist, wer die Schlüssel kontrolliert.

Key Management: Kryptografische Schlüssel dürfen ausschließlich durch EU-ansässige Stellen verwaltet werden. Ein externer Key-Management-Service des Anbieters, auf den nur der Kunde Zugriff hat (Bring Your Own Key / Hold Your Own Key), kann diese Anforderung erfüllen – wenn er selbst souverän betrieben wird.

Zugriffskontrollen: Privilegierter Zugriff auf Produktionssysteme muss vollständig protokolliert, auf EU-Personal beschränkt und durch technische Maßnahmen gegen außerplanmäßigen Zugriff abgesichert sein. Break-Glass-Prozesse müssen dokumentiert und auditierbar sein.

Subauftragnehmer: Jeder Subauftragnehmer, der potenziell Zugriff auf Kundendaten haben könnte, muss denselben Anforderungen genügen wie der Hauptanbieter. Keine stillen Subprozessoren aus Drittstaaten.

Logging und Auditing: Vollständige, manipulationssichere Logs aller Datenzugriffe – nicht nur auf Anwendungsebene, sondern bis auf Infrastrukturebene.

Was Cloud-Souveränität nicht ist. Die Abgrenzung zur DSGVO

Ein häufiges Missverständnis: DSGVO-Konformität ist nicht dasselbe wie Cloud-Souveränität. Die DSGVO regelt, wie personenbezogene Daten verarbeitet werden dürfen. Sie sagt nichts darüber aus, ob ein Anbieter außereuropäischen Rechtszugriffen ausgesetzt ist.

Ein Dienst kann vollständig DSGVO-konform sein. Auftragsverarbeitungsvertrag, Datenschutz-Folgenabschätzung, Standardvertragsklauseln und trotzdem strukturell anfällig dafür sein, dass eine US-Behörde auf Basis des CLOUD Act Zugriff auf die Daten fordern kann. Das Framework macht diesen Unterschied explizit. Souveränität ist eine eigene Dimension, die über Datenschutzrecht hinausgeht.

Relevanz für Kubernetes-PaaS-Plattformen

Für Betreiber und Nutzer von Kubernetes-basierten PaaS-Plattformen hat das Framework direkte Konsequenzen. Eine Plattform, die auf nicht-souveräner Infrastruktur betrieben wird, vererbt deren Schwächen – egal wie gut die eigene Applikationsebene abgesichert ist. Sovereign by Design bedeutet, dass die Infrastrukturschicht, auf der die Plattform läuft, bereits die Anforderungen des Frameworks erfüllt.

Das ist der Ansatz, den lowcloud verfolgt: eine vollständig europäisch kontrollierte Plattform, die auf Infrastruktur läuft, die strukturell für das Sovereign-Level geeignet ist. Für Entwicklerteams bedeutet das, dass sie Cloud-native arbeiten können. Mit den gewohnten Kubernetes-Workflows, ohne dabei Souveränitätskompromisse einzugehen.

Das EU Cloud Sovereignty Framework gibt diesem Ansatz jetzt auch einen formalen Rahmen. Statt "wir sind in Deutschland gehostet" gibt es künftig prüfbare Kriterien, an denen sich Anbieter messen lassen müssen.

Ausblick: Was jetzt kommt

Das Framework ist zunächst als Orientierungsrahmen veröffentlicht worden. Die endgültige Verabschiedung des EUCS durch die EU-Mitgliedsstaaten steht noch aus. Hier gab es in der Vergangenheit politische Spannungen, insbesondere rund um die Frage, ob das Sovereign-Level US-Hyperscaler faktisch ausschließt. Das tut es und das ist politisch nicht unumstritten.

Dennoch: Die Richtung ist klar. Behörden und Unternehmen in regulierten Branchen werden in Ausschreibungen zunehmend nach zertifizierten souveränen Cloud-Diensten fragen. Wer jetzt auf souveräne Infrastruktur setzt, ist für diese Anforderungen vorbereitet – wer wartet, muss später unter Zeitdruck migrieren.

Wenn du wissen willst, wie eine Kubernetes-PaaS-Plattform auf souveräner Infrastruktur konkret aussieht und was das für deinen Stack bedeutet, schau dir an, wie lowcloud das umsetzt. Ohne Vendor-Lock-in, ohne Kompromisse bei der Souveränität.