Digitale Souveränität: Warum CIOs aufhören sollten, sich selbst zu belügen

Souveräne Clouds, europäische Allianzen, Milliarden-Investitionen – die Politik verspricht digitale Unabhängigkeit. Und trotzdem landen kritische Workloads weiterhin bei AWS, Microsoft und Co. Höchste Zeit für eine ehrliche Bestandsaufnahme.

Mitte 2026 verkünden Deutschland und Frankreich ihre gemeinsame Definition von digitaler Souveränität. Es ist der vorläufige Höhepunkt einer bemerkenswerten politischen Offensive: Souveränitätsgipfel in Berlin, deutsch-französische Initiativen für Frontier AI, zwölf Milliarden Euro Investitionszusagen. Die Message ist klar: Deutschland möchte nach den ganzen geopolitischen Krisen mehr Eigenständigkeit und Sicherheit in Schlüsseltechnologien.

Zeitgleich, in den Managementbüros deutscher Mittelständler und Konzerne, spielt sich ab, was sich seit Jahren wiederholt: Es wird in der Vorstandssitzung bei „digitaler Souveränität” genickt, während die IT drei Stockwerke tiefer gerade AWS-Lambda deployen. Nicht aus böser Absicht, sondern weil die DevOps-Teams auf schnelle Container drängen, der Vertriebsleiter seine KI-gestützte Lead-Scoring-Lösung sofort will. Das Problem ist nicht neu, allerdings wird technologische Abhängigkeit immer mehr zum strategischen Risiko. Während die Politik mit verschärfter Regulierung und Investitionen darauf reagiert, zeigt eine aktuelle Lünendonk-Studie wie groß die Lücke zwischen Anspruch und Wirklichkeit ist: Drei Viertel der befragten DACH-Unternehmen haben digitale Souveränität zwar in ihrer IT-Strategie verankert, doch nur 14 Prozent verfügen über eine umsetzbare Exit-Strategie. Noch ernüchternder: Lediglich drei Prozent können überhaupt messen, wie souverän sie tatsächlich sind. Digitale Souveränität ist in vielen Unternehmen also nach wie vor ein Lippenbekenntnis.

Digitale Souveränität wird vom Buzzword zum Risikomodell

Die Selbstlüge funktioniert so: Man hat ein Strategiepapier, in dem digitale Souveränität steht. Man nutzt deutsche Rechenzentren, zumindest für manche Workloads. Hat bisher auch funktioniert. Bis eine Compliance-Prüfung kommt und die Frage plötzlich real wird, die viele zu lange verdrängen: Wer hat eigentlich Zugriff auf meine Daten – heute, morgen und im Krisenfall? Ein häufig unterschätzter Risikofaktor ist der US Cloud Act. Dieser verpflichtet gesetzlich amerikanische Technologie- und Cloud-Dienstleister dazu, angeforderte Daten an US-Behörden weiterzugeben. Auch unabhängig davon, ob sich die entsprechenden Server innerhalb oder außerhalb der Vereinigten Staaten befinden. Die Cloud-Hyperscaler Microsoft, Google und Amazon sind dadurch nicht per se die falsche Wahl, aber es macht drängender, für jeden Workload eine bewusste Entscheidung zu treffen. 

Ein typisches Szenario: Der CIO eines mittelständischen Maschinenbauers ist überzeugt, souverän aufgestellt zu sein. Das ERP-System läuft in einem deutschen Rechenzentrum, die Produktionsdaten bleiben on-prem. Was nicht auf dem Radar ist: Die Marketing-Automation bei AWS, die Vertriebsdatenbank bei Salesforce, die HR-Software als SaaS aus den USA, die Entwicklungsumgebung in der Azure-Cloud. Zusammen macht das über 60 Prozent der geschäftskritischen Daten aus. Als die Rechtsabteilung im Zuge einer DORA-Compliance-Prüfung fragt, ob man alle regulatorischen Anforderungen erfülle, stellt sich heraus: Niemand hat den Gesamtüberblick. Eine Exit-Strategie? Fehlanzeige.

Entscheidungsgrundlage: Die Klassifizierung von Workloads

Eine belastbare Migrationsstrategie steht und fällt mit der Workload-Klassifizierung. Dabei haben sich vier Dimensionen als Rahmen bewährt:

1. Daten: Enthält der Workload personenbezogene, vertrauliche oder geschäftsrelevante Informationen?
2. Regulierung: Unterliegt er spezifischen Aufsichtspflichten, etwa BaFin, KRITIS oder NIS2?
3. Abhängigkeitsrisiko: Wie stark bindet die Lösung an bestimmte Anbieter oder proprietäre Schnittstellen?
4. Latenz & Verfügbarkeit: Sind niedrige Latenz oder hohe Ausfallsicherheit geschäftskritisch?

Das Ergebnis dieser Klassifizierung ist in den wenigsten Fällen eine Reinform nach dem Motto „alles on-prem“ oder „alles in die Cloud“. Stattdessen entsteht eine hybride oder Multi-Cloud-Strategie mit klarer innerer Logik: Kritische, regulierte Workloads laufen in kontrollierten, souveränen Umgebungen. Unkritische Workloads profitieren vom Innovationstempo und der Skalierbarkeit der Hyperscaler.

