Von Markus Groß auf Dienstag, 06. Februar 2024
Kategorie: IT

DORA einfach erklärt – Was das neue EU-Gesetz wirklich bedeutet

S

eit Jahren diskutieren Politik, Wirtschaft und IT-Sicherheits-Expert:innen über die Frage, wie man die digitale Widerstandsfähigkeit (Resilienz) von Finanzunternehmen in Europa einheitlich, verbindlich und zukunftsfähig gestalten kann. Cyberangriffe, Systemausfälle und Abhängigkeiten von kritischen Dienstleistern sind längst nicht mehr theoretische Risiken, sondern harte Realität. Mit dem Digital Operational Resilience Act – kurz DORA – hat die Europäische Union nun ein Regelwerk geschaffen, das genau hier ansetzt: einheitliche, verbindliche und umfassende Anforderungen an den Umgang mit IKT-Risiken in der Finanzbranche. Das Ziel ist klar: Finanzunternehmen sollen in der Lage sein, auch unter extremen digitalen Störungen weiter handlungsfähig zu bleiben. Doch was heißt das konkret? Und warum betrifft es so viele Unternehmen viel direkter, als manche denken?

Dieser Beitrag erklärt DORA verständlich und praxisnah: von Geltungsbereich und Kernanforderungen über Governance und Testkonzepte bis hin zu konkreten Umsetzungsschritten, KPIs und typischen Fallstricken. Er richtet sich an Praktiker:innen, die in kurzer Zeit einen klaren Umsetzungsplan brauchen – und an Führungskräfte, die wissen wollen, wofür sie Verantwortung tragen.

Was steckt hinter DORA?

Rechtsnatur und Zielsetzung. DORA ist keine lose Sammlung von Empfehlungen, sondern eine EU-Verordnung. Sie gilt ab dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten, ohne dass es einer nationalen Umsetzung bedarf. Damit verfolgt die EU den Ansatz, unterschiedliche nationale Anforderungen zu ersetzen und einen einheitlichen, sektorspezifischen Rahmen für digitale operative Resilienz zu schaffen. Parallel wurden über eine begleitende Richtlinie sektorale Rechtsakte (u. a. CRD, Solvency II, MiFID II) angepasst, um die DORA-Vorgaben sauber in die Aufsichtspraxis zu integrieren.

Integrierter Ansatz statt Silos. Während bisher zahlreiche Regelwerke einzelne Facetten adressierten – Informationssicherheit (z. B. ISO/IEC 27001), IKT-Risikomanagement (z. B. EBA-Leitlinien), Business Continuity/Notfallmanagement (z. B. BSI-Standard 200-4), Vorfallmeldung (z. B. PSD2) – führt DORA diese Themen in einem konsistenten, durchgängigen Rahmen zusammen. Im Zentrum steht Operational Resilience: die Fähigkeit, kritische Geschäftsprozesse selbst bei massiven IT-Störungen, Cyberangriffen oder dem Ausfall von Dienstleistern fortzuführen – nicht nur „sicher“, sondern funktionsfähig.

Lex specialis gegenüber NIS2. Für Finanzunternehmen ist DORA der spezifische Rechtsrahmen für Cyber- und IKT-Resilienz. Viele NIS2-Pflichten werden dadurch im Finanzsektor überlagert. Gleichwohl bleibt die Koordination mit nationalen Meldewegen und sektorübergreifenden Krisenmechanismen wichtig, um Mehrfachmeldungen zu vermeiden und Schnittstellen sauber zu regeln.

Wen betrifft DORA?

Die Reichweite von DORA ist groß – größer, als viele zunächst vermuten. Erfasst sind mehr als 20 Kategorien von Finanzmarktteilnehmern, u. a.:

Hinzu kommt eine Besonderheit: kritische IKT-Drittanbieter (Critical ICT Third-Party Service Providers, z. B. große Cloud-Plattformen, Kernbankensoftware- oder Zahlungsdienstleister) unterliegen einer direkten europäischen Aufsicht (Joint Oversight). Das ist ein Novum und adressiert systemische Risiken durch Konzentration auf wenige Technologieanbieter.

Wichtig für die Praxis: Auch Unternehmen, die „nur“ Dienstleistungen für Finanzinstitute erbringen – vom Rechenzentrum über Managed Security Services bis zur Kernbankensoftware – sind mittelbar betroffen. Finanzinstitute müssen sicherstellen, dass ihre Lieferkette DORA-fähig ist. Wer in der Lieferkette steht, wird Vertragsklauseln, Auditrechte, Exit-Szenarien und Nachweisanforderungen künftig deutlich stärker spüren.

Die fünf Kernpfeiler von DORA – und was sie praktisch bedeuten

