IKT-Vorfallmanagement und Meldepflichten unter DORA

Problem in der Praxis

Viele Finanzunternehmen hatten vor DORA bereits einen Incident-Prozess, oft aufgebaut auf BAIT, VAIT, KAIT oder ZAIT. Dieser Prozess war jedoch meist intern ausgerichtet: Störung erkennen, beheben, dokumentieren. DORA verschiebt den Schwerpunkt von der internen Behebung zur regulatorischen Meldung mit standardisierter Klassifizierung und sehr kurzen Fristen.

In der Praxis entstehen daraus drei wiederkehrende Schwachstellen. Erstens fehlt eine belastbare, vorab definierte Klassifizierungslogik, sodass im Ernstfall improvisiert wird, ob ein Vorfall schwerwiegend ist. Zweitens ist die Meldekette organisatorisch unklar: Wer hat die Klassifizierungsentscheidung, wer löst die Meldung tatsächlich aus, und was passiert nachts oder am Wochenende. Drittens werden parallele Meldepflichten nicht zusammengedacht, sodass derselbe Vorfall gegenüber Finanzaufsicht, Datenschutzaufsicht und gegebenenfalls weiteren Stellen mit abweichenden Darstellungen ankommt.

Der teuerste Fehler ist nicht die Störung selbst, sondern eine verspätete, widersprüchliche oder formal fehlerhafte Meldung. Sie macht aus einem technischen Vorfall ein Aufsichtsthema.

CISO-Einordnung

DORA standardisiert europaweit, wie schwerwiegende IKT-Vorfälle behandelt und gemeldet werden. Der CISO sollte die Anforderung in drei Blöcke gliedern.

Erstens die Behandlung: ein durchgängiger Managementprozess für IKT-Vorfälle, der Erkennung, Reaktion, Eskalation, Wiederherstellung und Lernen verbindet. Das ist die operative Grundlage und überschneidet sich stark mit dem IKT-Risikomanagement der ersten Säule.

Zweitens die Klassifizierung: DORA fordert eine einheitliche Einstufung anhand festgelegter Kriterien und Schwellen, um zu bestimmen, ob ein Vorfall schwerwiegend ist. Die konkreten Kriterien und Schwellenwerte stehen nicht im Verordnungsgrundtext, sondern werden durch Level-2-Recht der europäischen Aufsichtsbehörden konkretisiert (technische Regulierungs- und Durchführungsstandards, RTS und ITS). Die verbindlichen Kriterien und Werte sind daher am einschlägigen delegierten beziehungsweise Durchführungsrechtsakt zu prüfen und nicht aus dem Gedächtnis zu setzen.

Drittens die Meldung: schwerwiegende Vorfälle sind an die zuständige Behörde zu melden, typischerweise in einem mehrstufigen Modell aus Erstmeldung, Zwischenbericht und Abschlussbericht. DORA sieht zudem die Möglichkeit vor, erhebliche Cyberbedrohungen freiwillig zu melden. Auch hier gilt: die konkreten Meldefristen sind in den RTS und ITS festgelegt; die einschlägigen Werte müssen am aktuellen delegierten Rechtsakt verifiziert werden, bevor sie als verbindlich kommuniziert werden.

Umsetzungsperspektive

Aus CISO-Sicht trägt ein Aufbau in klar trennbaren Bausteinen.

• Klassifizierungsmodell: eine dokumentierte, vorab abgestimmte Logik, die einen Vorfall reproduzierbar als schwerwiegend oder nicht-schwerwiegend einstuft, abgeleitet aus den maßgeblichen RTS-Kriterien.
• Entscheidungs- und Meldekette: eindeutig benannte Rollen für die Klassifizierungsentscheidung und die Meldungsauslösung, inklusive Vertretung und 24/7-Fähigkeit.
• Fristen-Choreografie: ein Ablauf, der die Stufen Erstmeldung, Zwischenbericht und Abschlussbericht abdeckt und für jede Stufe Verantwortliche, Datenquellen und Freigaben festlegt.
• Datenbasis: definierte Felder und Quellen, damit Meldungen aus dem laufenden Vorfallmanagement gespeist werden und nicht in der Krise neu erhoben werden müssen.
• Synchronisation: ein Mechanismus, der prüft, ob derselbe Vorfall zusätzlich nach NIS2-Logik oder unter der DSGVO meldepflichtig ist, damit die Darstellungen konsistent bleiben.

In Deutschland sind BaFin (federführend) und Deutsche Bundesbank zuständig; für IKT-Vorfälle des Finanzsektors besteht ein nationaler Melde-Hub. Die nationale Durchführung erfolgt über das Finanzmarktdigitalisierungsgesetz mit dem DORA-Durchführungsgesetz. Die bisherigen aufsichtlichen IT-Anforderungen werden im Zuge von DORA abgelöst; ZAIT, VAIT und KAIT wurden zum 16.01.2025 aufgehoben, BAIT wird im Übergang für DORA-pflichtige Institute schrittweise abgelöst (genaue Termine national gegenprüfen).

