Eine souveräne Cloud ist eine Cloud-Umgebung, in der eine Organisation selbst bestimmt, wo ihre Daten liegen, wer die Systeme betreibt, wer die Schlüssel hält und welches Recht im Konfliktfall gilt. AWS, Microsoft, Google, SAP und europäische Anbieter vermarkten inzwischen eigene Dienste als „Sovereign Cloud“. Für IT-Leiter und CISOs sagt das Etikett wenig. Entscheidend ist, welche Ebene ein Angebot absichert und mit welchem Dokument sich das belegen lässt.
Vier Ebenen der Souveränität lassen sich prinzipiell unterscheiden:
Datenhoheit: Wo liegen Kundendaten, Backups, Metadaten, Telemetrie und Supportdaten? Microsoft beschreibt die EU-Data-Boundary als Grenze in EU und EFTA, nimmt aber Konfigurationsangaben wie Ressourcennamen aus dem Begriff der Kundendaten aus und dokumentiert Fälle, in denen Daten die Grenze verlassen. Wer prüft, liest Definitionen und Ausnahmeliste, nicht die Überschrift.
Betriebshoheit: Wer administriert die Plattform, wer hat Notfallzugriff, und läuft der Betrieb weiter, wenn die Verbindung zur Konzernzentrale abreißt? AWS gibt für seine European-Sovereign-Cloud an, sie werde ausschließlich von Personal mit Wohnsitz in der EU betrieben.
Schlüsselhoheit: Vom Kunden verwaltete Schlüssel im Schlüsseldienst des Anbieters sind etwas anderes als External-Key-Management mit einem Hardware-Sicherheitsmodul außerhalb der Anbieterumgebung. Gegen eine Herausgabeanordnung hilft Verschlüsselung nur, wenn der Anbieter den Klartextschlüssel nie in der Hand hat.
Rechtsraum: Welchem Recht unterliegen Betreiber und Muttergesellschaft? Diese Ebene folgt aus der Eigentümerstruktur, nicht aus dem Rechenzentrum.
Der Rechtsraum entscheidet, nicht der Serverstandort
Der US-Cloud-Act von 2018 verpflichtet Anbieter in 18 U.S.C. § 2713, Daten in ihrem „possession, custody, or control“ herauszugeben, unabhängig davon, ob sie in den USA liegen. Ein Rechenzentrum in Frankfurt beantwortet die Rechtsfrage deshalb nicht. Anbieter reagieren zweifach: gesellschaftsrechtlich mit europäischen Betreibergesellschaften, deren Tragweite die Rechtsabteilung im Einzelfall bewerten muss, und technisch mit Schlüsseln, die ausschließlich der Kunde kontrolliert. Dann kann der Anbieter nur Chiffretext herausgeben. Die Frage nach dem Rechtsraum gehört in die Ausschreibung, nicht erst in die Vertragsverhandlung.
Die drei vorherrschenden Marktmodelle leiden jedes unter einer offenen Flanke:
- Hyperscaler-Varianten, etwa die AWS-European-Sovereign-Cloud (seit Januar 2026, erste Region in Brandenburg), Souveränitätskontrollen in Microsofts-Public-Cloud oder partnerbetriebene Angebote wie die Delos-Cloud. Offen bleibt je nach Variante der Rechtsraum der US-Mutter, der Betrieb durch den Hyperscaler oder ein kleinerer Dienstumfang.
- Europäische Anbieter wie STACKIT halten Daten, Betrieb und Rechtsraum in Europa. Offen bleiben Dienstbreite, KI-Kapazität und Migrationsaufwand.
- Private Cloud und On-Premises bieten maximale Kontrolle, verlangen aber eigenen Betrieb. Microsoft schreibt selbst, lokale Clouds lieferten die stärksten Souveränitätskontrollen, aber „nicht den vollständigen Cloudwert“.
Dass Europas KI-Souveränität an der Kapazität des heimischen Cloud-Ökosystems hängt, argumentiert der Netzpalaver-Beitrag Europas KI-Souveränität steht und fällt mit seinem Cloud-Ökosystem.
Nachweise ersetzen Etiketten
BSI C5: Ein Typ-2-Bericht testet die Wirksamkeit der Maßnahmen, Typ 1 nur ihr Design. In den „Rahmenbedingungen“ legt der Anbieter die Lokalisation der Datenverarbeitung offen, der Gerichtsstand wird abgefragt. Die Fassung C5:2026 liegt seit Ende März 2026 final vor.
EU-Data-Act: Seit dem 12. September 2025 muss ein Cloud-Vertrag den Wechsel regeln, die Kündigungsfrist darf höchstens zwei Monate betragen. Wechsel- und Egress-Entgelte dürfen nur die unmittelbaren Kosten decken und entfallen ab dem 12. Januar 2027 ganz.
CADA: Der Verordnungsvorschlag der EU-Kommission vom 3. Juni 2026 sieht vier Souveränitätsstufen vor, von der Verarbeitung auf EU-Infrastruktur bis zur vollen Kontrolle über die Software-Lieferkette. Geltendes Recht ist das nicht, als Vokabular für Ausschreibungen taugt es schon heute.
Prüffragen je Workload
- Wo liegen Kunden-, Meta-, Telemetrie- und Supportdaten? Beleg: C5-Rahmenbedingungen und Ausnahmeliste.
- Unterliegen Betreiber oder Mutter Drittstaatenrecht? Beleg: Gesellschafterstruktur.
- Wer betreibt die Plattform, mit welchem Personal und welchem Notfallzugriff? Beleg: Betriebskonzept und Zugriffsprotokolle. Warnsignal: Follow-the-Sun-Support aus Drittstaaten.
- Läuft der Betrieb bei Trennung von der Konzernzentrale weiter? Beleg: Betriebshandbuch. Warnsignal: zentrale Steuerungsebene außerhalb der EU.
- Liegt der Schlüssel außerhalb der Anbieterumgebung? Beleg: Dokumentation zu External Key Management.
- Liegt ein aktueller C5-Typ-2-Bericht vor? Warnsignal: nur Typ 1 oder nur Selbstauskunft.
- Welche Dienste gibt es in der souveränen Variante wirklich? Beleg: veröffentlichte Dienstmatrix statt Roadmap.
- Wie funktioniert der Exit? Beleg: Wechselklauseln nach Data Act und Exportformate.
Angewendet wird das pro Workload, nicht pro Unternehmen. Praktikabel sind drei Schutzklassen: Klasse 1 verlangt Datenresidenz, Klasse 2 zusätzlich Schlüssel- und Betriebshoheit, Klasse 3 alle vier Ebenen. So landet nicht das ganze Portfolio im teuersten Modell.
Kosten folgen Betriebsmodell, Schlüsseln und Exit
Einen Listenpreis gibt es nicht, wohl aber Kostentreiber: Private Cloud bringt Hardware und Bereitschaftsdienst ins eigene Budget, External-Key-Management erhöht den Prozessaufwand, fehlende Dienste erzwingen Eigenbetrieb oder Umbau. Pexon Consulting setzt mit dem Souveränitäts-Foundation-Paket für die Sovereign Cloud vor der Plattformentscheidung an: Strategie-Workshop und Roadmap, Compliance-Analyse nach DSGVO und BSI, Architektur-Design, Anbieter-Evaluierung, Proof-of-Concept-Plan und Management-Präsentation, laut Leistungsseite ab 75.000 Euro. Umsetzung und Betrieb sind nicht enthalten. Migration, Plattformkosten und Nachweise gehören als eigene Positionen in die Wirtschaftlichkeitsrechnung.
Ein Fahrplan in drei Phasen
Pexon Consulting gliedert solche Projekte in drei Phasen: Strategie und Assessment, dann Architektur und Design mit einer BSI-C5-konformen Zielarchitektur und einem Proof-of-Concept, danach Implementierung und Betrieb mit Infrastructure as Code, Migration und Security-Operations. Die strategische Grundlage entsteht nach dieser Darstellung in wenigen Wochen, ein vollständiger Aufbau dauert je nach Umfang mehrere Monate.
Für die Reihenfolge hilft ein einfaches Prinzip: zuerst die Workloads der höchsten Schutzklasse mit geringen Abhängigkeiten von proprietären Diensten, danach die übrigen. Wer seine Kontrollen bereits an C5 oder ISO 27001 ausgerichtet hat, bildet die neuen Anforderungen als Delta ab und dokumentiert Schlüsselverwaltung, Betriebszugriffe und Exit-Verfahren zusätzlich.
Von Phillip Pham, Geschäftsführer der Pexon Consulting GmbH, Grünwald bei München