1) IKT-Risikomanagement

Unternehmen müssen ein robustes, dokumentiertes, getestetes IKT-Risikomanagement etablieren. Kernelemente:

2) Meldung IKT-bezogener Vorfälle (Incident Reporting)

DORA führt gemeinsame Kriterien, Prozesse und Formate für schwerwiegende IKT-Vorfälle ein. Erwartet wird:

3) Digital Operational Resilience Testing

Regelmäßige, risikoorientierte Tests – vom Vulnerability-Scan bis zum Threat-Led Penetration Test (TLPT) – sind Pflicht. Eckpunkte:

4) IKT-Drittparteienrisiko (Outsourcing & Lieferkette)

DORA stärkt das Third-Party Risk Management (TPRM) deutlich:

5) Informationsaustausch

DORA fördert den freiwilligen, strukturierten Austausch von Cyber-Bedrohungsinformationen (TTPs, IOCs, Schwachstellen, Best Practices) zwischen Finanzmarktteilnehmern, etwa in vertrauenswürdigen Foren/ISACs. Ziel ist eine gemeinsame Erhöhung der Abwehrfähigkeit – rechtlich gerahmt, um Wettbewerbs- und Datenschutzfragen zu adressieren.

Warum DORA eingeführt wurde

Die Angriffsfläche wächst: Cloudifizierung, hochintegrierte Lieferketten, Remote-Arbeit, API-Ökosysteme und vernetzte Zahlungs-/Handelsinfrastrukturen erzeugen komplexe Abhängigkeiten. Einzelereignisse können schnell systemische Effekte auslösen – vom Ausfall eines Identity-Providers über fehlerhafte Software-Updates bis hin zu gezielten Ransomware-Kampagnen gegen Dienstleister. DORA ist die regulatorische Antwort auf diese Realität: Sektorkohärenz, Verbindlichkeit und Testbarkeit statt Flickenteppich.

Was bedeutet DORA in der Praxis? – Auswirkungen auf Organisation und Prozesse

Struktur und Rollen. Institute benötigen klare Rollen und Gremien: z. B. eine DORA-Programmleitung, ein bereichsübergreifendes Resilienz-Board (IT, Risk, Compliance, Fachbereiche, Einkauf, Recht, BCM), definierte Service-Owner, TPRM-Funktion, Incident Manager, Crisis Manager und unabhängige Test-/Auditfunktionen.

Prozesse. Bestehende Abläufe werden integriert und an einheitliche Kriterien angeglichen: ein zentraler Servicekatalog mit Toleranzgrenzen; ein harmonisierter Incident-Lifecycle; ein konsolidiertes Testprogramm mit Jahresplan; ein End-to-End-Lieferkettenprozess von der Bedarfsanmeldung bis zum Exit.

Systeme & Daten. Ohne saubere Datenbasis geht nichts: CMDB/Asset-Inventar, Logging-/SIEM-Plattform, Ticketing/IR-Workflow, GRC-Tool für Risiken/Kontrollen, TPRM-Register, Metriken-Repository – und Schnittstellen, die Redundanzen vermeiden.

Kultur. Resilienz ist kein IT-Projekt, sondern eine Organisationseigenschaft. Schulungen, Awareness, klare Verantwortlichkeiten und eine offene Fehler-/Lernkultur sind erfolgskritisch.

Governance und Verantwortlichkeit des Managements

Artefakte und Nachweise: Was Aufsichten (und Auditoren) sehen wollen

Konkrete Umsetzung: Ein pragmatischer 12-Monats-Fahrplan

Phase 1 – Mobilisieren (0–4 Wochen)

Phase 2 – Scoping & Inventar (5–10 Wochen)

Phase 3 – Gap-Analyse & Zielbild (8–14 Wochen)

Phase 4 – Umsetzen & Verankern (laufend bis Monat 12)

TLPT, Szenarien & Übungen: So wird Testen wirksam

TPRM in der Tiefe: Von der Vertragsklausel zur tatsächlichen Resilienz

Due Diligence vor Vertragsschluss

Vertragliche Mindestklauseln

Betriebliche Steuerung

Incident-Reporting ohne Chaos: Der Dreischritt in der Praxis

  1. Detektion & Klassifizierung: SOC/IRT erkennt Ereignis, bewertet Impact (Kunden, Services, Dauer, Daten), ordnet DORA-Relevanz ein.
  2. Meldeworkflow: definierte Erstmeldung an zuständige Behörde(n), interne Eskalation an Krisenstab/Management, Zwischenberichte mit Lageupdates, Abschlussbericht mit Ursachenanalyse und Maßnahmen.
  3. Lessons Learned & Hardening: Befunde in Kontrollen/Architektur verankern; ggf. Verträge/Drittparteien anpassen; Metriken aktualisieren.

