Wie Sie DORA-konforme operative Resilienz ohne Abhängigkeit von US-Cloud-Anbietern erreichen

Der Digital Operational Resilience Act (DORA, Verordnung EU 2022/2554) ist seit dem 17. Januar 2025 verbindlich und legt einheitliche Anforderungen an die ICT-Sicherheit im gesamten europäischen Finanzsektor fest. DORA gliedert seine Anforderungen in fünf Säulen: ICT-Risikomanagement, Vorfallmanagement und -meldung, Tests zur digitalen Betriebsresilienz, Drittparteien-ICT-Risikomanagement und Austausch von Cyberbedrohungsinformationen. Jede Säule setzt voraus, dass Finanzinstitute die tatsächliche Kontrolle über ihre ICT-Infrastruktur und die darin verarbeiteten Daten behalten.

Diese Annahme stellt ein grundlegendes Problem für europäische Finanzinstitute dar, die auf Cloud-Anbieter mit Hauptsitz in den USA setzen. Wenn kritische Datenplattformen von Anbietern betrieben werden, die dem CLOUD Act und FISA Section 702 unterliegen, hängt die Betriebsresilienz der Bank von einem ausländischen Rechtsregime ab, das sie nicht kontrollieren kann. Eine US-Regierungsanfrage auf Datenzugriff löst keine Incident-Response-Prozesse der Bank aus – sie umgeht diese vollständig. Der Anbieter erfüllt die Anforderung, ohne die Bank zu informieren, und die Bank kann die Datensouveränität, die DORA implizit fordert, nicht nachweisen.

Dieser Leitfaden beleuchtet jede DORA-Säule im Kontext der Abhängigkeit von US-Cloud-Anbietern und erklärt, wie europäische Finanzinstitute durch eine souveräne Architektur echte Betriebsresilienz erreichen – indem sie das Risiko ausländischen Zugriffs eliminieren statt es zu verwalten.

Executive Summary

Kernaussage: DORAs fünf Säulen verlangen von europäischen Finanzinstituten den Nachweis operativer Resilienz in den Bereichen ICT-Risikomanagement, Incident-Handling, Resilienztests, Drittparteien-Überwachung und Informationsaustausch. Jede Säule wird geschwächt, wenn kritische Datenplattformen von Anbietern betrieben werden, die ausländischen Zugriffsrechten unterliegen. DORA-konforme Resilienz erfordert eine souveräne Architektur: vom Kunden kontrollierte Verschlüsselung, Single-Tenant-Bereitstellung in Europa und operative Unabhängigkeit von US-Anbieter-Infrastrukturen.

Warum das relevant ist: DORA-Sanktionen reichen bis zu 10 % des Jahresumsatzes für Finanzinstitute und bis zu 5 Mio. € für kritische ICT-Anbieter. Im November 2025 haben die europäischen Aufsichtsbehörden 19 ICT-Dienstleister als kritisch eingestuft, darunter AWS, Microsoft Azure und Google Cloud, die damit der direkten EU-Aufsicht unterliegen. Die BaFin erwartet erste DORA-Compliance-Ergebnisse bis Ende 2025. Institute, deren Resilienz von Anbietern abhängt, die sie nicht vollständig überwachen können, riskieren sowohl regulatorische Strafen als auch die operationellen Risiken, die DORA verhindern soll.

5 Wichtige Erkenntnisse

1. DORAs ICT-Risikomanagement-Säule verlangt Kontrolle, die Sie nicht an einen US-Anbieter delegieren können. Finanzinstitute müssen ICT-Risiken identifizieren, schützen, erkennen, darauf reagieren und sich davon erholen. Hält der Anbieter die Verschlüsselungsschlüssel und unterliegt ausländischen Zugriffsrechten, verbleibt ein Restrisiko, das sich nicht allein durch vertragliche Maßnahmen beseitigen lässt.
2. Vorfallmeldepflichten setzen vollständige Transparenz bei Datenzugriffen voraus. DORA verlangt die Klassifizierung und Meldung schwerwiegender ICT-Vorfälle innerhalb strenger Fristen. Erfüllt ein US-Anbieter eine Regierungsanfrage, ohne die Bank zu informieren, kann die Bank nicht melden, was sie nicht sieht.
3. Resilienztests müssen Szenarien ausländischen Regierungszugriffs abdecken. DORA schreibt Schwachstellenanalysen, Penetrationstests und szenariobasierte Tests vor. Institute sollten CLOUD-Act-Anfragen als Testfall für jede kritische Plattform eines US-Anbieters einbeziehen.
4. Drittparteien-Risikomanagement verlangt die Bewertung der Anbieterjurisdiktion, nicht nur von Sicherheitszertifikaten. DORA fordert explizit die Überwachung von ICT-Drittparteien, einschließlich einer Risikobewertung, die die rechtliche Exponierung des Anbieters gegenüber ausländischen Regierungsanfragen berücksichtigt.
5. Souveräne Architektur eliminiert Abhängigkeit, statt sie zu verwalten. Vom Kunden kontrollierte Verschlüsselungsschlüssel, Single-Tenant-Bereitstellung in Europa und durch Richtlinien erzwungene Datenresidenz beseitigen das Risiko ausländischen Zugriffs auf architektonischer Ebene und erfüllen alle fünf DORA-Säulen gleichzeitig.

DORAs Fünf Säulen und das Problem der US-Anbieter-Abhängigkeit

Säule 1: ICT-Risikomanagement

DORA Artikel 6 verlangt von Finanzinstituten die Etablierung umfassender ICT-Risikomanagement-Rahmenwerke, die Identifikation, Schutz, Erkennung, Reaktion und Wiederherstellung abdecken. Das Rahmenwerk muss interne und externe Risiken, einschließlich der von Drittanbietern ausgehenden, adressieren und die Governance bis auf Vorstandsebene ausdehnen.

Für deutsche Banken gilt das BaFin-BAIT-Rahmenwerk (anwendbar bis Dezember 2026 für überleitende Institute) schon lange als Pflicht für das IT-Risikomanagement. DORA Artikel 6(4) führt eine dedizierte ICT-Risikokontrollfunktion mit definierten Unabhängigkeitsanforderungen ein, die laut BaFin der bisherigen BAIT-Informationssicherheitsfunktion ähnelt, aber nicht identisch ist.

Die zentrale Herausforderung: Ein ICT-Risikomanagement, das „US-Regierungszugriff über Cloud-Anbieter“ als Risiko identifiziert, aber aufgrund von Standardvertragsklauseln oder dem EU-US Data Privacy Framework als akzeptabel einstuft, baut Resilienz auf unsicherer rechtlicher Basis auf. SCCs und das DPF sind rechtliche Übertragungsmechanismen, aber keine technischen Schutzmaßnahmen. Sie verhindern nicht, dass eine CLOUD-Act-Anfrage erfolgreich ist. DORA verlangt technische Maßnahmen, die Risiken tatsächlich steuern – nicht nur dokumentieren. Ist das Risiko architektonisch, muss auch die Antwort architektonisch sein.

Säule 2: Incident Management und Reporting

DORA verlangt strukturierte Prozesse zur Erkennung, Klassifizierung und Meldung schwerwiegender ICT-Vorfälle. Die EBA schreibt eine Erstmeldung innerhalb von 4 Stunden nach Klassifizierung, einen Zwischenbericht innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats vor. Bedeutende Vorfälle müssen den zuständigen nationalen Behörden gemeldet werden.

Diese Säule setzt vollständige Transparenz über Ereignisse voraus, die die Daten des Instituts betreffen. Erhält ein US-Anbieter eine National Security Letter oder eine FISA-Gerichtsverfügung zur Herausgabe von Daten, kann es ihm gesetzlich untersagt sein, den Kunden zu informieren. Das Finanzinstitut hat keine Transparenz über den Zugriff und kann den Vorfall daher nicht klassifizieren oder melden. Es entsteht eine strukturelle Lücke im Incident Management, die sich durch Prozessoptimierung nicht schließen lässt, weil sie im Anbieter-Verhältnis selbst angelegt ist.

Souveräne Architektur löst dieses Problem, indem der Anbieter unabhängig von rechtlichen Anforderungen keinen Zugriff auf entschlüsselte Daten erhält. Kontrolliert das Institut die Verschlüsselungsschlüssel im eigenen HSM, liefert eine Regierungsanfrage an den Anbieter nur Chiffretext. Das Audit Logging des Instituts erfasst alle legitimen Zugriffe und stellt die vollständige Transparenz sicher, die DORA für die Vorfallmeldung verlangt.

Säule 3: Tests zur digitalen Betriebsresilienz

DORA verlangt regelmäßige Tests der Betriebsresilienz, darunter Schwachstellenanalysen, Penetrationstests und szenariobasierte Übungen. Kritische Institute müssen unter Umständen Advanced Threat-Led Penetration Testing (TLPT) nach dem TIBER-EU-Framework durchführen.

Resilienztests, die Szenarien ausländischen Regierungszugriffs ausklammern, liefern für Institute mit US-betriebenen Cloud-Services ein unvollständiges Bild. Ein umfassendes Testprogramm sollte das Szenario abbilden, in dem ein Anbieter kritischer Datenplattformen zur Herausgabe von Kundendaten gezwungen wird – und prüfen, ob die Architektur des Instituts eine Datenexponierung verhindert, ob Überwachungssysteme den Versuch erkennen und ob Incident-Response-Prozesse korrekt aktiviert werden.

Mit kundengesteuerter Verschlüsselung ist das Testergebnis eindeutig: Der Anbieter kann keine lesbaren Daten liefern. Das Szenario wird zum Nachweis architektonischer Kontrollen statt zur Offenlegung eines nicht beherrschbaren Risikos.

Säule 4: Drittparteien-ICT-Risikomanagement

DORAs Anforderungen an das Drittparteien-Risikomanagement gehören zu den folgenreichsten Bestimmungen. Finanzinstitute müssen Risiken von ICT-Anbietern bewerten und kontinuierlich überwachen, vertragliche Vereinbarungen mit Sicherheitsklauseln, Audit-Rechten, Kündigungsrechten, Exit-Strategien und Vorfallbenachrichtigungen sicherstellen. Die europäischen Aufsichtsbehörden haben im November 2025 19 Anbieter als kritische ICT-Drittparteien (CTPPs) eingestuft, darunter AWS, Microsoft Azure, Google Cloud und weitere, die damit der direkten EU-Aufsicht unterliegen.

DORA Artikel 28(3) verpflichtet Finanzinstitute zur Führung eines Registers aller vertraglichen Vereinbarungen mit ICT-Drittparteien. Die BaFin verlangte von deutschen Instituten die Erstübermittlung dieses Registers bis zum 11. April 2025. Das Register muss nicht nur das Bestehen der Beziehung, sondern auch Art der Leistungen, Datenstandorte und Risikoklassifikationen dokumentieren.

Für Institute, die US-betriebene Plattformen für sensible Datenbewegungen nutzen, muss die Drittparteien-Risikoanalyse die juristische Exponierung des Anbieters ehrlich bewerten. Die EBA hat klargestellt, dass Zertifizierungen wie ISO 27001 für die Risikobewertung nicht ausreichen. Die Bewertung muss klären, ob der Anbieter nach ausländischem Recht zur Herausgabe von Kundendaten gezwungen werden kann – und ob die Architektur des Instituts in diesem Fall eine Datenexponierung verhindert.

DORA verlangt zudem tragfähige Exit-Strategien. Finanzinstitute müssen nachweisen, dass sie von jedem ICT-Anbieter ohne Betriebsunterbrechung wechseln können. Diese Anforderung adressiert direkt das Risiko der Anbieterabhängigkeit, das durch die Konzentration kritischer Funktionen bei wenigen US-Hyperscalern entsteht. Institute sollten prüfen, ob ihre Architektur Migration unterstützt und ob alternative Anbieter unter europäischer Jurisdiktion gleichwertige Funktionalität bieten können.

Säule 5: Austausch von Cyberbedrohungsinformationen

DORA ermutigt Finanzinstitute zur Teilnahme an Threat-Intelligence-Sharing-Initiativen. Die Teilnahme ist nicht verpflichtend, aber Institute müssen die Aufsichtsbehörden über ihre Aktivitäten informieren. Effektiver Austausch setzt voraus, dass Institute ihr eigenes Bedrohungsbild kennen. Fehlt Transparenz über potenziellen, durch Cloud-Anbieter erzwungenen Regierungszugriff, ist das Bedrohungsmodell unvollständig. Souveräne Architektur beseitigt diese Unsicherheit und ermöglicht es, den Austausch auf tatsächliche externe Cyberbedrohungen zu konzentrieren.

Wie souveräne Architektur unter DORA aussieht

DORA-konforme Betriebsresilienz ohne Abhängigkeit von US-Cloud-Anbietern erfordert drei architektonische Fähigkeiten, die dem GTM-Prinzip folgen: Datensouveränität ist eine technische Architektur, keine Vertragsklausel.

Vom Kunden kontrollierte Verschlüsselungsschlüssel

Das Institut generiert und speichert Verschlüsselungsschlüssel im eigenen Hardware-Sicherheitsmodul – On-Premises oder in einem vom Institut kontrollierten europäischen Rechenzentrum. Die Cloud-Plattform verarbeitet verschlüsselte Daten, besitzt aber nie die Entschlüsselungsschlüssel. Das unterscheidet sich grundlegend von BYOK-Modellen, bei denen der Anbieter Zugriff auf Schlüsselmaterial behält. Der Test ist einfach: Kann der Anbieter auf rechtliche Anordnung entschlüsselte Daten liefern? Wenn ja, erfüllt das Verschlüsselungsmodell nicht die DORA-Anforderungen an das Risikomanagement kritischer Funktionen.

Single-Tenant-Bereitstellung in Europa

Multi-Tenant-Plattformen bedienen Tausende Kunden auf gemeinsam genutzter Infrastruktur, optimiert für die globale Reichweite des Anbieters. Single-Tenant-Bereitstellung auf dedizierter europäischer Infrastruktur bedient einen Kunden auf isolierten Systemen, deren Zugriffskontrollen europäischem Recht unterliegen. In Kombination mit kundengesteuerter Verschlüsselung eliminiert Single-Tenant-Bereitstellung sowohl den logischen (Verschlüsselungsschlüssel) als auch den physischen (geteilte Infrastruktur) Zugriffsweg, der die Anbieterabhängigkeit schafft.

Operative Unabhängigkeit und Exit-Fähigkeit

DORA verlangt tragfähige Exit-Strategien für alle ICT-Drittparteien, die kritische Funktionen unterstützen. Finanzinstitute benötigen Plattformen, die auf Standardprotokollen basieren und Datenportabilität sowie operative Unabhängigkeit ermöglichen. Die Architektur sollte den Einsatz On-Premises, in einer europäischen Private Cloud oder in einer vom Anbieter gehosteten europäischen Infrastruktur erlauben – mit der Flexibilität, zwischen diesen Optionen ohne Datenverlust oder Betriebsunterbrechung zu migrieren. Das adressiert DORAs Konzentrationsrisiko und die BaFin-Erwartung, ausgelagerte Funktionen zurückholen zu können.

DORA-Säulen im Vergleich: US-Anbieter-Abhängigkeit vs. souveräne Architektur

Umsetzung: Der Weg zur DORA-konformen souveränen Architektur

Phase 1: Kritische ICT-Abhängigkeiten erfassen

Nutzen Sie das DORA-Register als Ausgangspunkt. Identifizieren Sie jede ICT-Drittparteienbeziehung, die kritische oder wichtige Funktionen unterstützt, und bewerten Sie Jurisdiktion, Verschlüsselungsmodell und Schlüsselmanagement-Architektur jedes Anbieters. Dokumentieren Sie für jeden US-betriebenen Dienst, ob der Anbieter unter irgendeinem Umstand – auch unter rechtlichem Zwang – auf entschlüsselte Kundendaten zugreifen kann. Diese Bewertung fließt direkt in Ihr ICT-Risikomanagement ein und erfüllt die BaFin-Erwartung einer ehrlichen Risikoeinschätzung.

Phase 2: Nach regulatorischer Exponierung priorisieren

Nicht alle ICT-Dienste bergen dasselbe DORA-Risiko. Priorisieren Sie Dienste, die die sensibelsten Daten verarbeiten: Kundenfinanzdaten, Managed File Transfer für regulatorische Einreichungen, interne Audit-Kommunikation, grenzüberschreitende Transaktionsdaten und Vorstandskorrespondenz. In diesen Bereichen hätte ein ausländischer Regierungszugriff die gravierendsten regulatorischen, reputativen und operationellen Folgen.

Phase 3: Souveräne Architektur implementieren

Überführen Sie priorisierte Funktionen auf Plattformen mit kundengesteuerter Verschlüsselung, Single-Tenant-Bereitstellung in Europa und durch Richtlinien erzwungener Datenresidenz mit Geofencing. Validieren Sie durch unabhängige Tests, dass der Anbieter keinen Zugriff auf entschlüsselte Daten hat. Richten Sie umfassendes Audit Logging ein, um die DORA-Vorgaben für Incident Reporting und kontinuierliches Monitoring zu erfüllen. Etablieren Sie Incident-Response-Prozesse, die die neuen architektonischen Möglichkeiten berücksichtigen.

Phase 4: Compliance durch Nachweise belegen

DORA-Compliance wird durch Nachweise, nicht durch Behauptungen belegt. Halten Sie Dokumentationen bereit, die die Schlüsselgenerierung im eigenen HSM, die Single-Tenant-Konfiguration, Geofencing und vollständige Audit-Trails zeigen. Bereiten Sie dieses Nachweispaket für BaFin-Prüfungen, EZB-Aufsichtsreviews und die periodischen Resilienztests vor, die DORA verlangt. Nachweisbare Souveränität ist der beste Schutz.

Betriebsresilienz erfordert operative Souveränität

DORAs fünf Säulen beschreiben, wie Betriebsresilienz aussieht. Doch Resilienz ist nur dort möglich, wo Kontrolle besteht. Werden kritische Datenplattformen eines Finanzinstituts von Anbietern betrieben, die ausländischen Zugriffsrechten unterliegen, entsteht eine strukturelle Lücke, die keine Vertragsklausel, Zertifizierung oder Prozessoptimierung schließen kann.

Souveräne Architektur – basierend auf kundengesteuerter Verschlüsselung, Single-Tenant-Betrieb in Europa und echter operativer Unabhängigkeit – schließt diese Lücke, indem sie die Abhängigkeit eliminiert statt sie zu verwalten. Europäische Finanzinstitute, die diese Architektur implementieren, erfüllen nicht nur DORA – sie schaffen die zero trust Resilienz-Infrastruktur, die Europas Finanzaufsicht fordert.

Kiteworks unterstützt europäische Finanzinstitute beim Erreichen DORA-konformer Betriebsresilienz

Das Kiteworks Private Data Network liefert eine souveräne Architektur, die gezielt für das DORA-Fünf-Säulen-Modell entwickelt wurde. Kiteworks setzt auf ein vom Kunden verwaltetes Verschlüsselungsmodell: Das Institut generiert und verwahrt die Schlüssel im eigenen HSM. Kiteworks kann keine entschlüsselten Inhalte einsehen und kann ausländischen Regierungsanfragen zur Herausgabe lesbarer Daten nicht nachkommen, da es die Schlüssel nicht besitzt.

Kiteworks wird als Single-Tenant-Instanz auf dedizierter europäischer Infrastruktur bereitgestellt – On-Premises, in der Private Cloud oder als gehärtete virtuelle Appliance – und bietet damit die Flexibilität und Exit-Fähigkeit, die DORA verlangt. Integriertes Geofencing erzwingt Datenresidenz auf Plattformebene. Umfassendes Audit Logging unterstützt die DORA-Vorgaben für Incident Reporting und liefert die Monitoring-Nachweise, die Aufsichtsbehörden erwarten. Kiteworks unterstützt DORA-Compliance über alle fünf Säulen hinweg mit einem einheitlichen Ansatz für das ICT-Risikomanagement sensibler Inhalte.

Die Plattform vereint sicheres Filesharing, E-Mail-Schutz, Managed File Transfer und Web-Formulare unter einem einzigen Governance-Rahmen. So können Finanzinstitute die DORA-Anforderungen an Drittparteienrisiken über alle Datenbewegungskanäle hinweg mit einer Architektur, einem Kontrollsatz und einem Nachweispaket erfüllen.

Erfahren Sie mehr darüber, wie Sie DORA-konforme Betriebsresilienz ohne Abhängigkeit von US-Cloud-Anbietern erreichen – vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen 

• Blogbeitrag  
  Datensouveränität: Best Practice oder regulatorische Pflicht?
• eBook  
  Datensouveränität und DSGVO
• Blogbeitrag  
  Vermeiden Sie diese Fallstricke bei der Datensouveränität
• Blogbeitrag  
  Best Practices für Datensouveränität
• Blogbeitrag  
  Datensouveränität und DSGVO [Verständnis von Datensicherheit]