Digitale Souveränität: Ein steuerbarer Reifegrad in Unternehmen

Digitale Souveränität in Unternehmen ist kein Schalter, den man anstellen kann. Sie ist ein Reifegrad, den Unternehmen aktiv steuern können. Welche Hebel und Best Practices es gibt? Das zeigt Markus Fischer, unser Fellow für das Thema Cloud, im Interview.  

Markus, wie relevant ist digitale Souveränität aktuell für Kunden – eher politisches Schlagwort oder echter geschäftskritischer Faktor? 

Digitale Souveränität ist längst kein Buzzword mehr, sondern für viele Unternehmen ein geschäftskritischer Faktor. Das zeigt auch die aktuelle Lünendonk-Studie zum Thema Digitale Souveränität, bei der wir mitgewirkt haben.

Durch geopolitische Spannungen und regulatorische Anforderungen ist das Thema bei vielen unserer Kunden hoch priorisiert, weil es unmittelbar um Risiko, Resilienz und Handlungsfähigkeit geht. Der Druck ist bei kritischer Infrastruktur natürlich am größten: Regulierung, hohe Schutzbedarfe und Ausfallszenarien sind dort Alltag. Dort haben wir gerade bei einem großen deutschen Netzbetreiber den Auftrag, souveräne Cloud-Betriebsmodelle gegen Hyperscaler-Optionen zu bewerten. Der Fokus liegt dabei auf Datenhoheit, Exit-Fähigkeit, Governance und realistischen Migrationspfaden.

Aber wir sehen das Thema genauso bei Industrie, Finanzdienstleistern oder Unternehmen mit sensiblen Daten und geschäftskritischen Plattformen. Da geht es nicht um politische Symbolik, sondern um eine klare, workloadspezifische Entscheidung: Was muss souveräner werden – und was darf pragmatisch bleiben? 

Welche konkreten Anforderungen stellen Unternehmen heute an digitale Souveränität, und wie hat sich diese Erwartungshaltung in den vergangenen Jahren verändert? 

Im Kern geht es meist um drei Dinge: Kontrolle über Daten, Kontrolle über Betriebsmodell und rechtliche Klarheit. Also ganz konkret: Wer kommt an die Daten? Wo liegen sie? Und unter welchem Rechtsrahmen werden sie verarbeitet? Früher war Cloud vor allem eine Effizienz- und Time-to-Market-Frage.

Heute kommt eine zweite Achse hinzu: Resilienz. Unternehmen wollen Transparenz, verlässliche Governance und eine Exit-Fähigkeit. Also die realistische Option, Anbieter zu wechseln oder Workloads zu verlagern, ohne geschäftskritische Systeme zu destabilisieren. Gleichzeitig ist der Wille gestiegen, stärker auf offene Standards und Open Source zu setzen. Nicht als Selbstzweck, sondern als Werkzeug, um Portabilität, Transparenz und Unabhängigkeit zu verbessern.

Und viele Kunden kommen inzwischen mit der Frage „Wie weise ich Souveränität nach?”. Denn das Thema wird nicht nur intern diskutiert, sondern zunehmend von Aufsicht, Partnern und Stakeholdern explizit eingefordert. Oft wird in der Debatte Souveränität zu binär gedacht. 

So stark treiben folgende Aspekte den Ausbau digitaler Souveränität in Unternehmen:

Wie meinst du das, Souveränität wird zu binär gedacht?   

Oft wird nur in “souverän” oder “nicht souverän” gedacht. In der Praxis ist das deutlich differenzierter. Digitale Souveränität hat mehrere Dimensionen und je nach Use Case braucht es mehr oder weniger davon. Ich unterscheide vor allem drei Ebenen: technologisch, betrieblich und juristisch.

Technologische Souveränität betrifft die Architektur: Wie stark bin ich an proprietäre Services gebunden? Wie portabel sind meine Workloads? Betriebliche Souveränität beschreibt die Kontrolle über den laufenden Betrieb: Wer administriert Systeme? Wie transparent sind Prozesse, Logging und Zugriff? Und juristische Souveränität stellt die Frage nach dem Rechtsrahmen und Zugriffsrechten.

Je nach Kritikalität eines Systems kann eine Organisation in einer Dimension sehr souverän sein und in einer anderen bewusst Abhängigkeiten akzeptieren. Souveränität ist kein Label, das man einmal kauft und dann „hat”. Sondern ein steuerbarer Reifegrad.

Inwieweit beeinflusst die Debatte um Souveränität die strategische IT-Planung der Kunden – insbesondere im Hinblick auf Architekturentscheidungen und Cloud-Strategien? 

Die Debatte schlägt inzwischen direkt in Architekturentscheidungen durch, insbesondere bei kritischen Systemen. In Ausschreibungen sehen wir zunehmend Anforderungen, die Hyperscaler entweder explizit ausschließen oder zumindest eine souveräne Betriebsvariante verlangen.