Schnittstellen beachten: Datenschutz, Zahlungsverkehr, NIS2, nationale Aufsichten – eine Melde-Orchestrierung vermeidet Widersprüche und Doppelaufwand.

KPIs & KRIs: Messen, was Resilienz wirklich treibt

Governance & Reife

Incident-Management

Testing

TPRM

BCM/DR

Training & Awareness

Integration mit bestehenden Frameworks

Typische Fallstricke – und wie man sie vermeidet

  1. „Compliance statt Resilienz“: Policies ohne gelebte Praxis. Gegenmittel: Üben, testen, messen, nicht nur schreiben.
  2. Unvollständige Service-/Abhängigkeitskarten: Ohne sauberes Mapping keine Ziel-Toleranzen. Gegenmittel: Service-Owner benennen, Architekturen dokumentieren.
  3. TPRM unterschätzt: Vertragsnachverhandlungen dauern. Gegenmittel: Früh starten, Standardklauseln, Eskalationspfade.
  4. Meldechaos: Uneinheitliche Klassifizierung, Mehrfachmeldungen. Gegenmittel: zentrale Orchestrierung, klare Kriterien, Probeläufe.
  5. Fehlende Evidenzen: Gute Praxis, aber nicht nachweisbar. Gegenmittel: Audit-feste Dokumentation, Ticket-Referenzen, Sign-offs, Artefakt-Ablage.
  6. Einmalige TLPT-„Show“: Kein nachhaltiger Effekt. Gegenmittel: Remediation-Tracking, Management-Attention, Retests.
  7. Ressourcen & Skills: Zu wenig Personal/Kompetenz. Gegenmittel: realistische Roadmap, Upskilling, gezielte Partner, klare Prioritäten.

Beispielhafte Quick Wins

Häufige Fragen (FAQ)

Gilt DORA auch für kleine Institute?
Ja – proportional. Umfang und Tiefe richten sich nach Größe und Risiko, aber Kernanforderungen (Governance, Incident, Tests, TPRM, BCM) gelten für alle.

Wie oft müssen TLPTs durchgeführt werden?
Für bestimmte, als bedeutend eingestufte Institute in mehrjährigen Zyklen. Details ergeben sich aus den technischen Standards/Aufsichtsvorgaben. Andere Institute betreiben ein risikoorientiertes Testprogramm mit angemessener Tiefe.

Ersetzt DORA ISO 27001?
Nein. ISO 27001 bleibt wertvoll als Managementsystem-Standard. DORA verlangt jedoch zusätzliche, sektor- und aufsichtsrechtliche Elemente (z. B. Meldeformate, TPRM-Register, TLPT-Anforderungen).

Wie verhält sich DORA zu NIS2?
Für Finanzinstitute ist DORA lex specialis. Dennoch müssen Schnittstellen zu NIS2-Meldewegen national sinnvoll koordiniert werden.

Was droht bei Nicht-Einhaltung?
Aufsichtsmaßnahmen bis hin zu Sanktionen, Auflagen, Einschränkungen wesentlicher Auslagerungen – und vor allem operative Risiken mit Reputationsschäden.

DORA ist mehr als Compliance – es ist ein Wettbewerbsfaktor

Es wäre ein Fehler, DORA nur als regulatorische Pflicht zu sehen. Richtig umgesetzt, schafft DORA robuste, belastbare Abläufe, die Kundenvertrauen stärken, Ausfallkosten senken und die Zeit-zur-Erholung nach Störungen verkürzen. Institute, die Resilienz messen, üben und verbessern, sind verlässliche Partner für Kund:innen, Aufsicht und Markt – und können Innovationen (Cloud, APIs, KI) sicherer und schneller skalieren.

Fazit: Jetzt handeln – strukturiert, messbar, pragmatisch

DORA ist nicht nur ein weiteres Gesetz – es ist der Versuch, die digitale Resilienz der europäischen Finanzbranche auf ein neues, einheitliches Niveau zu heben. Wer jetzt proaktiv startet, hat genug Zeit, Prozesse anzupassen, Systeme zu prüfen, Verträge zu härten und Teams zu schulen. Der klügste Weg ist fokussiert: kritische Services identifizieren, Toleranzgrenzen festlegen, Incident-/Meldeprozesse vereinheitlichen, TPRM-Register schließen, Testprogramm aufsetzen, Evidenzen sammeln.

Der Countdown läuft: Ab Januar 2025 wird DORA Realität – und wer dann vorbereitet ist, wird nicht nur den Stresstest bestehen, sondern gestärkt daraus hervorgehen.

Verwandte Beiträge