DORA (Digital Operational Resilience Act)

Hintergrund und normative Einordnung

DORA schließt eine Lücke, die in der EU-Finanzregulierung lange bestand: Während MaRisk, BAIT und VAIT in Deutschland bereits ausdifferenzierte Erwartungen an die IT-Sicherheit formulierten, fehlte ein einheitlicher, unmittelbar geltender Rahmen auf Unionsebene. Die Verordnung (EU) 2022/2554 setzt diesen Rahmen und definiert in Art. 5 bis 16 ein verbindliches IKT-Risikomanagement, das Governance, Schutzmaßnahmen, Detektion, Reaktion, Wiederherstellung sowie Lernprozesse umfasst. Artikel 17 bis 23 regeln die harmonisierte Meldung schwerwiegender IKT-Vorfälle, Artikel 24 bis 27 verpflichten zu einem risikobasierten Testprogramm einschließlich Threat-Led Penetration Testing (TLPT) für bedeutende Institute.

In der deutschen Aufsichtspraxis führt die BaFin DORA als vorrangige Rechtsgrundlage gegenüber den bisherigen Rundschreiben; BAIT und VAIT wurden zum 16. Januar 2025 aufgehoben, soweit DORA gleichwertige Regelungen enthält. Für betroffene Unternehmen bedeutet das: bestehende ISMS nach ISO/IEC 27001 oder BSI IT-Grundschutz müssen um DORA-spezifische Anforderungen ergänzt werden, insbesondere zum vertraglichen Mindestinhalt bei IKT-Drittparteien (Art. 30) und zur Führung eines Informationsregisters (Art. 28). Der enge inhaltliche Bezug zur NIS-2-Richtlinie ist gewollt, DORA gilt als Lex specialis für den Finanzsektor. Eine strukturierte Umsetzung findet sich in der DORA-Beratung der SECURAM Consulting.

Normative Bezüge:

Vorgehen in der Praxis

Die Einführung von DORA folgt einer typischen Reifegradlogik: Scope klären, Lücken zur bestehenden IT-Sicherheitsorganisation identifizieren, Governance und Prozesse anpassen, Nachweise aufbauen. Die folgenden vier Schritte orientieren sich an den Anforderungen der Verordnung und den Regulatory Technical Standards (RTS) der ESAs.

Abgrenzung zu verwandten Begriffen

Typische Fehler und wie ihr sie vermeidet

• Anwendbarkeit zu eng ausgelegt: Art. 2 DORA umfasst mehr als 20 Finanzunternehmenstypen inklusive Krypto-Dienstleistern und Crowdfunding-Plattformen. Viele Institute unterschätzen den Scope und schließen verbundene Unternehmen oder Auslagerungsnehmer fälschlich aus.
• Drittparteienregister unvollständig: Das Informationsregister nach Art. 28 Abs. 3 DORA verlangt Angaben entlang der RTS on Register of Information (Durchführungsverordnung (EU) 2024/2956). Häufig fehlen Sub-Auftragsverhältnisse, Datenstandorte oder Klassifikationen kritischer Funktionen.
• Vorfallsklassifikation ohne Schwellenwerte: Ohne explizite Anwendung der Kriterien aus der RTS on Incident Classification (RTS 2024/1772) werden Vorfälle inkonsistent eingestuft. Dies führt zu verspäteten Meldungen oder umgekehrt zu Überlast der Meldepflichten.
• Testprogramm ohne Risikobezug: Art. 24 Abs. 2 DORA verlangt ein risikobasiertes Testprogramm. Ein Katalog generischer Pentests ohne Bezug zu kritischen Funktionen, Bedrohungslage und TLPT-Pflicht erfüllt die Anforderung nicht.

Relevanz im regulatorischen Kontext

DORA ist als EU-Verordnung unmittelbar geltendes Recht, eine nationale Umsetzung wie bei Richtlinien entfällt. Flankiert wird sie in Deutschland durch das Finanzmarktdigitalisierungsgesetz (FinmadiG), das Zuständigkeiten und Bußgeldvorschriften regelt. Zuständige Aufsichtsbehörden sind BaFin und Deutsche Bundesbank. Für kritische IKT-Dienstleister nehmen die Europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA) als Lead Overseer gemeinsam Überwachungsaufgaben wahr.

Die inhaltliche Präzisierung erfolgt über Regulatory und Implementing Technical Standards der ESAs, die fortlaufend als delegierte Rechtsakte im Amtsblatt der EU veröffentlicht werden. Relevante RTS betreffen unter anderem das IKT-Risikomanagement (RTS 2024/1774), die Vorfallsklassifikation (RTS 2024/1772), das Drittparteien-Policy-Framework (RTS 2024/1773) und das Informationsregister (ITS 2024/2956). Sanktionen bei Verstößen können nach deutschem Recht Bußgelder bis zu zehn Millionen Euro oder fünf Prozent des Jahresumsatzes vorsehen.

Häufige Fragen