Typische Fehler

1. Die Klassifizierung wird erst im Vorfall improvisiert, statt vorab als reproduzierbares Modell festgelegt.
2. Meldefristen werden aus dem Gedächtnis oder aus älteren Quellen gesetzt, ohne den aktuellen RTS/ITS-Stand zu prüfen.
3. Es gibt keine klare, ausfallsichere Rolle, die die Meldung außerhalb der Geschäftszeiten tatsächlich auslöst.
4. DORA-, NIS2- und DSGVO-Meldungen werden getrennt bearbeitet, sodass Fakten und Zeitpunkte auseinanderlaufen.
5. Der Abschlussbericht wird unterschätzt; Ursachenanalyse und Lessons Learned fließen nicht in das IKT-Risikomanagement zurück.

Risiken und Trade-offs

Ein zu enges Klassifizierungsmodell meldet zu wenig und riskiert den Vorwurf der Untermeldung. Ein zu weites meldet vorsorglich alles und bindet Kapazitäten, schwächt die Aussagekraft der Meldungen und kann die Aufsicht überlasten. Die Schwellen aus den RTS sind der Maßstab; die interne Logik muss daran ausgerichtet, aber praktikabel bleiben.

Ein zweiter Trade-off betrifft Geschwindigkeit gegen Genauigkeit. Sehr kurze Erstmeldefristen erzwingen eine Meldung auf unvollständiger Faktenbasis. Das ist gewollt, erfordert aber die Disziplin, später im Zwischen- und Abschlussbericht nachzuschärfen, ohne sich in Widersprüche zur Erstmeldung zu verstricken.

Ein dritter Punkt ist die Mehrfachmeldung. DORA ist für Finanzunternehmen lex specialis gegenüber NIS2: wo beide dieselbe Materie regeln, geht DORA vor. Die DSGVO verfolgt dagegen einen anderen Schutzzweck (personenbezogene Daten) und kann denselben Vorfall zusätzlich meldepflichtig machen, an eine andere Behörde und gegebenenfalls an Betroffene. Diese Spuren müssen synchronisiert, dürfen aber nicht vermischt werden.

Entscheidungspunkte

• Wer trägt die Klassifizierungsentscheidung, und wie wird sie außerhalb der Geschäftszeiten sichergestellt?
• Wie wird gewährleistet, dass die verwendeten Fristen und Schwellen dem aktuellen RTS/ITS-Stand entsprechen und nicht veralten?
• Wie wird ein Vorfall systematisch auf parallele Meldepflichten (NIS2-Bezug, DSGVO) geprüft, bevor gemeldet wird?
• Welche Datenfelder müssen ohnehin im Vorfallmanagement erfasst werden, damit Meldungen ohne Krisenrecherche befüllbar sind?
• Wie fließt der Abschlussbericht in das IKT-Risikomanagement und in die Prüfprogramme der dritten Säule zurück?

Praktische Empfehlungen

1. Definieren Sie das Klassifizierungsmodell vorab und leiten Sie es nachvollziehbar aus den maßgeblichen RTS-Kriterien ab; verifizieren Sie die Werte am delegierten Rechtsakt.
2. Beschreiben Sie die Meldekette als belastbaren Ablauf mit benannten Rollen, Vertretung und 24/7-Fähigkeit, nicht als Organigramm.
3. Etablieren Sie eine Fristen-Choreografie für Erstmeldung, Zwischenbericht und Abschlussbericht mit klaren Freigaben.
4. Führen Sie einen Synchronisations-Check ein, der DORA-, NIS2- und DSGVO-Relevanz eines Vorfalls strukturiert prüft und konsistent hält.
5. Üben Sie die Meldung praktisch (Tabletop), inklusive Zeitnahme, und speisen Sie Erkenntnisse in das IKT-Risikomanagement zurück.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554, Kapitel III (Behandlung, Klassifizierung und Meldung IKT-bezogener Vorfälle; orientierend Art. 17 bis 23): zentrale Rechtsgrundlage. Verbindliche Klassifizierungskriterien und Meldefristen ergeben sich erst aus den ergänzenden RTS/ITS der ESAs.
• Richtlinie (EU) 2022/2555 (NIS2): horizontaler Rahmen; für Finanzunternehmen geht DORA als lex specialis vor.
• Verordnung (EU) 2016/679 (DSGVO): eigenständige Meldepflicht bei Verletzungen des Schutzes personenbezogener Daten; verbindliche Fristen und Schwellen am DSGVO-Originaltext prüfen.
• ISO/IEC 27035 und ISO/IEC 27001: Referenz für die operative Ausgestaltung des Incident-Managements (Wie), ohne DORA-Spezifika zu ersetzen.
• NIST SP 800-61: Referenz für Incident-Handling-Praxis (Mapping möglich, nicht normativ).