Digitale Souveränität im Spannungsfeld von DORA, NIS2 und Cloud-Anbietern

Die AWS European Sovereign Cloud verspricht Datensouveränität per Knopfdruck. Doch die Realität sieht anders aus: 72% der Unternehmen kämpfen mit Legacy-Systemen, die sich nicht einfach in souveräne Clouds schieben lassen. DORA und NIS2 verschärfen den Druck. Ein Reality Check für Entscheider.

Am 15. Januar 2026 startete die AWS European Sovereign Cloud in Brandenburg. Das Versprechen: Datensouveränität für regulierte Branchen – vollständig in der EU, unter EU-Recht, betrieben von EU-Personal. Ähnliche Initiativen wie Gaia-X oder nationale Cloud-Strategien suggerieren: Wähle die richtige Cloud, und das Souveränitätsproblem ist gelöst.

Die Realität sieht brutal anders aus. Laut einer Studie von Computerwoche/CIO/CSO stehen 72% der Unternehmen in Deutschland vor der Herausforderung, geschäftskritische Bestandssysteme zu modernisieren.¹ Eine Slalom-Studie zeigt: 61% nutzen für die Mehrheit ihrer Geschäftsanwendungen weiterhin veraltete Plattformen.² Noch drastischer: Bei 11% der Unternehmen sind 76–100% der kritischen Anwendungen betroffen.

Was bedeutet das konkret? Eine Bank kann ihr neues Kundenportal in einer souveränen Cloud betreiben, aber das Kernbankensystem läuft auf 20 Jahre altem COBOL. Eine Versicherung modernisiert ihr Frontend, aber die Schadensabwicklung hängt an proprietären Legacy-Datenbanken. Eine öffentliche Verwaltung digitalisiert Bürgerdienste, aber die Fachverfahren laufen auf Altanwendungen, die niemand mehr anfassen will. Die Frage ist nicht: „Wohin in die Cloud?“ Die Frage ist: „Was mache ich mit den 60% meiner IT-Landschaft, die sich nicht einfach migrieren lassen?“

Digitale Souveränität ist kein Cloud-Problem. Es ist ein Architektur-, Migrations- und Betriebsproblem in hybriden IT-Landschaften. Die tatsächlichen Herausforderungen liegen woanders:

62% der Unternehmen stufen Teile ihrer geschäftskritischen Anwendungen als so veraltet ein, dass sie den heutigen Anforderungen nicht mehr gerecht werden.³ 40% der veralteten Systeme sind Eigenentwicklungen¹, gewachsen über Jahrzehnte, verzahnt mit Dutzenden anderen Systemen, dokumentiert von Mitarbeitern, die längst in Rente sind.

Ein Beispiel aus der Praxis: Eine Versicherung betreibt ihre Schadensabwicklung auf einer 25 Jahre alten Eigenentwicklung. Das System ist mit SAP (On-Prem), Salesforce (Cloud), diversen Fachverfahren und externen Dienstleistern verbunden. DORA verlangt jährliche Resilienz-Tests. Die Frage ist nicht: „Welche Cloud ist souverän?“ Die Frage ist: „Wie teste ich wirksam die Resilienz eines Systems, das niemand mehr vollständig versteht?“

DORA ist seit 17. Januar 2025 in Kraft, NIS2 sollte bis Oktober 2024 in nationales Recht umgesetzt werden, das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) wurde jedoch erst 2025 verabschiedet. Die Anforderungen sind konkret:⁴

Das Problem: Diese Anforderungen treffen auf IT-Landschaften, in denen Entwickler laut einer Stripe-Studie 17 Stunden pro Woche allein mit der Pflege von Legacy-Code verbringen.⁵ 40% des IT-Budgets fließen in die Wartung technischer Schulden, nicht in Innovation oder Compliance.⁶

Wie soll eine Organisation, die kaum die Betriebsfähigkeit ihrer Altsysteme aufrechterhalten kann, zusätzlich DORA-konforme Resilienz-Tests durchführen?

90% der Unternehmen betreiben laut Gartner hybride Infrastrukturen⁷ – eine Mischung aus On-Premise, Private Cloud, Public Cloud, Legacy-Systemen und modernen Microservices. Das ist keine Übergangslösung, sondern dauerhafter Zustand.
Die Herausforderungen sind massiv:

