Cloud-Souveränität Governance: Warum das Thema aus der IT-Abteilung ins Führungsteam gehört

Wer das Thema Cloud Souveränität 2026 noch an den IT-Leiter delegiert, hat das regulatorische Risiko nicht verstanden. NIS2, DORA und wachsende geopolitische Unsicherheiten machen eine nachweisbare Sovereign-Cloud-Policy zur Pflicht. Die Verantwortung dafür liegt nicht im Serverraum, sondern im Konferenzraum.

Was Cloud-Souveränität 2026 wirklich bedeutet

Das Missverständnis zieht sich durch viele Organisationen: Man hat DSGVO-konform gehostet, die Daten liegen irgendwo in Frankfurt, also ist man souverän. Das stimmt nicht.

Cloud-Souveränität ist mehr als Datenlokalisierung. Sie beschreibt, wer tatsächlich die Kontrolle über Daten, Infrastruktur und Zugang hat und wer das nicht hat. Drei Dimensionen sind entscheidend:

• Datenhoheit: Wer definiert, klassifiziert und kontrolliert die Nutzung der Daten (inkl. Schlüssel-/Rechtemanagement und Datenflüsse)?
• Betriebshoheit: Wer betreibt die Plattform im Alltag und wer kann technisch Änderungen, Admin-Zugriffe oder Support-Zugriffe durchsetzen?
• Rechtliche Immunität: Inwieweit ist der Anbieter (Konzernstruktur/Rechtsordnung) vor extraterritorialen Zugriffsrechten geschützt bzw. kann solche Zugriffe ausschließen?

Eine detaillierte Einordnung der drei Begriffe kann in unserem Cloud Sovereignty Framework Artikel nachgelesen werden. Was Souveränität technisch bedeutet, haben wir in unserer Cloud-Vendor-Lock-in-Analyse beschrieben.

Ein Hyperscaler mit deutschem Rechenzentrum kann Datenhoheit und Betriebshoheit organisatorisch unterstützen, aber die rechtliche Immunität hängt maßgeblich von Konzernstruktur und Rechtsordnung des Anbieters ab. Und da wird es kompliziert.

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act) erlaubt US-Behörden den Zugriff auf Daten von US-Unternehmen, unabhängig davon, wo die Daten physisch gespeichert sind. Ein Rechenzentrum in München schützt dich nicht vor einer CLOUD Act-Anfrage, wenn der Betreiber eine US-amerikanische Muttergesellschaft hat. Das ist keine Theorie, das ist geltendes US-Bundesrecht.

Warum viele Unternehmen das Thema neu verorten

Cloud-Souveränität wird in vielen Organisationen nicht mehr als IT-Projekt betrachtet, sondern als Teil der Risikovorsorge, vergleichbar mit Brandschutz oder Compliance-Management. Das ist ein Paradigmenwechsel, und er hat konkrete Gründe.

Der erste Grund ist regulatorischer Druck. NIS2 ist seit Oktober 2024 in deutsches Recht umgesetzt. DORA gilt seit Januar 2025 für den Finanzsektor. Beide Regelwerke verlangen keine Absichtserklärungen, sondern nachweisbare Maßnahmen inklusive dokumentierter Cloud-Governance.

Der zweite Grund ist geopolitisch. Die letzten Jahre haben gezeigt, dass Abhängigkeiten von nicht-europäischen Cloud-Infrastrukturen ein strategisches Risiko sind. Was nach einem abstrakten Szenario klang, hat sich in konkreten Lieferkettenproblemen und politischen Spannungen materialisiert.

Der dritte Grund ist wirtschaftlich. Unternehmen, die im öffentlichen Sektor oder im sensiblen B2B-Bereich tätig sind, verlieren Aufträge, wenn sie keine glaubwürdige Cloud-Souveränitätsstrategie vorweisen können. Das ist keine Zukunftsmusik, das passiert heute in Ausschreibungen.

NIS2 und DORA: Was konkret von dir verlangt wird

NIS2 richtet sich an DevOps-Teams in kritischen und wichtigen Sektoren: Energie, Transport, Gesundheit, digitale Infrastruktur, Finanzdienstleistungen und mehr. Die Anforderungen sind konkret:

• Risikoanalyse und Dokumentation von IT-Sicherheitsmaßnahmen
• Nachweisbare Sicherheitsrichtlinien für den Einsatz von Cloud-Diensten
• Meldepflichten bei Sicherheitsvorfällen
• Haftung des Managements – Vorstände und Geschäftsführer können persönlich zur Verantwortung gezogen werden

DORA geht für Finanzinstitute noch weiter. Der Digital Operational Resilience Act fordert ein vollständiges IKT-Risikomanagement, das explizit Cloud-Abhängigkeiten erfasst. Drittanbieter-Verträge müssen Exit-Strategien enthalten, kritische Dienstleister müssen geprüft werden, und das alles muss dokumentiert und auditierbar sein.

Was bei einem Audit fehlt, wenn keine Policy existiert

Stell dir einen NIS2-Audit vor. Der Prüfer fragt nach deiner Cloud-Governance-Dokumentation. Du zeigst deinen AWS-Vertrag. Der Prüfer fragt nach der dokumentierten Risikoanalyse zu Drittlandszugriffen. Du hast keine. Er fragt nach der Exit-Strategie. Auch keine.

Das ist kein Nischenszenario. Das ist die Realität in vielen mittelständischen Unternehmen, die Cloud-Dienste produktiv nutzen, aber nie eine formale Sovereign-Cloud-Policy entwickelt haben. Die Konsequenzen reichen von Bußgeldern bis zur persönlichen Haftung der Geschäftsführung.

Was eine Sovereign-Cloud-Policy enthalten muss

