Cyber Resilienz
Digital Operational Resilience Act (DORA): Was steht drin — und warum gibt es ihn?
Kernaussagen
- DORA zielt auf digitale operationelle Resilienz im Finanzsektor: konsistente EU-Anforderungen an IKT-Risikomanagement, Vorfälle, Wiederherstellung und Prüfungen/Tests.
- IKT-Drittanbieter sind zentral: Verträge, Exit-/Substitutionslogik und Registerpflichten; ausgewählte „kritische“ Anbieter stehen unter Aufsicht der ESAs (Lead Overseer-Modell).
- Die drei Europäischen Aufsichtsbehörden — EBA, EIOPA, ESMA — setzen technische Regulierungsstandards und Leitlinien um; nationale Aufsicht bleibt eingebunden.
- DORA ist kein „IT-Nebenprojekt“: er verbindet Einkauf, Risiko, Business Continuity und Security mit messbaren Nachweisen.
- Umsetzung braucht oft Spezialisten, die regulatorische Sprache und Architektur/Operations zusammenführen — Engpass auch im deutschen Markt.
Der Digital Operational Resilience Act (DORA) ist die EU-Antwort auf ein strukturelles Problem: Finanzmarktteilnehmer sind von IKT so abhängig wie nie — gleichzeitig waren Lieferketten, Cloud-Konzentration und operative Tests historisch uneinheitlich geregelt. DORA zwingt den Sektor zu gemeinsamer Disziplin — nicht zu mehr Papier um ihrer selbst willen, sondern zu nachweisbarer Steuerbarkeit bei Störungen und Angriffen.
Dieser Text ordnet Motivation, Inhalt und Akteure ein — mit offiziellen Einstiegen bei EIOPA, EBA und der übergreifenden ESMA/ESAs-Arbeit. Keine Rechtsberatung; die jeweilige Aufsicht und Primärtexte haben Vorrang.
Verlässliche Einstiege:
- EIOPA — Digital Operational Resilience Act (DORA)
- EBA — operational resilience / DORA
- Marktnahe Einordnung u. a. Latham & Watkins — insights (internationale Kanzlei-Publikationen zu DORA und Finanzregulierung)
Das Politikziel in einem Satz
Störungen in zentralen IKT-Dienstleistern oder Kaskadenfehler sollen weniger systemisch werden — durch Governance, vertragliche Mindestständards, Prüfregister und Übungen, die der Aufsicht erläutert werden können.
Kernelemente — was Organisationen typischerweise bauen
- IKT-Risikomanagement als integrierter Bestandteil des Risikobildes — nicht lose „Security-Projekt“.
- IKT-Vorfälle: Melde- und Eskalationslogik, auch bei Dienstleistern; konsistente Schweregrade entlang der ESAs-Vorgaben.
- Digital operational resilience testing: angepasst an Größe und Risiko — inkl. Szenarien, die realistisch genug sind, nicht nur Checkbox.
- IKT-Drittanbieter-Management: Register, Due Diligence, Exit- und Substitutionsüberlegungen — auch wenn „alles bei Hyperscaler X läuft“.
- Aufsichtliche Koordination: nationale Behörden und ESAs — bei kritischen Drittanbietern kommt das Lead-Overseer-Modell ins Spiel.
Typische Stolpersteine in Programmen
- Register als Excel-Friedhof: ohne Owner und Qualitäts-SLA veralten Daten vor dem ersten Audit.
- Tests ohne Konsequenz: Findings landen nicht in Risiko- und Budgetzyklen.
- Verträge ohne Mitwirkungspflichten: Provider liefern keine Incident-Evidence — Nachträge dauern in Krisen zu lang.
- Organisationsblindheit: BCM kennt die Cloud-Ketten nicht — und Security kennt BCM-Prozesse nicht.
EIOPA, EBA, ESMA — gemeinsame Standards
Die European Supervisory Authorities haben unter DORA Regulatory Technical Standards, Leitlinien und Statements veröffentlicht bzw. fortgeschrieben — etwa zu IKT-Risiko und Drittanbietern oder Incident-Klassifikation (öffentliche EIOPA/EBA-News wie zu ersten Regelsets und Konsultationen). Für internationale Gruppen zählt: Konsistenz über Entitäten statt Insellösungen je Lizenz.
Kritische IKT-Drittanbieter (CTPPs)
Die ESAs benennen kritische Provider nach Kriterien — dann greift direkte aufsichtliche Aufsicht durch einen Lead Overseer. Für Finanzentitäten heißt das: Abhängigkeiten und Konzentrationsrisiken müssen benannt, gesteuert und substituierbar gemacht werden — zumindest in Plan B/C.
Vertiefung: DORA und Cyber Resilienz aus HR-Sicht
Programme scheitern oft an fehlenden Schnittstellenprofilen: jemand muss regulatorische Texte in Release-, Vendor- und Krisenprozesse übersetzen. Das sind keine „reinen Juristen“ und keine „reinen Ops“ — sondern erfahrene Hybridrollen.
Wer parallel Resilience-Grundlagen aufbaute, sollte DORA als weitere Evidenzschicht mappen, nicht als zweites paralleles Universum.
Checkliste — 90-Tage-Start
Schneller Projektstart
- Scope je juristischer Entität klären (keine Vermutung).
- IKT-Register: Minimaldatenmodell + Owner + monatliche Qualitäts-KPI.
- „Top 20“ Drittanbieter nach substituierbarer Kritikalität rangieren.
- Incident Playbook mit Provider-Pflichten synchronisieren.
- Testprogramm: 1 realistische Übung quartalsweise — mit Management-Lernpunkten.
Fazit
DORA ist operationelle Resilienz im Finanzsektor als Regelstandard — mit starkem IKT-Lieferketten-Fokus und aufsichtlicher Durchsetzung. Organisationen gewinnen, die Register, Tests und Verträge ernst nehmen — und Profile finden, die Regulatorik und Technik zusammenführen.
Hinweise zur Besetzung schwer zu findender Rollen: Cybersecurity Recruiting und IT Recruiting für breitere Delivery-Rollen.
Passender nächster Schritt
Häufige Fragen
- Ja. Typisch sind Rollen zwischen Enterprise/Segment-IT, Informationssicherheit, Risiko, BCM und Vendor Management. Wir definieren Outcomes (z. B. Registerqualität, Verbesserung der Substituierbarkeit kritischer Provider, Testprogramm-Reife) und suchen aktiv — auch dort, wo klassische Stellenanzeigen wenig liefern. Shortlists sind auf Audit- und Aufsichtsdialog vorbereitet.
- Nein — der Kreis der Finanzentitäten ist breiter (u. a. Wertpapierfirmen, Versicherungen und relevante Finanzinfrastruktur je nach nationaler Umsetzung und Liste). Die exakte Einordnung ist verbindlich über Ihre Aufsicht und Primärquellen der ESAs.
- Beide adressieren IKT-Risiken und Vorfallfähigkeit; Zuständigkeiten und Scope unterscheiden sich. Viele Organisationen benötigen eine gemeinsame IKT-Themenliste ohne Doppelarbeit — aber ohne naive „ein Programm für alles“-Vereinfachung.