Studien zeigen: 67% der Cloud-Migrationsprojekte überschreiten ihr Budget, 43% dauern länger als geplant.⁹ Der Grund ist selten die Cloud selbst, sondern die Komplexität der Migration aus gewachsenen, verzahnten Altsystemen.

Am 15. Januar 2026 hat AWS die European Sovereign Cloud (ESC) in Brandenburg offiziell gestartet. AWS positioniert sie als autarke Cloud für Europa mit strikter Trennung von allen anderen AWS-Regionen. Die Versprechen klingen verlockend.

Die ESC ist physisch und logisch von allen anderen AWS-Regionen getrennt. Sie verfügt über ein eigenes Identity & Access Management (IAM), separate Abrechnungssysteme und eine eigene Route-53-Infrastruktur mit EU-TLDs. Der Betrieb erfolgt durch die AWS European Sovereign Cloud GmbH, eine 100-prozentige Tochtergesellschaft von Amazon.com Inc. mit Sitz in Deutschland.
Die Führung liegt bei Stéphane Israël und Stefan Hoechbauer, beide EU-Bürger. Ein Advisory Board aus ausschließlich EU-Bürgern – darunter zwei unabhängige Vertreter – soll zusätzliche Governance-Kontrolle sicherstellen. AWS verspricht, dass der Betrieb schrittweise ausschließlich von EU-Bürgern mit Wohnsitz in der EU übernommen wird. In einer Übergangsphase arbeiten derzeit noch gemischte Teams aus EU-Bürgern und EU-Residents, allerdings ausschließlich innerhalb der EU.

Am 15. Januar 2026 ging die AWS European Sovereign Cloud (ESC) in Brandenburg an den Start. AWS verspricht vollständige Trennung von anderen AWS-Regionen, eigenes Identity & Access Management, Betrieb ausschließlich durch EU-Personal unter EU-Recht.¹⁰

Das Service-Portfolio ist beachtlich. Rund 90 Services zum Start: Compute (EC2, Lambda), Storage (S3, EBS), Datenbanken (Aurora, RDS, Neptune), Container (EKS, ECS), KI/ML (SageMaker, Bedrock). Eine Investition von 7,8 Milliarden Euro bis 2040 untermauert die Ernsthaftigkeit.

Die ESC ist technisch beeindruckend, aber sie löst nicht das Kernproblem:

Sie adressiert nicht die Legacy-Realität. Ein 20 Jahre altes COBOL-System lässt sich nicht einfach nach AWS ESC migrieren. Eine proprietäre Eigenentwicklung mit Hunderten Abhängigkeiten ist kein Cloud-Workload. Eine gewachsene SAP-Landschaft verschiebt man nicht über Nacht.

Sie schafft neue Komplexität. Die ESC ist bewusst isoliert, es gibt keine Vernetzung mit anderen AWS-Regionen. Das bedeutet:

Sie löst nicht vollständig das US-Rechts-Problem. Die AWS European Sovereign Cloud GmbH ist 100-prozentige Tochter von Amazon.com Inc. Damit unterliegt sie potenziell US CLOUD Act und FISA 702, auch wenn AWS verspricht, jeden Request zu prüfen und Kunden zu informieren[^12]. Die rechtliche Grauzone bleibt.Sie ignoriert die Migrations-Komplexität. Wer glaubt, Souveränität bedeutet „System in die ESC schieben“, übersieht:

Die ESC kann für neue Workloads mit hohen Compliance-Anforderungen sinnvoll sein:

Die ESC ist Overkill für:

Die ESC ist keine Lösung für:

Die unbequeme Wahrheit: Wer seine 20 Jahre alten Kernsysteme nicht modernisieren kann, dem hilft auch die souveränste Cloud nicht weiter.

Digitale Souveränität entsteht nicht durch Provider-Wahl. Sie entsteht durch Architektur-Kompetenz, Migrations-Fähigkeit und Betriebs-Exzellenz.