Hybride Architektur als technische Realität für mehr digitale Souveränität

Die Theorie ist einfach: kritische Workloads souverän, unkritische beim Hyperscaler. Die Praxis ist komplizierter, denn hybride und Multi-Cloud-Umgebungen müssen konsistent gesteuert werden. Bewährt hat sich eine Architektur mit zwei klar getrennten Zonen, die unterschiedlichen Governance-Prinzipien folgen. Die erste Zone ist hochgradig kontrolliert und beherbergt sensible, regulierte Workloads wie ERP-Systeme, Produktionsdaten oder Kundendatenbanken. Hier gelten enge Zugriffsrechte, strenges Change Management, zentrales Logging und dedizierte Verschlüsselung. Jede Änderung wird dokumentiert, jeder Zugriff protokolliert. Das ist aufwendig, aber für regulierte Umgebungen unverzichtbar.

Die zweite Zone ist agiler aufgestellt und umfasst Entwicklung, Test, Analytics oder Marketing-Tools. Hier ist Self-Service möglich, die Bereitstellung schneller, weil Innovationsgeschwindigkeit wichtiger ist als maximale Kontrolle. Teams können eigenständig Ressourcen provisionieren – allerdings innerhalb definierter Leitplanken wie Budgetgrenzen, Security-Baselines und automatisiertem Abbau ungenutzter Ressourcen.

Entscheidend ist die Verbindung zwischen beiden Zonen. Diese erfolgt nicht über das öffentliche Internet, wo jeder Datentransfer potenzielle Angriffsfläche bietet, sondern über dedizierte private Leitungen. Entweder über neutrale Carrier-Verbindungen oder Hyperscaler-native Dienste wie Azure ExpressRoute oder AWS Direct Connect, die lediglich Netzwerkkonnektivität bereitstellen, aber keinen Datenzugriff durch den Anbieter ermöglichen. Darüber liegt eine zentrale Governance-Plattform mit einheitlichem Monitoring, Infrastructure-as-Code und rollenbasierter Zugriffskontrolle über beide Zonen hinweg.

Drei Kardinalfehler, die Souveränität zu einer Farce machen

Wer kritische Workloads migrieren muss, trifft häufig auf gewisse Stolpersteine. Die erste Falle ist Migration ohne Strategie. Viele Projekte starten direkt mit Lift-and-Shift, weil der Business-Druck hoch ist und man schnelle Erfolge zeigen will. Man hebt Workloads 1:1 in die Cloud, ohne vorher die Anforderungen an Verfügbarkeit, Compliance, Performance oder Skalierbarkeit systematisch zu prüfen. Das spart kurzfristig Zeit und Budget, führt aber langfristig zu schwer kontrollierbaren Strukturen. Der richtige Ansatz lautet konsequent: erst klassifizieren, dann migrieren.

Die zweite Falle ist fehlerhafte IAM-Integration. Inkonsistente Identitätssynchronisation zwischen zentralen Verzeichnisdiensten und Cloud-IAM-Systemen gehört zu den häufigsten Ursachen für Sicherheitslücken in hybriden Architekturen. Veraltete Berechtigungen oder Konten, die in einer Umgebung deaktiviert wurden, in einer anderen jedoch weiterhin aktiv sind, erhöhen nicht nur das Risiko unautorisierter Zugriffe dramatisch, sondern erschweren auch Audits und Compliance-Nachweise erheblich. Im schlimmsten Fall hat ein Ex-Mitarbeiter, der vor sechs Monaten das Unternehmen verlassen hat, immer noch Zugriff auf produktive Systeme über einen vergessenen Cloud-Account.

Der dritte Kardinalfehler ist der Irrglaube, On-Prem sei automatisch sicherer. Viele Unternehmen halten Workloads aus einem diffusen Sicherheitsgefühl heraus on-prem, ohne die tatsächlichen Risiken zu bewerten. Doch ohne kontinuierliche Wartung, zeitnahe Updates und professionelles Patch-Management entstehen schnell kritische Sicherheitslücken, die monatelang unentdeckt bleiben. Daher sollte man sich selbst immer ehrlich die unbequeme Gegenfrage stellen: Kann ich es wirklich besser? Wenn nicht braucht es die bewusste Entscheidung, welche Umgebung welchen Workload am zuverlässigsten schützt.

Fazit: Digitale Souveränität ist machbar, aber nicht geschenkt

Digitale Souveränität bedeutet, bewusst zu entscheiden, was wohin gehört, um im Ernstfall handlungsfähig zu bleiben. 2026 wird das Jahr sein, in dem es um die praktische Anwendung gehen muss. Die Regierung investiert bereits Milliarden in digitale Souveränität. Aber solange fast die Hälfte der Unternehmen nicht weiß, wie sie aus ihrer Cloud wieder rauskommt, bleibt das Geld verpuffte Symbolpolitik. Echte Souveränität beginnt nicht in Berlin oder Brüssel – sie beginnt in der IT-Architektur. 

Die gute Nachricht: Es gibt bewährte Methoden, funktionierende Architekturen und reife Tools. Die schlechte: Ohne systematisches Vorgehen bleibt digitale Souveränität eine Illusion.