Technisch führt das oft zu stärkerer Containerisierung, mehr Plattform-Standards wie Kubernetes und eine bewusste Entkopplung von proprietären Services. Vor allem für unsere Kunden im öffentlichen Sektor spielt Open Source eine zentrale Rolle und reicht vom Backend bis hin zum digitalen Arbeitsplatz.

Aber auch Unternehmen außerhalb stark regulierter Branchen reagieren. Viele Kunden, die heute sehr auf einen Hyperscaler setzen, entwickeln ihre Landschaft weiter Richtung Multi-Cloud. Und das bedeutet inzwischen mehr als AWS, Azure und Google. 

Open Source: steigende Relevanz trifft auf geringen Reifegrad

Welche Alternativen zu den bekannten Hyperscalern gibt es und welche Vor- bzw. Nachteile bringen diese mit?  

Die bekannten Hyperscaler AWS und Microsoft Azure sind nach wie vor der Goldstandard in Sachen Cloud-Migration – und das auch zurecht. In Bezug auf Funktionalitäten, Skalierbarkeit und Innovation sind sie unschlagbar. Nur das allein reicht vielen nicht mehr aus, es soll digital souveräner werden.

AWS hat mit seiner European Sovereign Cloud ein stärker abgeschottetes EU-Modell eingeführt. Strukturell bleibt es jedoch das Angebot eines US-Hyperscalers. Ein anderes Modell ist die Delos Cloud. Hier wird Microsoft-Azure-Technologie in einer eigenständigen, in Deutschland verankerten Struktur bereitgestellt und durch SAP betrieben. Das erhöht die operative und rechtliche Kontrolle im deutschen Kontext deutlich. Allerdings basiert auch hier dieses Modell auf der Technologie eines US-Hyperscalers.

Rein europäische Anbieter wie STACKIT, IONOS oder OVHcloud gehen noch einen Schritt weiter. Sie operieren sowohl eigentümerseitig als auch technologisch unter europäischer Jurisdiktion.

In der Praxis zeigt sich jedoch ein Trade-off: Je höher die Souveränitätsanforderung, desto stärker muss ich funktionale Lücken, geringere Innovationsgeschwindigkeit oder mehr Integrationsaufwand einkalkulieren. Darum entscheiden sich viele für ein pragmatisches Modell: kritische Komponenten souveräner aufstellen – und dort, wo es sinnvoll ist, weiterhin Hyperscaler-Services nutzen. Allerdings mit klaren Kontrollmechanismen und Exit-Szenarien. 

Diese Rolle spielen relevante Cloud-Anbietermodelle in den kommenden drei Jahre bei geschäftskritischen Prozessen / sensiblen Daten:

Viele Organisationen kämpfen mit Fragmentierung, Legacy und komplexen Betriebsmodellen. Welche technologischen oder organisatorischen Weichen müssen gestellt werden, um souveräne Architekturen überhaupt realisierbar zu machen? 

Ohne ein belastbares Zielbild wird digitale Souveränität schnell zur Sammlung gut gemeinter Einzelmaßnahmen. Deshalb braucht es zuerst eine Strategie, die fachliche Kritikalität, Regulierung und technische Realität zusammenbringt. Am besten ist diese mit der höchsten Management-Ebene abgestimmt.

Unsere Erfahrung zeigt: Souveränitätsprojekte sind mit einem klaren Go „von oben“ oft schneller und effizienter am Ziel. Ein sehr wirksamer Hebel ist aus meiner Sicht ein Architektur-Board mit echtem Mandat. Dieses Board schaut einmal ganzheitlich auf die IT-Landschaft, definiert verbindliche Standards und sorgt dafür, dass Fragmentierung nicht weiter wächst. Und das vielleicht Wichtigste: Legacy darf nicht umschifft werden.

Wer Souveränität ernst meint, braucht zumindest einen klar priorisierten Modernisierungs- und Migrationsplan. Sonst baut man Souveränität auf einem Fundament, das nicht trägt.

Welche Schritte sind aus deiner Sicht unverzichtbar, um eine belastbare Souveränitäts-Roadmap zu entwickeln? 

Zunächst sollte man sich über drei Dinge klar werden: Welche Daten, Prozesse und Plattformen sind kritisch und warum? Digitale Souveränität aus unterschiedlichen Perspektiven betrachtet – was heißt „souverän genug” pro Bereich? Und wie kann ich das transparent messen und nachweisen? Es braucht also eine ganzheitliche Strategie, sonst bleibt digitale Souveränität nur ein Schlagwort.

Darauf aufbauend wird es operativ: Standards definieren etwa für Exit-Patterns, Portabilität oder Identitäts- und Zugriffsmodelle. Provider-Modelle bewerten und Migrationspfade priorisieren. Und vor allem Skills aufbauen und regelmäßige Risiko-Reviews etablieren.

Bleibe auf dem Laufenden: Folge uns auf LinkedIn und abonniere den Newsletter