DORA ist der Digital Operational Resilience Act, Verordnung (EU) 2022/2554. Er gilt seit dem 17. Januar 2025 und schafft gemeinsame Anforderungen an IKT-Risikomanagement, Meldung von Vorfällen, Resilienztests, Informationsaustausch und IKT-Drittparteienrisiken im Finanzsektor.
DORA gilt direkt für die benannten Finanzunternehmen und prägt auch deren Verträge sowie Aufsicht über IKT-Dienstleister. Die genauen Pflichten hängen von Art, Größe und Rolle des Unternehmens sowie den zugehörigen technischen Standards ab.
Für wen gilt DORA?
Erfasst sind zahlreiche Finanzunternehmen, darunter Kredit- und Zahlungsinstitute, Wertpapierfirmen, Versicherungen, bestimmte Verwalter und Anbieter rund um Kryptowerte. Hinzu kommen in DORA ausdrücklich genannte IKT-Dienstleister und Datenbereitsteller. Nicht jede Pflicht gilt für jede Organisation in identischer Tiefe: DORA enthält Vereinfachungen und ein Proportionalitätsprinzip. Die Einstufung muss deshalb anhand der konkreten Unternehmensart und der einschlägigen technischen Regulierungsstandards erfolgen.
Was sind die Hauptbereiche?
- - Governance und IKT-Risikomanagementrahmen.
- - Klassifizierung und Meldung schwerwiegender IKT-Vorfälle.
- - Tests der digitalen operationalen Resilienz einschließlich TLPT für bestimmte Unternehmen.
- - Vertragliche Steuerung und Aufsicht von IKT-Drittparteienrisiken.
| Bereich | Praktische Frage | Typische Nachweise |
|---|---|---|
| IKT-Risiko | Welche Systeme tragen kritische Funktionen? | Inventar, Risikoanalysen, Richtlinien |
| Vorfälle | Wie werden Vorfälle erkannt und gemeldet? | Playbooks, Tickets, Übungen |
| Tests | Funktionieren Schutz und Wiederherstellung? | Testpläne, Findings, Retests |
| Drittparteien | Welche externen IKT-Leistungen sind kritisch? | Informationsregister, Verträge, Exit-Pläne |
Wie funktioniert das IKT-Risikomanagement?
Finanzunternehmen benötigen einen dokumentierten IKT-Risikomanagementrahmen unter Verantwortung des Leitungsorgans. Er verbindet Strategie, Rollen, Assets, Schutzmaßnahmen, Überwachung, Reaktion, Wiederherstellung und kontinuierliche Verbesserung. Besonders wichtig ist die Zuordnung technischer Systeme und externer Leistungen zu kritischen oder wichtigen Funktionen. Ohne diese Verbindung lässt sich die Auswirkung eines Ausfalls nicht zuverlässig bewerten oder priorisieren.
- Identifizieren:
Assets, Verantwortliche, Abhängigkeiten und Risiken erfassen. - Schützen:
Zugriffe, Änderungen, Netzwerke, Daten und Entwicklung angemessen absichern. - Erkennen:
Anomalien, Leistungsprobleme und Sicherheitsereignisse zeitnah feststellen. - Reagieren und wiederherstellen:
Vorfälle eindämmen und Funktionen innerhalb definierter Ziele wiederherstellen. - Lernen:
Tests und Vorfälle auswerten und Kontrollen nachweisbar verbessern.
Wie werden IKT-Vorfälle behandelt?
IKT-bezogene Vorfälle müssen aufgezeichnet und nach festgelegten Kriterien klassifiziert werden. Schwerwiegende Vorfälle werden über das zuständige Aufsichtsverfahren gemeldet. Die Bewertung berücksichtigt unter anderem betroffene Kunden, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität der Dienste und wirtschaftliche Auswirkungen. Technische Erkennung, Business Impact, Recht und Kommunikation müssen deshalb bereits vor einem Vorfall miteinander verbunden sein.
Warum reichen technische Alarmierungen nicht aus?
Ein SIEM-Alarm kennt zunächst weder die Zahl betroffener Kunden noch die aufsichtsrechtliche Relevanz. Umgekehrt kann ein länger anhaltender Ausfall ohne erkennbaren Angriff meldepflichtig sein. Ein DORA-tauglicher Prozess ergänzt technische Schweregrade daher um Geschäfts- und Meldekriterien, dokumentiert Entscheidungen und ermöglicht aktualisierte Zwischen- und Abschlussmeldungen.
Welche Resilienztests verlangt DORA?
Das Testprogramm soll Schwachstellen in Prävention, Erkennung, Reaktion und Wiederherstellung aufdecken. Je nach Risiko gehören Schwachstellenscans, Konfigurationsprüfungen, szenariobasierte Tests, Penetrationstests, Wiederherstellungstests und Übungen dazu. Findings müssen priorisiert, behoben und erneut geprüft werden. Tests sind damit kein einmaliges Audit, sondern ein wiederkehrender Verbesserungsprozess.
Threat-Led Penetration Testing (TLPT)
Bestimmte von der Aufsicht ausgewählte Unternehmen müssen mindestens alle drei Jahre ein bedrohungsgeleitetes Penetration Testing durchführen. Das Szenario basiert auf aktueller Threat Intelligence und prüft kritische Funktionen möglichst realistisch. Anders als ein gewöhnlicher Pentest betrachtet TLPT auch Erkennung und Reaktion und kann relevante IKT-Drittdienstleister einbeziehen. TIBER-EU liefert dafür einen etablierten europäischen Rahmen.
Was gilt für IKT-Drittdienstleister?
Die Verantwortung bleibt beim Finanzunternehmen, auch wenn Cloud, Software oder Betrieb ausgelagert werden. Vor Vertragsabschluss sind Risiken und Konzentrationen zu bewerten. Verträge benötigen definierte Leistungen, Sicherheits- und Meldepflichten, Zugangs- und Prüfungsrechte, Unterauftragnehmerregeln, Datenstandorte, Unterstützung bei Vorfällen sowie Kündigungs- und Exit-Regelungen. Alle vertraglichen IKT-Beziehungen werden in einem Informationsregister erfasst.
Wie wird DORA praktisch umgesetzt?
- Betroffene Gesellschaften, kritische Funktionen und verantwortliche Leitungsorgane bestimmen.
- Assets, Prozesse, Datenflüsse und IKT-Drittdienstleister diesen Funktionen zuordnen.
- Risikomanagement, Vorfallprozess, Testprogramm und Drittparteiensteuerung gegen DORA und RTS/ITS prüfen.
- Informationsregister und Vertragsremediation mit Einkauf, Recht und Fachbereichen organisieren.
- Resilienz- und Meldeprozesse üben, Findings beheben und Fortschritt an das Management berichten.
DORA, NIS2 und TIBER-EU
DORA ist für erfasste Finanzunternehmen das sektorspezifische Regelwerk zur digitalen operationalen Resilienz. NIS2 verfolgt einen breiteren, sektorübergreifenden Ansatz. TIBER-EU ist keine allgemeine Compliance-Verordnung, sondern ein Rahmen für bedrohungsgeleitete Tests. Die drei Begriffe sollten daher nicht synonym verwendet werden.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.