Was ist digitale Souveränität?
Digitale Souveränität bezeichnet die Fähigkeit eines Staates, einer Organisation oder eines Individuums, autonom über digitale Infrastruktur, Daten und Anwendungen zu entscheiden.
In Deutschland wird der Begriff insbesondere durch DSGVO, NIS2-Richtlinie1 und das Schrems-II-Urteil2 rechtlich gerahmt — und durch den US CLOUD Act als extraterritorialen Gegenpol geprägt.
Wichtig: Souveränität ist nicht gleichbedeutend mit nationaler Abschottung oder Hyperscaler-Verzicht. Sie ist eine Frage von Kontrolle, Nachvollziehbarkeit und Wahlfreiheit — und genau dort liegt der Unterschied zwischen einer Marketing-Floskel und einer betrieblichen Realität.
Drei Dimensionen der Cloud-Souveränität
Ein praktikables Modell unterteilt Souveränität in drei Dimensionen:
- Daten-Souveränität — Wo liegen die Daten? Wer hat rechtlich Zugriff? Datenresidenz allein reicht nicht: ein Anbieter unter US-Jurisdiktion muss nach dem US CLOUD Act3 Daten in seinem Besitz, Gewahrsam oder seiner Kontrolle herausgeben — unabhängig vom Speicherort, also auch aus einem EU-Rechenzentrum.
- Operations-Souveränität — Wer betreibt die Infrastruktur, wer hat Personal-Zugriff (logisch und physisch)? Operierendes Personal mit Sitz innerhalb der EU verschiebt die Risikolage erheblich.
- Software-Souveränität — Welcher Software-Stack? Offene Standards, IaC-Reproduzierbarkeit, hexagonale Architekturen und Exit-Fähigkeit halten die Tür für Anbieter-Wechsel offen.
Souveränität beginnt im Management, nicht im Rechenzentrum
Die wichtigste Erkenntnis aus der Praxis: echte Souveränität entsteht nicht durch eine technische Einzelentscheidung, sondern durch ein abgestimmtes Governance-Modell. Wo Business und IT gemeinsam eine Cloud-Strategie entwickeln, reduzieren sich Risiken, Entscheidungen werden schneller, Insellösungen vermieden. Wo das fehlt, wachsen Schatten-IT und nicht-auditierbare Datenflüsse.
Frameworks helfen: BSI C5, ISO/IEC 27001, SOC 1–3 strukturieren Compliance. Aber die Frameworks ersetzen keine Entscheidungs-Hierarchie: Wer trifft Cloud-Architektur-Entscheidungen? Wer reviewt? Wer eskaliert?
AWS European Sovereign Cloud (ESC)
Die AWS European Sovereign Cloud ist eine prominente Antwort eines Hyperscalers auf europäische Souveränitätsanforderungen: eine vollständig innerhalb der EU betriebene Cloud, physisch und logisch getrennt von den übrigen AWS-Regionen, mit eigener Gesellschaftsstruktur in Deutschland. Kernmerkmale laut AWS4:
- EU-betriebene Partition: Operations ausschließlich durch in der EU ansässiges Personal, mit eigenen Zertifikaten und Root Authorities5.
- EU-basierte Metadatenhaltung: vom Kunden erstellte Metadaten (Rollen, Berechtigungen, Labels, Konfigurationen) bleiben in der EU.
- Eigene Identity-, Billing- und Metering-Systeme: separat von der globalen AWS-Plattform.
- Service-Portfolio: Start am 15. Januar 2026 mit mehr als 90 Services — ein Ausschnitt des globalen AWS-Portfolios.
Für IT-Entscheider heißt das aus meiner Sicht: Souveränität ist auch mit globalen Cloud-Providern erreichbar, sofern technische, rechtliche und organisatorische Kontrollen ineinandergreifen. Die ESC richtet sich laut AWS unter anderem an öffentliche Verwaltung, Gesundheitswesen, Finanzdienstleister, Energie und Telekommunikation — mit einem Service-Umfang, der zum Start kleiner ist als in den globalen AWS-Regionen.
Einschränkung: Die ESC wird von in Deutschland gegründeten Gesellschaften6 betrieben, deren Konzernmutter jedoch ein US-Unternehmen ist. Ob das Zugriffe nach dem US CLOUD Act wirksam ausschließt, ist aus meiner Sicht rechtlich nicht abschließend geklärt.
Transparenzhinweis: Storm Reply, wo ich Geschäftsführer bin, ist AWS-Partner.
Anbieterlandschaft im Vergleich
Die deutsche Cloud-Landschaft differenziert sich zunehmend:
- Nationale Anbieter: IONOS, STACKIT (Schwarz Digits), Open Telekom Cloud — Betrieb in Deutschland bzw. Europa (STACKIT7 etwa mit Rechenzentren in Deutschland und Österreich), kleinere Service-Tiefe.
- EU-souveräne Hyperscaler-Modelle: AWS European Sovereign Cloud, Google Cloud Dedicated8 (Betrieb durch einen lokalen Partner auf isolierter Infrastruktur) — europäische Kontrollen, Service-Umfang je nach Angebot unterschiedlich. Nicht zu verwechseln mit Datenresidenz-Kontrollen innerhalb der regulären Public Cloud wie der Microsoft EU Data Boundary9 oder der Google Cloud Data Boundary.
- Klassische Public-Cloud-Regions in der EU: etwa Frankfurt, Dublin, Mailand — aus meiner Sicht die größte Service-Breite, aber als Angebote von US-Anbietern dem CLOUD Act unterliegend.
Die richtige Wahl hängt vom Workload ab. Ein 23-Kategorien-Entscheidungs-Kompass strukturiert die Bewertung — siehe vertiefende Beiträge weiter unten.
Souveränität als strategischer Prozess
Der Weg zur souveränen Cloud-Organisation folgt einem klaren Pfad:
- Souveränitäts-Assessment — Readiness-Check, Regulatorik-Mapping (DSGVO, NIS2, KRITIS, BaFin), Workload-Klassifikation.
- Zielarchitektur — Landing Zone, Policy-Set, Rollenmodell, KRITIS-/BaFin-Blueprints.
- Pilot-Workloads — Infrastructure-as-Code, Guardrails, Gate-Entscheidungen.
- Continuous Compliance — Policy-as-Code, Audit-Trails, regelmäßige Reviews, Evidenz-Management.
Souveränität ist kein Anbieter-Label, sondern eine Eigenschaft des eigenen Betriebsmodells.
Häufige Fragen zu digitaler Souveränität
Wie verhindern Trennungsmodelle, dass Daten zwischen EU und USA fließen?
Souveräne Cloud-Modelle trennen auf drei Ebenen. Technisch: eine eigene Partition mit eigener Infrastruktur, getrennt von den globalen Regionen. Organisatorisch: Betrieb durch Personal mit Wohnsitz in der EU unter einer europäischen Gesellschaft. Kryptografisch: Schlüssel, die der Kunde selbst verwaltet. Die AWS European Sovereign Cloud setzt die technische und organisatorische Trennung seit ihrem Start am 15. Januar 2026 um (AWS-Ankündigung). Eine Grenze bleibt: Die Muttergesellschaft sitzt in den USA, und ob US-Behörden über den CLOUD Act dennoch Zugriff verlangen können, ist aus meiner Sicht rechtlich nicht abschließend geklärt.
Welche Anbieter bieten souveräne Cloud-Optionen?
Drei Gruppen: nationale Anbieter wie IONOS, STACKIT und Open Telekom Cloud mit Betrieb in Deutschland bzw. Europa und schmalerem Service-Angebot; EU-souveräne Modelle der Hyperscaler wie die AWS European Sovereign Cloud und Google Cloud Dedicated; und klassische Public-Cloud-Regionen in der EU mit der größten Service-Breite, die aber dem CLOUD Act unterliegen. Datenresidenz-Kontrollen wie die Microsoft EU Data Boundary oder die Google Cloud Data Boundary gehören zur dritten Gruppe. Welche Gruppe passt, hängt vom Workload ab.
Was ist der Unterschied zwischen Datenlokation und Datensouveränität?
Datenlokation beschreibt nur, wo die Daten physisch liegen. Datensouveränität beantwortet die wichtigere Frage: Wer hat rechtlich Zugriff auf die Daten? Ein US-Hyperscaler mit EU-Rechenzentrum unterliegt dem US CLOUD Act unabhängig vom Speicherort. Souveränität erfordert deshalb sowohl Datenlokation als auch betrieblich-rechtliche Trennung.
Ist die AWS European Sovereign Cloud DSGVO-konform?
Keine Cloud-Plattform ist pauschal DSGVO-konform — sie kann einen DSGVO-konformen Betrieb ermöglichen; ob er gelingt, hängt von der konkreten Nutzung ab. Die AWS European Sovereign Cloud ist auf EU-Datenschutzanforderungen ausgerichtet. Operations ausschließlich durch in der EU ansässiges Personal, in der EU gehaltene Kunden-Metadaten sowie eigene Identity- und Billing-Systeme schaffen die strukturellen Voraussetzungen. Wie bei jedem Cloud-Service muss die DSGVO-Konformität auf Workload-Ebene durch die nutzende Organisation hergestellt werden (Verantwortlicher-Pflichten, Verarbeitungsverzeichnisse, technisch-organisatorische Maßnahmen).
Wie wirkt der US CLOUD Act gegenüber europäischen Cloud-Services?
Der US CLOUD Act verpflichtet Anbieter unter US-Jurisdiktion, auf Anordnung von US-Behörden Daten herauszugeben, die sich in ihrem Besitz, Gewahrsam oder ihrer Kontrolle befinden — unabhängig vom physischen Speicherort der Daten. Konsequenz: ein US-Anbieter mit EU-Rechenzentrum bleibt grundsätzlich CLOUD-Act-pflichtig. Souveränitätsmodelle wie die AWS European Sovereign Cloud adressieren dies über rechtlich getrennte EU-Entitäten und EU-betriebene Operations. Die Muttergesellschaft sitzt allerdings in den USA — ob das den CLOUD-Act-Zugriff wirksam ausschließt, ist aus meiner Sicht rechtlich nicht abschließend geklärt.
Welche Frameworks helfen bei Cloud-Souveränitäts-Bewertung?
BSI C5 (Cloud Computing Compliance Criteria Catalog), ISO/IEC 27001 (ISMS), SOC 1–3 (Service Organization Controls). Ergänzend für spezifische Branchen: BaFin-Anforderungen (Finanzdienstleistung), KRITIS-Anforderungen (kritische Infrastruktur), GxP/MDR (Healthcare). Auf strategischer Ebene strukturiert der 23-Kategorien-Entscheidungs-Kompass die Anbieter-Bewertung.
Macht digitale Souveränität den Hyperscaler-Einsatz unmöglich?
Nein — im Gegenteil. Digitale Souveränität bedeutet informierte Wahlfreiheit, nicht Isolation. Globale Cloud-Provider sind nutzbar, wenn die benötigten technischen, rechtlichen und organisatorischen Kontrollen ineinandergreifen. Angebote wie die AWS European Sovereign Cloud sind für diesen Zweck geschaffen; reine Datenresidenz-Zusagen wie die Microsoft EU Data Boundary reichen dagegen allein nicht aus.
Was ist NIS2 und wie hängt es mit Souveränität zusammen?
Die NIS2-Richtlinie ist die zweite EU-Cybersicherheitsrichtlinie; sie legt erweiterte Sicherheits- und Meldepflichten für kritische und wichtige Sektoren fest. In Kraft seit Januar 2023, Umsetzungsfrist für die Mitgliedstaaten Oktober 2024; Deutschland hat sie mit dem NIS2-Umsetzungsgesetz umgesetzt, in Kraft seit 6. Dezember 2025. Sie ist kein direktes Souveränitäts-Gesetz, aber sie erzwingt Resilienz-Anforderungen, die direkt die Cloud-Architektur berühren: Lieferkettensicherheit, Vorfallsmeldung, Mehrfaktor-Authentifizierung, Recovery-Fähigkeit. Für KRITIS-Betreiber verschmilzt NIS2 mit Souveränitäts-Anforderungen.
Quellen
- Europäisches Parlament und Rat: „Richtlinie (EU) 2022/2555 … (NIS-2-Richtlinie)“, ABl. L 333 vom 27. Dezember 2022; in Kraft seit 16. Januar 2023, Umsetzungsfrist 17. Oktober 2024 (Art. 41), Risikomaßnahmen in Art. 21 Abs. 2. eur-lex.europa.eu
- Gerichtshof der Europäischen Union: Urteil C-311/18 „Data Protection Commissioner / Facebook Ireland und Maximillian Schrems“ (Schrems II), 16. Juli 2020; Pressemitteilung Nr. 91/20. curia.europa.eu
- US-Kongress: „18 U.S.C. § 2713 – Required preservation and disclosure of communications and records“, eingefügt durch den CLOUD Act (Pub. L. 115-141, Div. V), 23. März 2018. law.cornell.edu
- Amazon Web Services: „AWS Launches AWS European Sovereign Cloud and Announces Expansion Across Europe“, Pressemitteilung, 15. Januar 2026. Allgemeine Verfügbarkeit, erste Region in Brandenburg, mehr als 90 Services, Betrieb ausschließlich durch EU-Ansässige, vom Kunden erstellte Metadaten sowie IAM, Billing und Usage-Metering in der EU. press.aboutamazon.com
- Colm MacCárthaigh, AWS Security Blog: „Establishing a European trust service provider for the AWS European Sovereign Cloud“, Blogbeitrag, 10. Juli 2025 (aktualisiert 4. August 2025). aws.amazon.com
- Amazon: „Built, operated, controlled, and secured in Europe: AWS unveils new sovereign controls and governance structure for the AWS European Sovereign Cloud“, Unternehmensmeldung, 3. Juni 2025. Eigene Root-CA in Europa, deutsche Muttergesellschaft mit drei GmbHs, Betrieb nur durch EU-ansässige Mitarbeitende. aboutamazon.eu
- STACKIT: „About STACKIT“, Unternehmensprofil, abgerufen 27. September 2026. stackit.com
- Google Cloud: „Sovereign Cloud from Google“, Produktseite, abgerufen 27. September 2026. Portfolio: Google Cloud Data Boundary, Google Cloud Dedicated, Google Cloud Air-Gapped. cloud.google.com
- Julie Brill, Paul Lorimer (Microsoft): „Microsoft completes landmark EU Data Boundary, offering enhanced data residency and transparency“, Blogbeitrag, 26. Februar 2025. blogs.microsoft.com
