Digitale Souveränität im IT-Delivery: Was CIOs 2026 wirklich entscheiden müssen

Was bedeutet digitale Souveränität im IT-Delivery?

Kurz gesagt: Digitale Souveränität ist die Fähigkeit einer Organisation, über ihre Daten, ihren Betrieb und ihre Technologieauswahl selbst zu entscheiden — und diese Entscheidung bei Bedarf auch zu revidieren. Sie ist damit keine Eigenschaft eines Rechenzentrums, sondern eine messbare Eigenschaft der eigenen Architektur: Wie teuer, wie schnell und wie risikoarm könnten Sie einen Anbieter wechseln, wenn Sie müssten?

Diese Definition klingt unspektakulär, verschiebt aber die gesamte Diskussion. In den meisten Vorstandsrunden wird Souveränität als Standortfrage verhandelt — „liegen die Daten in Frankfurt?" — und mit einem Häkchen auf einer Vertragsanlage beantwortet. Das ist die falsche Frage. Ein Datensatz in einem Frankfurter Rechenzentrum, betrieben von einer Tochtergesellschaft mit US-Muttergesellschaft, über eine proprietäre Managed-Service-API, die es nirgendwo sonst gibt, ist rechtlich und operativ deutlich weniger souverän als ein Datensatz in Irland, der über eine offene Schnittstelle in 48 Stunden migrierbar wäre.

Für Delivery-Verantwortliche ist das die zentrale Übersetzungsleistung: Souveränität ist eine nicht-funktionale Anforderung wie Verfügbarkeit oder Skalierbarkeit. Sie wird in der Architektur entschieden, nicht im Einkauf — und sie verfällt still, wenn niemand sie prüft.