Der erste Schritt ist Ehrlichkeit. 41% der Unternehmen geben zu, ihre Legacy-Systeme trotz Modernisierungsdruck nicht loszuwerden.¹² Der Grund ist oft: Niemand weiß mehr genau, was das System tut, mit wem es verbunden ist, und was passiert, wenn man es anfasst.

Eine realistische Bestandsaufnahme bedeutet:

Nicht jedes System braucht Sovereign Cloud. Aber jedes kritische System braucht eine durchdachte Strategie.

Die Realität der nächsten 10-15 Jahre ist hybrid. Legacy-Systeme laufen parallel zu Cloud-Workloads. On-Premise-Infrastruktur koexistiert mit Sovereign Clouds und Standard-Public-Clouds.

Die entscheidenden Fragen sind:

Das erfordert mehr als Cloud-Kompetenz. Das erfordert Architektur-Exzellenz in komplexen, gewachsenen IT-Landschaften. Jemanden, der nicht nur Cloud kann, sondern auch Legacy versteht. Jemanden, der nicht nur berät, sondern entwickelt, modernisiert und betreibt.

Laut Lünendonk erwarten 76% der Unternehmen, dass mindestens 20% ihrer geschäftskritischen Kern-Applikationen in den nächsten 5 Jahren modernisiert werden müssen.³ Die Frage ist: Wie?

Big-Bang-Migrationen scheitern. 68% der Unternehmen berichten, dass Legacy-Systeme ihre Effektivität hemmen – Hauptgründe: Wartungsaufwand (44%), Kosten (37%), Isolation durch nicht integrierte Systeme (37%).¹²

Schrittweise Modernisierung funktioniert:

Das braucht jemanden, der beides kann: Legacy-Systeme verstehen UND moderne Architekturen bauen.

DORA und NIS2 verlangen striktes Third-Party-Risk-Management. Das bedeutet:

Der Cloud-Provider (egal ob AWS ESC, Azure, GCP, OVHcloud) ist dabei nur einer von vielen Lieferanten. Legacy-System-Wartung, Managed Services, Software-Entwicklung, Middleware-Betrieb – alles sind Third Parties, die DORA-konform gemanagt werden müssen.

Die Frage ist: Wer kann das Ende-zu-Ende managen? Wer versteht Legacy, Cloud, Betrieb UND Compliance?

Provider-Wahl

Die AWS European Sovereign Cloud ist kein Gamechanger für Europa. Sie ist ein Symptom – ein Symptom dafür, dass der Bedarf nach digitaler Souveränität da ist. Aber sie löst nicht das eigentliche Problem.

Das eigentliche Problem ist: Die meisten Unternehmen in regulierten Branchen betreiben hybride IT-Landschaften mit massiven Legacy-Anteilen. 72% stehen vor Modernisierung geschäftskritischer Systeme. 61% nutzen für die Mehrheit ihrer Anwendungen veraltete Plattformen. 40% des IT-Budgets geht in technische Schulden.

Digitale Souveränität bedeutet nicht: „Ich wähle die richtige Cloud.“
Digitale Souveränität bedeutet: „Ich kann meine Systeme modernisieren, betreiben, migrieren und ich habe Optionen.“

Wer das ernst nimmt, braucht:

Das ist kein Cloud-Migration-Projekt. Das ist strategische IT-Transformation. Und das bekommt man nicht mit einer Provider-Entscheidung. Das bekommt man mit jemandem, der entwickeln, modernisieren UND betreiben kann – aus einer Hand.

2026 ist das Jahr der Bewährungsprobe: DORA-Aufsicht startet ihre ersten vollständigen Prüfzyklen, Aufsichtsbehörden können erstmals sanktionieren. NIS2-Übergangsfristen laufen aus. Gleichzeitig gehen neue Lösungen wie die AWS ESC produktiv. Wer jetzt strategisch handelt statt nur zu reagieren, verschafft sich einen Wettbewerbsvorteil. Wer ausschließlich auf Cloud-Provider setzt, riskiert neue Abhängigkeiten.

Für den Finanzsektor in Kraft seit 17. Januar 2025.
Kernforderungen:

KRITIS-Erweiterung, Umsetzung bis Oktober 2024.
Betrifft unter anderem:

Kernforderungen: