DORA: Von klassischer IT‑Security zur nachweisbaren Resilienz kritischer End‑to‑End‑Services – inklusive IKT‑Lieferkette und Drittanbietern.

Author: NEXORA Unternehmensberatung GmbH Date: January 2026 Reading time: approx. 13 minutes

Einleitung & Zielgruppe

Mit dem Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) hat die EU einen einheitlichen Rahmen für die digitale operationale Resilienz von Finanzunternehmen geschaffen. Neben klassischen Bausteinen wie IKT‑Risikomanagement, Incident‑Reporting, Tests und Informationsaustausch führt DORA erstmals eine europaweite Aufsicht über kritische IKT‑Drittdienstleister ein. Dieser Beitrag richtet sich an Vorstände, Geschäftsleiter:innen, CROs, CIOs, CISO‑ und Outsourcing‑Verantwortliche in Banken, Wertpapierfirmen, Zahlungsinstituten, E‑Geld‑Instituten, Versicherungen, Pensionskassen, Krypto‑Dienstleistern sowie Fintechs mit EU‑Bezug. Er beleuchtet, was sich durch DORA und den neuen Aufsichtsrahmen für kritische IKT‑Drittdienstleister („kritische Provider“) in der Praxis wirklich ändert – inklusive der neuen EU–UK‑Kooperation.

1. DORA ist mehr als „noch ein Compliance‑Projekt“

In der Theorie kennen viele Häuser DORA als Paket aus fünf Modulen: IKT‑Risikomanagement, Incident‑Reporting, Resilienztests, Management des IKT‑Drittparteienrisikos sowie Informationsaustausch. In der Praxis misst DORA aber nicht, ob ein Framework auf Papier existiert, sondern ob kritische Services unter Stress tatsächlich weiterlaufen können – und ob Auslagerungen so gesteuert werden, dass der Ausfall eines Providers nicht zum Existenzrisiko wird.

Die zentrale Verschiebung: von „wir haben IT‑Security und Policies“ zu „wir können nachweisen, dass unsere kritischen End‑to‑End‑Services resilient sind“ – inklusive Menschen, Prozesse, Daten, Lieferanten, BCP/DR und Wiederanlauf in definierten RTO/RPO. Regulatorisch werden damit IKT‑Risiken und Auslagerungen nicht mehr als Support‑Thema, sondern als Kernrisiken behandelt, die direkt in Geschäftsmodell, Kapitalplanung und Governance hineinwirken.

2. Kritische IKT‑Drittdienstleister: Wer ist betroffen – und warum auch ohne direkten Vertrag?

DORA etabliert ein eigenständiges europäisches Überwachungsrahmenwerk für jene IKT‑Drittdienstleister, die für viele beaufsichtigte Unternehmen systemrelevant sind. Typischerweise handelt es sich um große Cloud‑, Plattform‑ und Infrastruktur‑Anbieter, aber auch um andere zentrale IKT‑Infrastrukturen, auf denen Zahlungsverkehr, Handel, Verwahrung oder Kernbankprozesse aufsetzen.

Die Einstufung als „kritischer IKT‑Drittdienstleister“ erfolgt durch den Gemeinsamen Ausschuss der europäischen Aufsichtsbehörden anhand harmonisierter Kriterien (u.a. Konzentrationsrisiken, Systemrelevanz, Substituierbarkeit, grenzüberschreitende Bedeutung). Für jeden kritischen Anbieter bestimmt der Ausschuss eine federführende Überwachungsbehörde (Lead Overseer – EBA, ESMA oder EIOPA), orientiert am größten Kundenanteil nach Bilanzsumme.

Warum das Finanzunternehmen real betrifft

• Vertrags‑ und Governance‑Druck nach unten: Wird ein Provider (oder ein Subdienstleister in der Kette) als kritisch eingestuft, werden Anforderungen zu Audit‑Rechten, Informationspflichten, Testing, Incident‑Transparenz und Suboutsourcing faktisch „aufsichtsnah“ – auch wenn sie formal im B2B‑Vertrag verankert werden müssen.

• Architektur‑ und Sourcing‑Entscheidungen werden aufsichtsrelevant: Single‑Provider‑Designs, fehlende Portabilität, proprietäre Abhängigkeiten und nicht getestete Exit‑Pläne werden in Prüfungen deutlich sichtbarer und können direkt adressiert werden.

• Indirekte Reichweite („indirekte Kette“): Auch wenn kein direkter Vertrag mit einem Hyperscaler besteht (z.B. SaaS über Integrator), bleibt die Verantwortung, die Risikokette zu verstehen, Kontrollrechte abzubilden und DORA‑konforme Mindestanforderungen entlang der Lieferkette sicherzustellen.

3. Wie die neue Aufsicht über kritische Provider funktioniert

Der Überwachungsrahmen für kritische IKT‑Drittdienstleister ergänzt die klassische Aufsicht über Finanzunternehmen um einen „Makro‑Blick“ auf zentrale IKT‑Knoten.

Zentrale Elemente:

• Einstufung & Lead Overseer: Der Gemeinsame Ausschuss der ESAs bereitet Einstufung und Ernennung kritischer Provider vor und bestimmt eine federführende Überwachungsbehörde (Lead Overseer) je Anbieter.

• Aufgaben des Lead Overseers: Bewertung von Governance, Sicherheits‑ und Risikostrukturen, Anforderung von Informationen und Dokumenten, Durchführung von Untersuchungen und Vor‑Ort‑Prüfungen, Erteilung von Empfehlungen und Abhilfemaßnahmen.

• Folgen & Kosten: Werden Empfehlungen nicht umgesetzt, können nationale Aufsichten beaufsichtigte Finanzunternehmen verpflichten, die Zusammenarbeit mit kritischen Dienstleistern auszusetzen oder zu beenden; die Kosten der Aufsicht tragen die kritischen Provider selbst.

Wichtig für Finanzunternehmen: Die direkte Aufsicht über kritische Provider ersetzt nicht das eigene IKT‑Drittparteien‑Risikomanagement, sondern schafft zusätzlichen Informationsfluss und Aufsichtsimpulse („Top‑down“), die in der eigenen Steuerung zu berücksichtigen sind.

4. Von der Policy zur „Beweisführung“: Was Aufsicht jetzt konkret erwartet

Viele DORA‑Anforderungen waren über Leitlinien von EBA, EZB oder nationale Erwartungshaltungen bereits bekannt. Neu ist der Grad der Standardisierung – etwa über technische Standards zu Auslagerungsregistern – und die klare Erwartung, dass Unternehmen regelmäßig und dokumentiert zeigen können, dass Kontrollen wirken.

Drei Bereiche, in denen Teams real nachschärfen müssen:

4.1 Service‑Map statt Systemliste

Statt einer reinen System‑Inventarliste erwarten Aufsichten eine Service‑Perspektive: kritische Funktionen/Services (z.B. „SEPA Instant Payments“, „Krypto‑Custody“, „Onboarding/KYC“) mit End‑to‑End‑Flows, RTO/RPO, Datenklassifikation und klarer Owner‑Struktur. Diese Service‑Maps müssen sichtbar machen, welche externen IKT‑Drittdienstleister an welcher Stelle eingebunden sind – inklusive Subdienstleister‑Ketten.

4.2 Incident‑Handling als echter Betriebsprozess

DORA verlangt mehr als definierte Meldeschwellen. Erwartet werden:

• funktionsfähige Runbooks mit klaren Rollen und Eskalationswegen,

• Triage‑Modelle, die auch Drittanbieter‑Incidents strukturiert erfassen,

• Kommunikationskaskaden (intern, Kunden, Aufsicht) und

• konsequente Post‑Mortems mit Lessons Learned und nachweisbaren Verbesserungen.

Hier zeigt sich unmittelbar, wie schnell kritische Provider technische Root‑Cause‑Informationen, Log‑Auszüge und Remediation‑Nachweise liefern – und ob entsprechende Rechte vertraglich gesichert sind.

4.3 Resilienztests, die „wehtun dürfen“

Resilienztests unter DORA sollen nicht zur Formalie verkommen. Tabletop‑Übungen, technische Tests (inkl. Failover‑Szenarien über Provider‑Grenzen hinweg) und realistische Störfälle – etwa Ausfall eines Identity‑Providers in der Peak‑Zeit – müssen geplant, durchgeführt und mit klaren Maßnahmen verknüpft werden. Aufsicht interessiert sich nicht nur für den Testplan, sondern für die Kette: Findings, Entscheidungen, Umsetzungsstand und erneute Tests.

5. Drittparteirisiko: die neuen Mindestbausteine in Verträgen und Steuerung

DORA zwingt Finanzunternehmen, IKT‑Drittdienstleisterbeziehungen nicht nur zu sourcen, sondern aktiv zu steuern – über den gesamten Lebenszyklus.

Typische Nachbesserungsfelder in der Praxis:

• Klarheit über kritische/wichtige Funktionen: Welche Services fallen darunter, welche Provider hängen daran, wie werden diese in Verträgen und SLAs abgebildet.​

• Audit‑ und Informationsrechte (inkl. Subdienstleister): Rechte auf Vor‑Ort‑Prüfungen, Zugriff auf relevante Informationen, Teilnahme an Tests und Incident‑Simulationen, durchsetzbar auch gegenüber Subdienstleistern.

• Messbare SLAs/SLOs und Incident‑Regelungen: Definierte Zeitfenster für Meldungen, Mindestinhalte (Impact, Ursachen, Maßnahmen), Zugriff auf Root‑Cause‑Information zumindest auf Abstraktionsebene.

• Suboutsourcing‑Governance: Transparenz über Subdienstleister, Zustimmung‑/Notification‑Mechanismen, Kettenkontrollen entlang der gesamten IKT‑Lieferkette.

• Exit‑Strategie: Daten‑ und Workload‑Portabilität, Transition Assistance, testbare Exit‑Szenarien (z.B. Desktop‑Exercises) und realistische Kostenannahmen.

Für kritische Provider werden diese Bausteine zunehmend zum Marktstandard im regulierten Umfeld; Standardbedingungen ohne DORA‑kompatible Klauseln werden im Aufsichtsdialog schwer zu rechtfertigen sein.

6. Cross‑Border‑Komplexität und der EU–UK‑MoU‑„Hook“

Viele relevante IKT‑Provider, Security‑Dienstleister und Konzern‑Delivery‑Einheiten sitzen oder operieren in mehreren Jurisdiktionen (EU, UK, USA, APAC). DORA ist EU‑Recht – die Wertschöpfungs‑ und Datenketten sind aber global.

Am 14. Januar 2026 haben die europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) und die britischen Aufseher (BoE, PRA, FCA) ein Memorandum of Understanding (MoU) zur Kooperation bei der Aufsicht über kritische IKT‑Drittdienstleister bzw. Critical Third Parties (CTPs) unterzeichnet. Das MoU schafft einen Rahmen für Informationsaustausch, Abstimmung von Aufsichtshandlungen und Koordination in Incident‑Situationen (z.B. großflächige Cyber‑Attacken oder Stromausfälle).

Wofür ein MoU in der Praxis gut ist – und wofür nicht:

• Gut: Es reduziert Reibungsverluste zwischen Behörden, erleichtert konsistente Aufsicht über grenzüberschreitende Strukturen und kann Doppelprüfungen begrenzen.

• Nicht ausreichend: Es ersetzt keine vertraglichen Kontrollrechte, keine belastbaren Exit‑Pläne und keine technisch getestete Portabilität von Daten und Workloads.

Pragmatische Konsequenz: Cross‑Border‑Themen dürfen nicht als „späteres Legal‑Detail“ behandelt werden. Sie gehören in das Vendor‑ und Architektur‑Design: welche Daten liegen wo, wer kann im Incident welche Informationen liefern, und wie schnell ist eine Migration im Worst‑Case-Szenario realistisch möglich.

7. „Was muss ich morgen tun?“ – ein 30/60/90‑Tage‑Fahrplan

Um von der Analyse in die Umsetzung zu kommen, hat sich ein gestufter Ansatz bewährt.

30 Tage

• Kritische Services definieren (nicht nur Systeme), Service‑Owner benennen, Ziel‑RTO/RPO festlegen.​

• Vendor‑Landschaft mappen: direkte Provider plus wesentliche Subdienstleister, inkl. Zuordnung zu kritischen Services.

• Schnell‑Check der Top‑10‑Verträge: Audit/Informationen, Incident‑Regelungen, Suboutsourcing, Exit‑Klauseln – wo bestehen offensichtliche Lücken.​

60 Tage

• Incident‑Prozesse operationalisieren: Runbooks, Kommunikationsmatrix, erste Tests/Tabletop‑Übungen mit Einbeziehung zentraler Provider.

• Resilienztest‑Plan erstellen: Szenarien über Provider‑Grenzen hinweg, inkl. Abhängigkeiten zu kritischen und potenziell kritischen Dienstleistern.​

• Contract‑Remediation‑Plan starten: Priorisierung nach Kritikalität, Verhandlungsmacht und zeitkritischen DORA‑Lücken.

90 Tage

• Exit‑Strategie pro kritischem oder besonders wichtigem Provider konkretisieren und mindestens als Desktop‑Exercise testen.​

• KPI/KRI‑Reporting für IKT‑Risiko und Provider‑Performance etablieren, abgestimmt mit Risikoberichterstattung und IT‑Governance.

• Aufsichtsfähige Evidenzpakete zusammenstellen (Policies, Service‑Maps, Auslagerungsregister, Testergebnisse, Incident‑Dokumentation, Remediation‑Nachweise).

DORA macht IKT‑Resilienz und Drittparteienrisiko zum integralen Bestandteil des Geschäftsmodells – und die neuen Regeln für kritische IKT‑Drittdienstleister sorgen dafür, dass Anforderungen bis in Architektur‑Entscheidungen, Verträge und Exit‑Strategien hineinwirken. Wer seine IKT‑Lieferkette heute strukturiert analysiert und steuert, reduziert nicht nur Aufsichts‑ und Reputationsrisiken, sondern gewinnt echte Robustheit für die nächste Generation digitaler Finanzservices.