Dass das Thema 2026 keine Nische mehr ist, zeigen die Zahlen des Branchenverbands Bitkom: In dessen Trendumfrage nennen 51 Prozent der befragten Gründerinnen und Gründer souveräne Cloud- und Edge-Lösungen als prägenden Trend des Jahres, 50 Prozent Data Sovereignty und 52 Prozent Cybersicherheit und Privacy Tech ([Bitkom, Trendumfrage 2026](https://www.bitkom.org/Presse/Presseinformation/Bundesregierung-jedes-zweite-Digitalvorhaben-auf-Weg-gebracht)). Drei der meistgenannten Trends stammen damit aus einem einzigen Themenfeld.

Die drei Ebenen: Daten, Betrieb, Technologie

Wer Souveränität steuerbar machen will, muss sie zerlegen. In der Praxis haben sich drei Ebenen bewährt, die unabhängig voneinander bewertet werden können — und die in realen Setups regelmäßig auseinanderfallen.

**Datensouveränität** beantwortet, wer rechtlich auf die Daten zugreifen kann. Entscheidend ist hier nicht der Speicherort, sondern die Rechtsordnung, der die Muttergesellschaft des Betreibers unterliegt. Verschlüsselung mit kundenseitig gehaltenen Schlüsseln (Hold-Your-Own-Key) verschiebt diese Frage spürbar, löst sie aber nur dann, wenn der Anbieter für den Betrieb tatsächlich keinen Klartextzugriff benötigt.

**Betriebssouveränität** beantwortet, wer das System im Fehlerfall wieder zum Laufen bringt. Wenn Ihr Betriebsteam ohne den Support des Anbieters kein Recovery durchführen kann, ist der Betrieb nicht souverän — unabhängig davon, wo die Hardware steht. Diese Ebene wird am häufigsten übersehen und fällt regelmäßig genau dann auf, wenn es teuer ist.

**Technologiesouveränität** beantwortet, ob es einen realistischen Ersatz gibt. Eine relationale Datenbank mit Standard-SQL ist ersetzbar. Ein proprietärer Workflow-Dienst, dessen Ablauflogik in einer anbieterspezifischen Notation liegt, ist es praktisch nicht — hier entsteht Lock-in nicht durch Daten, sondern durch Logik.

Die meisten Organisationen haben auf mindestens einer dieser Ebenen ein Problem, das sie nicht kennen, weil nie jemand die drei Ebenen getrennt bewertet hat. Genau das leistet eine strukturierte Bestandsaufnahme — etwa über unser Cloud-Migration-Assessment, das Exit-Pfade und Abhängigkeiten pro Workload sichtbar macht.

Was Zertifikate wirklich aussagen — und was nicht

Der Zertifikatsdschungel ist der häufigste Grund für Fehlentscheidungen, weil sehr unterschiedliche Prüfgegenstände unter demselben Etikett „souverän" verkauft werden. Drei Nachweise begegnen Ihnen im DACH-Raum regelmäßig, und sie prüfen jeweils etwas anderes.

Der **Kriterienkatalog C5** des Bundesamts für Sicherheit in der Informationstechnik ist ein Prüfstandard für Informationssicherheit im Cloud Computing und wird als Testat nach Wirtschaftsprüfer-Standard erteilt ([BSI, Cloud Computing Compliance Criteria Catalogue](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html)). C5 sagt sehr viel über Sicherheitsniveau und Transparenz — aber nichts über Eigentümerstruktur oder Zugriffsrisiken durch Drittstaaten.

**SecNumCloud** ist die französische Qualifizierung der Behörde ANSSI und geht deutlich weiter: Sie stellt auch Anforderungen an Betreiberstruktur und Immunität gegenüber außereuropäischem Recht. Wer echte Rechtsimmunität sucht, findet sie hier eher als bei einem reinen Sicherheitstestat.

**Gaia-X-Labels** wiederum zertifizieren Interoperabilität, Datenportabilität und Transparenz der Vertragsbedingungen — sie sind explizit kein Nachweis für EU-Eigentum und kein Schutz vor Drittstaatenzugriff. Die Europäische Kommission hat die Gaia-X-Regeln inzwischen in ihrem Cloud Sovereignty Framework referenziert, was ihre Rolle als Interoperabilitätsanker stärkt, ihren Prüfgegenstand aber nicht erweitert.

Praktische Konsequenz: Fragen Sie bei jedem Nachweis, den ein Anbieter vorlegt, welche der drei Ebenen er adressiert. Ein Anbieter mit C5-Testat und EU-Rechenzentrum kann trotzdem vollständig von einer Konzernmutter in einer anderen Rechtsordnung abhängen — und ein Anbieter ohne prominentes Label kann durch offene Standards faktisch die höhere Austrittsfähigkeit bieten.

Der Data Act macht Souveränität zur harten Anforderung

Was jahrelang eine strategische Präferenz war, wird nun regulatorisch unterfüttert. Die Verordnung (EU) 2023/2854 — der Data Act — enthält in Kapitel VI verbindliche Regeln für den Wechsel zwischen Datenverarbeitungsdiensten ([EUR-Lex, Verordnung (EU) 2023/2854](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)). Sie gilt seit dem 12. September 2025.

Zwei Punkte sind für Delivery-Organisationen unmittelbar relevant. Erstens verpflichtet die Verordnung Anbieter, den Wechsel aktiv zu ermöglichen: vertraglich definierte Übergangsfristen, Unterstützung beim Export von Daten und — soweit anwendbar — von digitalen Vermögenswerten. Zweitens laufen die Wechselentgelte aus: Ab dem 12. Januar 2027 dürfen Anbieter für den Wechsel grundsätzlich keine Entgelte mehr erheben.

Der Effekt ist subtiler, als es klingt. Der Data Act senkt die vertraglichen und finanziellen Wechselhürden — er beseitigt aber nicht die technischen. Wenn Ihre Geschäftslogik in einem proprietären Dienst liegt, hilft ein entgeltfreier Wechsel wenig, weil der eigentliche Aufwand in der Neuentwicklung steckt, nicht in der Rechnung des Anbieters. Die Regulierung räumt also genau die Hürde ab, die Sie ohnehin am leichtesten hätten überwinden können, und lässt die schwierige stehen.

Für die Delivery-Praxis heißt das: Ab 2027 ist „ein Wechsel wäre zu teuer" kein Vertrags-, sondern ein Architekturargument. Und Architekturargumente muss man messen können, bevor man sie glaubt. Wer den regulatorischen Gesamtrahmen einordnen will, in den sich das einfügt, findet ihn in unserer Regulierungs-Landkarte zu NIS2, DORA, CRA und AI Act.

Souveränitätsklassen statt Alles-oder-nichts

Der teuerste Fehler in Souveränitätsprogrammen ist die Pauschalentscheidung. „Wir gehen komplett souverän" führt zu Kosten, die niemand rechtfertigen kann, und endet meist in einer Ausnahmeliste, die den Beschluss aushöhlt. „Wir bleiben wie wir sind" ignoriert, dass einzelne Workloads tatsächlich ein Klumpenrisiko darstellen.

Der belastbare Weg ist eine Klassifizierung. Sie bewerten jeden Workload entlang von zwei Achsen — Schadenspotenzial bei fremdem Zugriff und Aufwand eines Anbieterwechsels — und leiten daraus eine von drei Souveränitätsklassen ab. Die Klasse bestimmt dann die zulässigen Plattformen, nicht der Einzelfall-Geschmack des jeweiligen Architekten.

1. 1Klasse A — souveränitätskritisch: Personenbezogene Kern- und Gesundheitsdaten, Quellcode mit Wettbewerbsrelevanz, regulatorisch besonders geschützte Bestände. Anforderung: Rechtsimmunität und kundenseitige Schlüsselhoheit, Betrieb im europäischen Rechtsraum, dokumentierter Exit-Pfad.
2. 2Klasse B — austrittsfähig: Standard-Geschäftsanwendungen ohne besonderen Schutzbedarf. Anforderung: offene Schnittstellen, exportierbare Daten in dokumentierten Formaten, getesteter Exit-Pfad — Hyperscaler zulässig.
3. 3Klasse C — unkritisch: Öffentliche Inhalte, Testumgebungen, nicht geschäftskritische Hilfsdienste. Anforderung: keine besonderen Souveränitätsauflagen, Auswahl rein nach Kosten und Betriebsaufwand.

Was das für die Delivery-Organisation heißt

Souveränität scheitert selten an der Strategie und fast immer an der Umsetzung — weil sie niemandem gehört. Die Strategieabteilung schreibt sie auf, der Einkauf verhandelt sie, aber niemand prüft sie im Sprint. Drei Mechanismen ändern das.

Erstens: **Exit-Fähigkeit als nicht-funktionale Anforderung.** Jeder Workload der Klassen A und B bekommt eine dokumentierte Zielplattform für den Wechselfall und eine geschätzte Wechseldauer. Diese Schätzung ist Teil der Architekturdokumentation und wird bei jeder wesentlichen Änderung aktualisiert. Eine Zahl, die niemand pflegt, ist keine Zahl.

Zweitens: **Der Exit-Test.** Eine Schätzung, die nie überprüft wurde, ist eine Vermutung. Für Klasse-A-Workloads sollte mindestens einmal jährlich der Datenexport tatsächlich durchgeführt und die Wiederherstellbarkeit auf einer Alternativplattform stichprobenartig belegt werden — analog zum Restore-Test beim Backup, den auch niemand ernst nimmt, bis er einmal fehlschlägt.

Drittens: **Ein Architektur-Gate bei Neuentscheidungen.** Wenn ein Team einen anbieterspezifischen Managed Service einführen will, wird die entstehende Bindung explizit gemacht und der Klasse zugeordnet. Das ist kein Verbot proprietärer Dienste — sie sind oft die wirtschaftlich richtige Wahl. Es ist die Anforderung, die Entscheidung bewusst und nachvollziehbar zu treffen, statt sie in einem Ticket verschwinden zu lassen.

Diese drei Mechanismen kosten wenig und wirken sofort, weil sie an vorhandene Routinen andocken. Wer prüfen will, wie belastbar die eigene Governance solche Gates überhaupt trägt, findet in unseren Assessment-Templates den passenden Einstieg — und in den Preisen den Rahmen für den vollen Zugriff.

Drei Anti-Patterns, die regelmäßig teuer werden

In Souveränitätsprogrammen wiederholen sich dieselben Fehler — und sie sind alle gut gemeint.

• **Das Standort-Häkchen.** Die Region wird auf „EU" gestellt, das Thema gilt als erledigt. Weder Betriebs- noch Technologiesouveränität wurden je bewertet, und der proprietäre Managed Service im Kern der Anwendung bleibt unangetastet.
• **Der Big-Bang-Beschluss.** Ein Vorstandsbeschluss erklärt die vollständige Migration auf souveräne Plattformen. Weil keine Klassifizierung vorliegt, trifft die Anforderung auch unkritische Systeme, die Kosten explodieren, und nach zwei Quartalen wächst die Ausnahmeliste schneller als das Programm.
• **Die Souveränität ohne Betriebsmodell.** Eine souveräne Plattform wird beschafft, aber das eigene Team kann sie nicht betreiben, weil die Managed-Service-Tiefe des vorherigen Anbieters fehlte. Ergebnis: formale Souveränität bei faktisch schlechterer Verfügbarkeit — und ein Rückbau innerhalb eines Jahres.