Die DORA-Verordnung (EU 2022/2554) verpflichtet Finanzunternehmen zur Meldung schwerwiegender IKT-Vorfälle innerhalb von 4 Stunden. Genauer gesagt verlangt Art. 19 DORA eine Erstmeldung binnen 4 Stunden nach der Klassifizierung als schwerwiegender IKT-Vorfall; zusätzlich darf diese Erstmeldung nicht später als 24 Stunden nach Bekanntwerden des Vorfalls erfolgen. Danach folgen ein Zwischenbericht innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats.
Für die Praxis ist genau diese Reihenfolge entscheidend: erst Vorfall erkennen, dann rasch klassifizieren, anschließend die 4-Stunden-Frist steuern. Wer die Meldepflicht erst dann prüft, wenn bereits forensische Details vorliegen, verliert unter DORA wertvolle Zeit. Wenn Sie die Grundlogik der Verordnung insgesamt einordnen möchten, lesen Sie zuerst unseren Überblick zur DORA-Verordnung, die operative Zusammenfassung der DORA-Anforderungen und den Vergleich DORA vs. NIS2.
DORA Incident Reporting ist damit kein reines Aufsichtsthema, sondern ein Prozess für Krisenmanagement, Informationssicherheit, Recht und Kommunikation. Die Meldepflicht greift nicht erst am Ende der Untersuchung, sondern sehr früh im Incident Response. Unternehmen brauchen deshalb Meldewege, Rollen, Vorlagen und Freigaben, bevor der erste schwerwiegende IKT-Vorfall auftritt. Für die operative Vorbereitung eines Vorfallstabs hilft ergänzend unser Leitfaden zu Krisenmanagement nach Cyberangriff.
Dreistufiges Meldeverfahren nach DORA Art. 19
Art. 19 der Verordnung (EU) 2022/2554 schreibt ein dreistufiges Meldeverfahren vor. Die Detailfristen und Meldeinhalte werden durch die technischen Regulierungs- und Durchführungsstandards konkretisiert. Für Finanzunternehmen bedeutet das: Eine einzige Sammelmeldung am Ende reicht nicht aus. Die Aufsicht erwartet drei aufeinander aufbauende Meldungen mit wachsendem Informationsgrad.
| Stufe | Frist | Kerninhalt | Empfänger |
|---|---|---|---|
| Erstmeldung | 4 Stunden nach Klassifizierung als schwerwiegender IKT-Vorfall, spätestens 24 Stunden nach Bekanntwerden | erste Einordnung, Zeitpunkt, betroffene Dienste, erste Auswirkungen, Sofortmaßnahmen | zuständige Behörde nach DORA |
| Zwischenbericht | innerhalb von 72 Stunden nach Erstmeldung | aktualisierte Faktenlage, Status der Eindämmung, Auswirkungsanalyse, mögliche Ursachen | zuständige Behörde nach DORA |
| Abschlussbericht | innerhalb eines Monats nach Zwischenbericht | Root Cause Analysis, endgültige Auswirkungen, Behebung, Lessons Learned, Präventionsmaßnahmen | zuständige Behörde nach DORA |
Die wichtigste Konsequenz lautet: DORA verlangt Prozessreife statt Perfektion. Die Erstmeldung darf und soll auf vorläufigen Informationen basieren, solange klar erkennbar ist, was bekannt ist, was noch geprüft wird und welche Maßnahmen bereits laufen. Unternehmen scheitern in der Praxis seltener an fehlender Technik als an unklarer Governance zwischen SOC, CISO, Compliance, Rechtsabteilung und Geschäftsleitung.
Erstmeldung innerhalb von 4 Stunden — Was gemeldet werden muss
Die Erstmeldung dient der schnellen aufsichtsrechtlichen Lageerfassung. Sie muss nicht jede Ursache belegen, aber sie muss der Behörde ermöglichen, Relevanz, Reichweite und Eskalationsgrad des Vorfalls früh zu bewerten. Genau deshalb ist die 4-Stunden-Frist so streng: Die Aufsicht will bei schwerwiegenden Vorfällen nicht erst Tage später erfahren, dass zentrale Dienste eines Finanzunternehmens beeinträchtigt waren.
Inhaltlich sollte die Erstmeldung mindestens beantworten, was passiert ist, wann der Vorfall entdeckt wurde, wann er als schwerwiegend klassifiziert wurde, welche Systeme oder Dienste betroffen sind und welche unmittelbaren Auswirkungen für Kunden, Gegenparteien oder kritische Geschäftsprozesse erkennbar sind. Hinzu kommen erste Angaben zu geografischer Reichweite, Betriebsunterbrechungen, Datenbezug, eventuellen Drittanbietern und bereits eingeleiteten Gegenmaßnahmen.
Entscheidend ist die Unterscheidung zwischen Erkennung und Klassifizierung. Ein Sicherheitsereignis kann um 08:10 Uhr entdeckt werden, aber erst um 09:35 Uhr nach klarer Bewertung die DORA-Schwelle zum schwerwiegenden IKT-Vorfall erreichen. Ab diesem Klassifizierungszeitpunkt läuft die 4-Stunden-Frist. Unabhängig davon bleibt die Obergrenze bestehen, dass die Erstmeldung spätestens 24 Stunden nach Bekanntwerden des Vorfalls abgegeben sein muss. Unternehmen brauchen deshalb einen dokumentierten Klassifizierungsprozess mit klaren Eskalationspunkten.
Praktisch sollte die Erstmeldung in einem vorab freigegebenen Minimalformat vorbereitet werden. Sinnvoll sind ein Meldebogen, ein festes Freigabeschema und eine Entscheidungsmatrix für Wochenenden, Feiertage und Nachtbetrieb. Gerade in international aufgestellten Gruppen ist es riskant, wenn nur eine Person meldungsbefugt ist oder wenn erst ein vollständiger Management-Call abgewartet werden muss.
Zwischenbericht innerhalb von 72 Stunden
Der Zwischenbericht vertieft die Erstmeldung und aktualisiert die Lage. Binnen 72 Stunden erwartet die Aufsicht kein perfektes Abschlussbild, aber eine deutlich belastbarere Darstellung des Incident-Verlaufs, der betroffenen Assets, der geschäftlichen Auswirkungen und der eingeleiteten Eindämmungsmaßnahmen. Unternehmen müssen deshalb in den ersten drei Tagen nicht nur technisch reagieren, sondern parallel den regulatorischen Nachweisstrom organisieren.
Typischerweise gehören in den Zwischenbericht die aktuelle Betriebsfähigkeit, der Stand der Service-Wiederherstellung, die vorläufige Ursachenanalyse, präzisierte Kundenauswirkungen, etwaige Datenverluste oder Integritätsprobleme sowie die Frage, ob der Vorfall noch andauert. Ebenso relevant sind Korrekturen zur Erstmeldung. DORA belohnt keine vermeintliche Fehlerfreiheit in der ersten Stunde, sondern eine saubere Fortschreibung der Faktenlage.
In der Praxis ist der Zwischenbericht oft der schwierigste Teil des Prozesses. Zu diesem Zeitpunkt laufen Forensik, Kommunikation, Management-Updates, Kundenanfragen und gegebenenfalls externe Dienstleister parallel. Wer den Zwischenbericht nicht bereits in der Erstmeldung als eigenen Arbeitspaket-Strang einplant, produziert unnötigen Zeitdruck. Bewährt hat sich ein Regulierungs-Logbuch, in dem jede neue Erkenntnis sofort mit Zeitstempel, Quelle und Freigabestatus dokumentiert wird.
Abschlussbericht innerhalb eines Monats
Der Abschlussbericht schließt das formale DORA-Meldeverfahren ab. Ein Monat nach dem Zwischenbericht muss das Finanzunternehmen darlegen, was den Vorfall endgültig ausgelöst hat, wie groß die tatsächlichen Auswirkungen waren, welche Abhilfemaßnahmen umgesetzt wurden und welche strukturellen Änderungen daraus folgen. Die Behörde erwartet an dieser Stelle keinen Rohzustand mehr, sondern eine nachvollziehbare Root Cause Analysis mit belastbaren Schlussfolgerungen.
Der Abschlussbericht sollte deshalb mindestens die endgültige Zeitleiste des Vorfalls, die betroffenen Funktionen, die Dauer der Störung, Kunden- und Marktfolgen, den Beitrag etwaiger Drittanbieter, die tatsächlichen finanziellen Folgen sowie die beschlossenen Präventionsmaßnahmen enthalten. Hinzu kommen Aussagen zur Wiederherstellung, zu Governance-Lücken und dazu, wie vergleichbare Vorfälle künftig früher erkannt oder begrenzt werden sollen.
Für Aufsichtsbehörden ist der Abschlussbericht besonders wichtig, weil er nicht nur das einzelne Ereignis beschreibt, sondern Rückschlüsse auf das IKT-Risikomanagement des Unternehmens zulässt. Wer hier keine sauberen Lessons Learned formuliert, signalisiert, dass der Vorfall zwar technisch bearbeitet, organisatorisch aber nicht verarbeitet wurde.
Schwerwiegende IKT-Vorfälle — Definition und Klassifizierung
Meldepflichtig ist nicht jeder technische Fehler, sondern der schwerwiegende IKT-Vorfall. DORA definiert IKT-bezogene Vorfälle grundsätzlich als ungeplante Ereignisse, die Sicherheit, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Netz- und Informationssystemen beeinträchtigen und dadurch negative Auswirkungen auf Daten oder Dienstleistungen verursachen. Ob ein Vorfall schwerwiegend ist, richtet sich nach den Klassifizierungskriterien der ergänzenden Standards.
Für die Klassifizierung müssen Finanzunternehmen mehrere Auswirkungen betrachten. Relevant sind insbesondere die Zahl und Bedeutung betroffener Kunden oder Finanzgegenparteien, die Dauer der Störung, die betroffene Datenmenge oder Datenkritikalität, die geografische Ausdehnung, die wirtschaftlichen Auswirkungen sowie die Kritikalität der betroffenen Dienste. Ein kurzer lokaler Fehler im Testsystem ist typischerweise nicht meldepflichtig; ein Ausfall eines produktiven Zahlungs-, Handels- oder Kernbanksystems kann dagegen sehr schnell die Schwelle zum schwerwiegenden IKT-Vorfall erreichen.
Die operative Herausforderung liegt darin, dass Klassifizierung unter Unsicherheit erfolgt. In der ersten Stunde ist oft noch unklar, ob es sich um einen Ransomware-Fall, einen Cloud-Fehler, eine Fehlkonfiguration oder eine Lieferkettenstörung handelt. DORA verlangt trotzdem eine zeitnahe Entscheidung. Deshalb sollte jedes Unternehmen vorab festlegen, welche Funktionen als kritisch oder wichtig gelten und welche Schwellenwerte unmittelbar eine Eskalation an Compliance und Management auslösen.
| Kriterium | Woran Sie in der Praxis denken sollten | Warum es meldeentscheidend ist |
|---|---|---|
| Betroffene Dienste | Zahlungsverkehr, Handel, Policierung, Kundenportal, Kernsysteme | Kritische oder wichtige Funktionen erhöhen die Relevanz sofort |
| Dauer | Minuten, Stunden, mehrtägige Störung | Lange Unterbrechungen sprechen für Schwerwiegigkeit |
| Kunden- und Gegenparteieffekt | Zahl betroffener Kunden, ausgefallene Transaktionen, Verzögerungen | DORA zielt auf Stabilität und Marktvertrauen |
| Datenbezug | Verlust, Manipulation oder Offenlegung sensibler Daten | Integrität und Vertraulichkeit sind Kernschutzgüter |
| Geografische Reichweite | ein Standort, mehrere Länder, gruppenweite Wirkung | Breite Wirkung erhöht das Aufsichtsinteresse |
| Wirtschaftliche Auswirkung | direkte Verluste, Vertragsstrafen, Wiederanlaufkosten | Materielle Folgen stützen die Einstufung |
| Drittanbieterbezug | Cloud, SaaS, Rechenzentrum, Managed Service | DORA adressiert ausdrücklich ICT-Third-Party-Risiken |
An wen wird gemeldet — Zuständige Behörden
Gemeldet wird an die zuständige Behörde im Sinne von DORA, nicht an eine beliebige Sicherheitsstelle. Welche Behörde konkret zuständig ist, richtet sich nach der nationalen Aufsichtsarchitektur und der Art des beaufsichtigten Finanzunternehmens. Für deutsche Finanzunternehmen ist BaFin die zuständige Behörde; nach dem aktuell beschriebenen Verfahren werden Meldungen in der DORA-Aufsicht zudem an weitere relevante Stellen wie Bundesbank, BSI oder EZB weitergegeben.
Für Unternehmen mit grenzüberschreitender Struktur ist besonders wichtig, dass DORA keine informelle E-Mail-Kette ersetzt. Die Meldung muss im vorgesehenen Format und Verfahren erfolgen. Die technischen Standards sehen dafür standardisierte Inhalte, Vorlagen und Prozessschritte vor. Wer nur intern einen Incident Report erstellt, aber keine formale DORA-Meldung absetzt, erfüllt die Pflicht nicht.
Daneben können weitere Meldepflichten parallel bestehen. Ein und derselbe Vorfall kann neben DORA etwa Pflichten aus DSGVO Art. 33, vertraglichen Outsourcing-Regeln, nationalem Aufsichtsrecht oder internen Kunden- und Marktinformationspflichten auslösen. Genau deshalb sollten Unternehmen nicht nur einen DORA-Meldeprozess, sondern ein verzahntes Regulatory Incident Framework aufbauen. Die Überschneidungen und Unterschiede dazu erläutern wir vertieft im Beitrag DORA vs. NIS2.
Dokumentation und Nachweispflicht
Ohne saubere Dokumentation ist DORA Incident Reporting kaum beherrschbar. Unternehmen müssen nachweisen können, wann ein Ereignis entdeckt wurde, wann die Klassifizierung erfolgte, wer die Entscheidung getroffen hat, welche Fakten zu welchem Zeitpunkt bekannt waren und welche Meldung wann an welche Behörde übermittelt wurde. Diese Dokumentation ist nicht nur für die Aufsicht wichtig, sondern auch für interne Post-Mortems, Versicherungsfragen und mögliche Organhaftung.
Mindestens dokumentiert werden sollten daher die Incident-Timeline, die Klassifizierungsentscheidung, die zugrunde liegenden Kriterien, alle versandten Meldungen, interne Freigaben, Kommunikationsentscheidungen und die Recovery-Schritte. Ebenso wichtig ist eine belastbare Versionierung. Wenn sich Annahmen zwischen Erstmeldung und Zwischenbericht ändern, muss nachvollziehbar bleiben, weshalb sich die Lageeinschätzung geändert hat. Genau das schützt vor dem Vorwurf widersprüchlicher oder verspäteter Meldungen.
Praktisch funktioniert das am besten mit drei Bausteinen: einem Incident-Log, einer DORA-Entscheidungsmatrix und vordefinierten Meldeformularen. Der Incident-Log enthält jedes Ereignis mit Zeitstempel. Die Entscheidungsmatrix beschreibt, wann Compliance, Recht und Geschäftsleitung eingebunden werden. Die Meldeformulare sichern, dass Erstmeldung, Zwischenbericht und Abschlussbericht nicht jedes Mal neu erfunden werden müssen.
FAQ
Welche Vorfälle müssen gemeldet werden?
Gemeldet werden schwerwiegende IKT-Vorfälle im Sinne von Art. 19 DORA und der ergänzenden Klassifizierungsstandards. Maßgeblich sind unter anderem Auswirkung auf kritische oder wichtige Dienste, Zahl betroffener Kunden oder Gegenparteien, Dauer der Störung, Datenbezug, geografische Reichweite und wirtschaftliche Folgen. Nicht jeder technische Fehler ist automatisch meldepflichtig, aber jedes Finanzunternehmen braucht eine belastbare Vorfallklassifizierung.
Was passiert bei verspäteter Meldung?
Eine verspätete Meldung kann aufsichtsrechtliche Maßnahmen, vertiefte Nachfragen und eine kritische Prüfung des gesamten IKT-Risikomanagements auslösen. Das Kernproblem ist weniger nur die verpasste Uhrzeit als das Signal, dass Eskalation, Governance und Incident Response nicht belastbar organisiert sind. Unternehmen sollten deshalb Fristversäumnisse wie einen eigenen Kontrollfehler behandeln und sofort intern analysieren.
Wer im Unternehmen ist verantwortlich?
Verantwortlich ist organisatorisch nicht nur die IT, sondern das Finanzunternehmen als beaufsichtigte Einheit unter Leitung seiner zuständigen Governance-Strukturen. Operativ liegt die Vorbereitung häufig bei CISO, Informationssicherheit, Compliance und Rechtsabteilung; die finale Verantwortung darf aber nicht in einer einzelnen Fachfunktion hängen bleiben. DORA verlangt ein steuerbares Gesamtverfahren mit klaren Rollen, Vertretungen und Management-Einbindung.
Wie unterscheidet sich DORA-Meldung von DSGVO Art. 33?
DORA und DSGVO Art. 33 verfolgen unterschiedliche Schutzrichtungen. DORA schützt die digitale operationale Resilienz des Finanzsektors und verlangt ein dreistufiges Verfahren mit 4 Stunden, 72 Stunden und einem Monat. DSGVO Art. 33 fokussiert auf Verletzungen des Schutzes personenbezogener Daten und sieht grundsätzlich eine Meldung binnen 72 Stunden an die Datenschutzaufsicht vor. Ein Vorfall kann beide Regime gleichzeitig auslösen, aber die Meldegegenstände, Behörden und Inhalte sind nicht identisch.
Wie schnell muss ein IKT-Vorfall nach DORA gemeldet werden?
Die Erstmeldung muss innerhalb von 4 Stunden nach der Klassifizierung als schwerwiegender IKT-Vorfall erfolgen. Zusätzlich gilt eine absolute Obergrenze von 24 Stunden nach Bekanntwerden des Vorfalls. Danach folgen der Zwischenbericht binnen 72 Stunden und der Abschlussbericht binnen eines Monats nach dem Zwischenbericht.
Was ist der 3-Stufen-Meldeprozess nach DORA?
Der 3-Stufen-Meldeprozess besteht aus Erstmeldung, Zwischenbericht und Abschlussbericht. Die Erstmeldung liefert die frühe Lageeinschätzung, der Zwischenbericht aktualisiert Fakten und Auswirkungen, und der Abschlussbericht dokumentiert Ursachenanalyse, endgültige Folgen und Präventionsmaßnahmen. Genau diese Staffelung unterscheidet DORA von vielen anderen Meldepflichten.
An wen wird ein DORA-Vorfall gemeldet?
Ein DORA-Vorfall wird an die zuständige Aufsichtsbehörde des jeweiligen Finanzunternehmens gemeldet. In Deutschland ist dies für betroffene Finanzunternehmen grundsätzlich BaFin; je nach Verfahren erfolgt eine Weiterleitung an weitere relevante Stellen. Entscheidend ist, dass die Meldung im vorgesehenen formalen Prozess erfolgt und nicht nur intern dokumentiert wird.
CTA: Incident Reporting vor dem Ernstfall operationalisieren
DORA Incident Reporting funktioniert nur, wenn Rollen, Fristen und Nachweise schon vor dem ersten Vorfall feststehen. Wenn Sie Governance, Verantwortlichkeiten und dokumentierte Schulungsstände in Ihrem Unternehmen strukturieren möchten, verbinden Sie Ihre Prozesse mit unserem EU AI Act Kurs und schaffen Sie eine belastbare Grundlage für dokumentierte Compliance, klare Zuständigkeiten und saubere interne Nachweise.
Wenn Sie zuerst Ihre regulatorische Ausgangslage sortieren möchten, starten Sie mit den Grundlagen zur DORA-Verordnung, vertiefen Sie danach die DORA-Anforderungen und prüfen Sie die Abgrenzung zu DORA vs. NIS2. So wird aus einer knappen 4-Stunden-Frist ein beherrschbarer, geübter Prozess statt eines improvisierten Krisenexperiments.