DORA ist unmittelbar anwendbar. NIS2 wird national durchgesetzt. Für Banken, Zahlungsinstitute, Finanzdienstleister und deren IT-Dienstleister entsteht jetzt ein gefährlicher Graubereich: Wer meldet was, wann, an wen — BaFin oder BSI?
Das Risiko ist nicht nur ein Bußgeld. Das Risiko ist ein teurer Compliance-Flickenteppich. Zwei Programme. Zwei Reporting-Linien. Zwei Kontrollsysteme. Kein belastbares Mapping.
Wenn Ihr Haus DORA und NIS2 getrennt behandelt, produzieren Sie genau das, was Prüfer später angreifen: ineffiziente Compliance-Silos, widersprüchliche Verantwortlichkeiten und vermeidbare Geschäftsleiterhaftung.
DORA und NIS2 im Finanzwesen: Anforderungen und Überschneidungen
DORA ist für Finanzunternehmen kein „weiterer IT-Standard“. Es ist eine unmittelbar geltende EU-Verordnung für das Management von IKT-Risiken, IKT-Drittparteienrisiken, Vorfällen, Tests und Governance im Finanzsektor.
NIS2 ist breiter. Sie adressiert Cybersicherheitsanforderungen für wesentliche und wichtige Einrichtungen. Dazu zählen auch Teile des Finanzsektors sowie relevante Dienstleisterketten. Die Umsetzung läuft über deutsches Recht und nationale Aufsichtszuständigkeiten.
Der Knackpunkt: DORA ist in vielen Bereichen die speziellere Regelung für Finanzunternehmen. Juristisch: Lex specialis. Praktisch: Wo DORA eine gleichwertige oder spezifischere Pflicht regelt, darf NIS2 nicht stumpf als zweites Vollprogramm daneben gebaut werden.
Genau hier warnt auch das BSI vor dem Kernproblem: „Im Falle sich überschneidender oder widersprechender Anforderungen [...] drohen unnötige Bürokratie, Effizienzverluste und Rechtsunsicherheiten; daher ist eine aufeinander abgestimmte Umsetzung der beiden europäischen Richtlinien in deutsches Recht wichtig.“
Übersetzt für Ihre Bankpraxis:
- DORA-Vorfallmeldung ist nicht automatisch identisch mit einer NIS2-Meldung.
- BaFin-Reporting ersetzt nicht in jedem Fall jede BSI-relevante Pflicht.
- IKT-Risikomanagement nach DORA deckt viele NIS2-Kernanforderungen ab — aber nur, wenn sauber gemappt.
- Auslagerungsmanagement, Drittparteienrisiken und Resilienztests müssen konsistent dokumentiert werden.
- Eine doppelte Kontrollmatrix ohne Lex-Specialis-Prüfung ist Compliance-Verschwendung.
Das ist kein akademisches Problem. Das ist Budget, Personal und Haftung.
Warum parallele Compliance-Programme Mehraufwand erzeugen
Ein ISO-27001-Template löst dieses Problem nicht. Eine neue Firewall auch nicht. Ein DORA-Projektplan aus der Beratungsschublade ebenfalls nicht.
Der Markt verkauft Ihnen meist drei Papier-Tiger:
- DORA-Checklisten ohne NIS2-Abgleich
- NIS2-Gap-Analysen ohne Finanzaufsichtslogik
- generische ISMS-Dokumente ohne Meldeketten-Mapping
Das Ergebnis: Sie erfüllen formal vieles. Aber Sie können nicht erklären, warum eine Pflicht nur einmal umgesetzt wurde. Oder warum eine Meldung nur an eine Behörde ging. Oder warum eine DORA-Kontrolle gleichzeitig eine NIS2-Anforderung abdeckt.
Genau diese Begründung brauchen Sie.
Was die meisten Anbieter verschweigen: Der entscheidende Hebel ist nicht „mehr Compliance“. Der entscheidende Hebel ist präzises Mapping zwischen DORA-Artikeln und NIS2-Anforderungen.
Beispielhaft:
- DORA-Governance und IKT-Risikomanagement müssen gegen NIS2-Risikomanagementpflichten gespiegelt werden.
- DORA-Incident-Classification und Meldefristen müssen gegen NIS2-Meldepflichten geprüft werden.
- DORA-Drittparteienmanagement muss gegen NIS2-Supply-Chain-Security gemappt werden.
- DORA-Tests digitaler operationaler Resilienz müssen gegen NIS2-Sicherheitsmaßnahmen abgegrenzt werden.
- DORA-Leitungsorganpflichten müssen mit NIS2-Management-Verantwortung verbunden werden.
Ohne diese Abgrenzung entsteht Doppelarbeit. Mit dieser Abgrenzung entsteht ein belastbares Aufsichtsargument.
Kurz: Sie brauchen kein zweites Compliance-Universum. Sie brauchen eine verteidigungsfähige Übersetzung zwischen DORA und NIS2.
Schritte zum gemeinsamen Kontrollsystem für DORA und NIS2
Erstellen Sie eine Pflichtenkollision-Matrix: Listen Sie alle DORA-Pflichten aus Governance, IKT-Risikomanagement, Incident Reporting, Drittparteiensteuerung und Resilienztests. Stellen Sie daneben die korrespondierenden NIS2-Anforderungen. Markieren Sie jede Pflicht mit drei Statuswerten: DORA deckt ab, NIS2 ergänzt, separate Umsetzung erforderlich. Ohne diese Matrix steuern Sie blind.
Definieren Sie eine einheitliche Melde- und Eskalationslogik: Legen Sie fest, wann ein IKT-Vorfall DORA-relevant ist, wann zusätzlich NIS2-relevant sein kann und wer intern entscheidet. Nicht im Krisenfall. Jetzt. Benennen Sie Verantwortliche für BaFin-Kommunikation, BSI-Schnittstelle, Legal, CISO, Notfallmanagement und Vorstandsinformation. Keine parallelen Ad-hoc-Meldeketten.
Bauen Sie ein gemeinsames Kontrollset statt zwei Compliance-Silos: Führen Sie DORA- und NIS2-Anforderungen in einem Kontrollkatalog zusammen. Jede Kontrolle erhält einen Owner, einen Nachweis, eine Prüffrequenz und eine regulatorische Zuordnung. So vermeiden Sie doppelte Audits, doppelte Policies und widersprüchliche Nachweise. Ein Kontrollsystem. Zwei regulatorische Blickwinkel.
Mapping-Checkliste: DORA und NIS2 für Finanzinstitute
Die Checkliste unterstützt dabei, Überschneidungen zwischen DORA-Pflichten und NIS2-Anforderungen systematisch zu erfassen und ein gemeinsames Kontrollset aufzubauen. Sie dient der internen Orientierung und ersetzt keine aufsichtsrechtliche oder rechtliche Fachberatung.