Digitale Souveränität: Cloud‑Komfort – aber wer hat die Kontrolle?

Du nutzt Cloud-Services, weil sie Arbeit abnehmen: Infrastruktur wird zur Nebensache, Teams können schneller liefern, und vieles ist standardisiert. Gleichzeitig kann sich das Gefühl einschleichen, dass du zwar die Anwendung betreibst, aber nicht mehr die Bedingungen kontrollierst. Was passiert, wenn du dringend Daten exportieren musst? Wenn ein Unterauftragnehmer ausfällt? Oder wenn die wichtigste Funktion in einem proprietären Dienst steckt, der sich nicht sinnvoll umziehen lässt?

Genau an dieser Stelle wird der Begriff digitale Souveränität konkret. Die Europäische Kommission beschreibt in ihrem Cloud Sovereignty Framework eine Art Bewertungslogik, die Souveränität nicht nur als Prinzip, sondern als messbare Kriterien in Beschaffung und Betrieb übersetzen soll. Parallel gibt es Kontrollkataloge wie den deutschen BSI-Anforderungskatalog C5, die sehr praktisch beschreiben, welche Nachweise und Prozesse bei Cloud-Betrieb erwartet werden. Und auf EU-Ebene setzen Rechtsakte wie der Data Act (Regulation (EU) 2023/2854) Leitplanken für Zugang, Nutzung und Wechsel von Daten.

Dieser Artikel verbindet diese Perspektiven: Was heißt „Kontrolle“ technisch? Wo entstehen typische Abhängigkeiten? Und wie kannst du – auch ohne Großprojekt – testen, ob dein Setup im Ernstfall wirklich umschaltbar ist.

Im Cloud-Kontext wird „Kontrolle“ oft zu eng verstanden: Daten liegen in einer bestimmten Region, also sei alles geregelt. Die Praxis ist komplexer. Kontrolle umfasst mindestens drei Ebenen: Wo Daten gespeichert und verarbeitet werden, wer Schlüssel und Zugriffe steuert, und welche Nachweise du im Streit- oder Auditfall liefern kannst. Der Cloud Sovereignty Framework der Europäischen Kommission versucht, diese Ebenen in Ziele und Bewertungsstufen zu übersetzen. Er arbeitet mit sogenannten Sovereignty Effectiveness Assurance Levels (SEAL) von SEAL-0 bis SEAL-4. Damit wird Souveränität als Abstufung gedacht: von „keine“ bis „voll“ – mit klarer Erwartung, dass Nachweise und Prozesse die Stufe tragen müssen.

Ein zweiter, sehr praktischer Referenzpunkt ist der BSI-Anforderungskatalog C5. Er ist von 2016 und damit älter als zwei Jahre, wird aber in vielen Organisationen weiterhin als strukturierender Kontrollrahmen genutzt. Dort wird zum Beispiel gefordert, Datenstandorte und juristische Rahmenbedingungen nachvollziehbar zu dokumentieren (etwa für Speicherung, Verarbeitung und Backups) und Exportmöglichkeiten für Daten vorzusehen. Diese „Bodenhaftung“ ist wichtig: Ohne dokumentierte Systembeschreibung, ohne belastbare Protokolle und ohne klare Prozesse bleibt Souveränität schnell ein Gefühl statt ein überprüfbarer Zustand.

Souveränität wird greifbar, wenn du sie als Kombination aus überprüfbaren Nachweisen, klaren Zuständigkeiten und getesteter Ausweichfähigkeit behandelst – nicht als Standortversprechen.

Auf EU-Ebene kommen Zertifizierungs- und Gesetzesrahmen hinzu. Die EU Cybersecurity Certification Framework-Logik (unter dem EU Cybersecurity Act) schafft die Grundlage, dass Cloud-Dienste über definierte Sicherheitsziele und Assurance-Levels zertifiziert werden können. ENISA führt dazu die Arbeit an einem Cloud-Service-Scheme (EUCS) auf. Parallel setzt der Data Act (2023) Impulse in Richtung Portabilität und Wechselbarkeit: Wenn Datenzugang und Wechsel nicht nur „nett“, sondern verpflichtungsnah gedacht werden, muss die Technik Export, Schnittstellen und klare Verantwortlichkeiten leisten.

Die wichtigste Frage hinter „Wer kann unsere IT im Ernstfall abschalten?“ ist selten eine einzelne Supermacht-Taste. Es sind viele kleine, reale Abschaltpunkte, die sich im Alltag unsichtbar aufbauen. Ein offensichtlicher Punkt ist das Konto selbst: Wenn Identitäten, Rollen und Berechtigungen vollständig am Anbieter hängen, entscheidet im Extremfall dessen Control Plane über Zugriff auf Infrastruktur, Daten und Logs. Dazu kommen betriebliche Faktoren wie Abrechnung, Policy-Verstöße, automatische Sperrmechanismen oder Abhängigkeiten von Unterauftragnehmern. Der BSI C5-Katalog adressiert diese Realität indirekt: Er fordert nachvollziehbare Governance, Protokollierung und transparente Einbindung von Lieferanten, gerade weil Ausfälle und Streitfälle organisatorisch und technisch beherrschbar bleiben müssen.

Ein zweiter Abschaltpunkt ist die Semantik der Dienste. Sobald dein System stark auf proprietäre Managed Services baut, wird „Wechsel“ nicht nur ein Kopierproblem, sondern ein Umbauproblem. Ein Datenexport hilft dann nur begrenzt, weil nicht nur Daten, sondern Betriebslogik, Berechtigungen, Event-Flüsse und Monitoring-Mechaniken migriert werden müssen. Genau hier wird der Data Act als Leitplanke interessant: Der Rechtsrahmen stärkt Ziele rund um Zugang, Nutzung und Wechselbarkeit von Daten. Er nimmt dir aber nicht die technische Arbeit ab, diese Wechselbarkeit konkret umzusetzen.

Ein dritter Abschaltpunkt liegt in Nachweisen und Audits. Wenn du im Ernstfall belegen musst, wo Daten lagen, wer Zugriff hatte oder ob bestimmte Sicherheitsbedingungen erfüllt waren, brauchst du belastbare Artefakte: Systembeschreibung, Protokolle, definierte Prozesse. C5 beschreibt außerdem Audit-Modelle und die Bedeutung der Abgrenzung: Wird ein Unterauftragnehmer in den Audit eingeschlossen (inklusive) oder ausgeklammert (carve-out)? Diese Entscheidung kann im Alltag „nur“ ein Prüfdetail sein, im Krisenfall aber ein echter Blindfleck.

Schließlich ist Abschaltbarkeit auch eine Frage der Konzentration in der Infrastruktur. Selbst wenn du dein eigenes System verteilst, nutzt du oft gemeinsame Basisschichten, die wenige Betreiber dominieren. Eine wissenschaftliche Analyse zur Zentralisierung von Traffic über DNS-Server zeigt, wie solche Konzentration messbar wird: In der betrachteten Messung lösten die Top-10-DNS-Anbieter im Mittel rund 30 % der Domains aus einer Tranco-Top-1M-Liste auf, mit Spitzenwerten bis etwa 39 %. Das ist kein „Cloud ist schlecht“-Argument, aber es zeigt: Abhängigkeit entsteht nicht nur im Rechenzentrum, sondern auch in den unscheinbaren Schichten davor.

Digitale Souveränität wird erst steuerbar, wenn du sie messen und testen kannst. Dafür brauchst du zwei Dinge: klare Kriterien und einen realistischen Testlauf. Das Cloud Sovereignty Framework der Europäischen Kommission ist hier nützlich, weil es Souveränität als Bündel aus Zielen strukturiert und in SEAL-Stufen übersetzt. Besonders wichtig ist: Das Framework behandelt Lieferketten-Aspekte als stark gewichteten Bereich (20 %), während Umweltaspekte geringer gewichtet werden (5 %). Für die Praxis heißt das: Nicht nur „wo stehen Server?“ zählt, sondern auch, wie abhängig du von Subprovidern, Verträgen und technischen Gatekeepern bist.

Dann kommt die Audit-Perspektive: Der BSI C5-Katalog macht klar, welche Artefakte in vielen Prüf- und Beschaffungssituationen erwartet werden. Dazu gehören etwa eine belastbare Systembeschreibung (inklusive Datenstandorte), nachvollziehbare Protokollierung sowie Prozesse für Export und Schnittstellen. Auch wenn C5 von 2016 ist und damit älter als zwei Jahre, bleibt die Logik zeitlos: Ohne Belege ist Kontrolle kaum beweisbar. Wenn du solche Artefakte von Anfang an als Teil des Betriebs ansiehst, sparst du später Aufwand und reduzierst das Risiko, dass du im Ernstfall erst „nachbauen“ musst, was eigentlich immer vorhanden sein sollte.

Für eine alltagsnahe Messung hilft die DNS-Zentralisierungsstudie als Blaupause: Sie zeigt, wie man aus einer Domainliste technische Abhängigkeiten ableiten kann, indem man Nameserver abfragt, IP-Adressen sammelt und diese auf autonome Systeme (AS) und Organisationen abbildet. Der begleitende Code (öffentlich auf GitHub) macht diesen Ansatz reproduzierbar. Du musst dafür kein Forschungsprojekt starten: Für deine Organisation kann schon ein reduziertes Inventar reichen, etwa zentrale Service-Endpoints, Container-Registries, Login-Domains oder Update-Server. Der Mehrwert liegt nicht im perfekten Modell, sondern in der Sichtbarkeit von Konzentration.

Der wichtigste Test bleibt aber operativ: ein „Exit“-Probelauf. Plane einen kleinen, kontrollierten Wechselweg: Welche Daten lassen sich in offenen Formaten exportieren? Welche Konfigurationen sind als Infrastruktur-Definition nachvollziehbar? Welche Rollen und Schlüssel sind dokumentiert? Der Data Act stärkt die Erwartung, dass Portabilität nicht nur ein Versprechen ist, sondern praktisch funktionieren muss. Ein Probelauf zeigt dir schnell, ob dein Setup tatsächlich umziehbar ist oder ob du vor allem ein Export von Rohdaten bekommst, der die eigentliche Anwendung nicht rettet.

Wenn du Abhängigkeiten reduzieren willst, ist der erste Schritt meist nicht „weg von der Cloud“, sondern „weg von unbegründeter Alternativlosigkeit“. In der Praxis entstehen drei Hebel: Portabilität, Föderation und Nachweisfähigkeit. Portabilität heißt: Daten und Konfigurationen sind so strukturiert, dass sie in einem anderen Umfeld wieder nutzbar sind. Der Data Act (2023) verstärkt dieses Ziel politisch und rechtlich. Technisch übersetzt sich das oft in dokumentierte Exporte, stabile Schnittstellen und Formate, die nicht an ein einzelnes Ökosystem gebunden sind.

Föderation heißt: Du setzt nicht auf ein einziges geschlossenes System, sondern auf ein Netzwerk aus kompatiblen Teilnehmern. Hier kommt Gaia‑X als europäischer Ansatz ins Spiel. Der Trust Framework (Version 2024) fokussiert auf maschinenlesbare Vertrauens- und Compliance-Aussagen, unter anderem über Verifiable Credentials sowie über Registries und Trust Anchors. Wichtig ist: Das ersetzt keine Sicherheit an sich, kann aber helfen, Nachweise standardisierter zu formulieren und Vergleichbarkeit herzustellen. Der Framework arbeitet außerdem mit Label-Levels (1 bis 3) und mit Trust-Indizes (z. B. Veracity, Transparency), um Eigenschaften eines Angebots strukturiert zu beschreiben. In der Praxis kann das die Beschaffung erleichtern, weil Anforderungen nicht nur als PDF-Text, sondern als überprüfbare Claims gedacht werden.

Nachweisfähigkeit schließlich verbindet die anderen beiden Hebel. EUCS als ENISA-Arbeitspaket Richtung Cloud-Zertifizierung ist hier relevant, weil Zertifizierung die Sprache von Prüfstellen, Behörden und großen Einkäufern ist. Gleichzeitig bleibt es entscheidend, was du intern tust: Protokollierung, Schlüsselführung, Lieferketten-Transparenz und Exportprozesse müssen so gestaltet sein, dass du sie im Betrieb auch beweisen kannst. Genau dafür ist ein Kontrollkatalog wie BSI C5 hilfreich, selbst wenn er älter ist: Er zwingt dich, die Fragen zu beantworten, die sonst erst im Incident auftauchen.

Ein realistisches Zielbild ist daher oft ein abgestuftes Modell: kritische Daten und Schlüssel so kontrollieren, dass sie im Notfall nicht „mit dem Anbieter verschwinden“; Abhängigkeiten bewusst akzeptieren, wenn sie gut dokumentiert und vertraglich wie technisch eingehegt sind; und regelmäßig testen, ob Wechsel und Wiederanlauf tatsächlich funktionieren. Kontrolle ist in der Cloud kein Zustand, sondern ein trainierter Prozess.

Cloud-Komfort und digitale Souveränität schließen sich nicht aus, aber sie passen nur zusammen, wenn du „Kontrolle“ nicht mit „Serverstandort“ verwechselst. Aus den EU-Rahmenwerken und Kontrollkatalogen lässt sich ein klares Muster ableiten: Entscheidend sind überprüfbare Nachweise, eine transparente Lieferkette und die Fähigkeit, Daten und Workloads geordnet zu exportieren. Der Data Act setzt dafür Ziele rund um Zugang und Wechselbarkeit, während Zertifizierungsansätze wie EUCS und operative Kataloge wie BSI C5 helfen, Anforderungen in konkrete Kontrollen zu übersetzen. Messungen zur technischen Zentralisierung, etwa über DNS, erinnern daran, dass Abhängigkeit oft in Basis-Schichten entsteht, die kaum jemand bewusst plant.

Für dich als Entscheider oder Techniker ist die pragmatische Konsequenz: Baue zuerst Sichtbarkeit auf (Inventar, Abhängigkeiten, Nachweise), dann übe einen kleinen, realistischen Exit-Test. Wenn du dabei feststellst, dass dir vor allem Dokumentation, Logs oder Exportpfade fehlen, ist das kein Scheitern, sondern ein wertvoller Befund. Souveränität ist nicht „alles unter eigener Kontrolle“, sondern die Fähigkeit, im Ernstfall Optionen zu haben.