Eine Sovereign-Cloud-Policy ist kein 50-seitiges Regelwerk. Sie ist ein klares, lebendiges Dokument, das fünf Kernfragen beantwortet:

1. Datenkategorisierung und Lokalisierungsregeln

Welche Daten dürfen in welchen Cloud-Umgebungen liegen? Personenbezogene Daten, IP-sensible Daten und regulatorisch relevante Daten brauchen unterschiedliche Behandlung.

2. Anbieterqualifikation

Nach welchen Kriterien wählst du Cloud-Anbieter aus? Rechtsordnung des Anbieters, Zertifizierungen (BSI C5, ISO 27001, SOC 2), Subauftragsverarbeiter. Das muss definiert und regelmäßig überprüft werden.

3. Zugriffskontrolle und Monitoring

Wer hat Zugriff auf Produktionsdaten? Wie wird der Zugriff protokolliert? Gibt es technische Maßnahmen gegen unberechtigten Drittlandzugriff (z. B. Ende-zu-Ende-Verschlüsselung mit selbst verwalteten Schlüsseln)?

4. Exit-Strategie

Wie migrierst du Daten und Workloads, wenn ein Anbieter ausfällt oder nicht mehr deinen Anforderungen entspricht? Welche Fristen, welche Formate, welche Kosten sind realistisch?

5. Verantwortlichkeiten und Review-Zyklus

Wer ist intern für die Policy verantwortlich? Wann wird sie überprüft? Welche Änderungen im regulatorischen Umfeld lösen eine Überarbeitung aus?

Warum das keine Ein-Mann-Entscheidung ist

Der CTO kann die technische Umsetzung verantworten. Aber eine Sovereign-Cloud-Policy hat Dimensionen, die über IT hinausgehen.

Der CFO muss die wirtschaftlichen Abhängigkeiten verstehen: Was kostet ein erzwungener Anbieterwechsel? Was kostet ein Compliance-Verstoß? Was kostet ein Datenleck, das durch fehlende Souveränitätsmaßnahmen entstanden ist?

Der Head of Legal / General Counsel (Chefjurist:in) muss die Vertragsarchitektur kennen: Welche Klauseln in Anbieterverträgen sind bei DORA-konformen Unternehmen nicht verhandelbar? Welche Drittlandsklauseln akzeptiert man gerade stillschweigend?

Und die Geschäftsführung oder der Vorstand trägt die ultimative Verantwortung. Bei NIS2 explizit und persönlich.

Das ist der eigentliche Grund, warum Cloud-Souveränität zur Chefsache wird: nicht weil das Thema komplex ist, sondern weil die Haftung nach oben wandert.

Europäische Alternativen. Worauf es beim Anbietervergleich ankommt

Der Markt für souveräne Cloud-Lösungen hat sich in den letzten zwei Jahren deutlich entwickelt. Es gibt mehr Optionen als noch 2023, aber auch mehr Unklarheit darüber, was "souverän" bei einem Anbieter wirklich bedeutet.

Achte auf folgende Kriterien:

• Rechtsordnung: Ist der Anbieter ein europäisches Unternehmen ohne US-amerikanische Muttergesellschaft?
• Betrieb: Werden die Rechenzentren vom Anbieter selbst betrieben oder von einem Hyperscaler zugemietet?
• Zertifizierungen: BSI C5 Typ 2 ist für den deutschen Markt der relevante Standard. ISO 27001 allein reicht nicht aus.
• Schlüsselmanagement: Wer kontrolliert die Verschlüsselungsschlüssel? Hast du die Möglichkeit, BYOK (Bring Your Own Key) zu nutzen?
• Vertragliche Absicherung: Gibt es explizite Klauseln, die Drittlandszugriffe ausschließen oder dokumentationspflichtig machen?

Erste Schritte. So startest du heute

Du musst nicht mit einem vollständigen Policy-Dokument starten. Aber du musst starten.

Ein pragmatischer Einstieg in drei Phasen:

Phase 1: Bestandsaufnahme (2–4 Wochen)

Kartiere alle genutzten Cloud-Dienste. Notiere für jeden Dienst: Anbieter, Rechtsordnung, Datenklasse, Vertragsgrundlage. Das klingt trivial, ist aber in den meisten Unternehmen nicht dokumentiert.

Phase 2: Risikobewertung (2–3 Wochen)

Identifiziere die drei bis fünf kritischsten Abhängigkeiten. Wo würde ein erzwungener Wechsel am meisten schmerzen? Welche Dienste verarbeiten die sensibelsten Daten?

Phase 3: Policy-Entwurf (4–6 Wochen)

Schreibe eine erste Version der Sovereign-Cloud-Policy. Hol dir juristisches Feedback. Verabschiede das Dokument auf Geschäftsführungsebene. Plane den ersten Review-Termin ein.

Das ist kein großes Projekt. Es ist ein überschaubarer Prozess, der aber aktiv angestoßen werden muss Am besten bevor der erste NIS2-Audit auf dem Kalender steht.

Cloud-Souveränität ist eine Führungsaufgabe, keine Infrastrukturfrage. Die Unternehmen, die das 2026 verstehen, werden Audits entspannt entgegensehen und in Ausschreibungen punkten. Die anderen lernen es auf die harte Tour.

Wenn du souveräne Kubernetes-Workloads auf einer europäischen DaaS-Plattform (DevOps as a Service) betreiben willst, die von Haus aus auf Datenkontrolle und Compliance ausgelegt ist, schau dir lowcloud an. Keine Abhängigkeit von US-Hyperscalern, kein CLOUD-Act-Risiko, keine versteckten Drittlandstransfers, sondern eine Plattform, die deine Sovereign-Cloud-Policy technisch umsetzt, nicht unterläuft.