Vier Stunden. Das ist die Zeit, die ein Finanzunternehmen hat, um nach der Einstufung eines IKT-Vorfalls als schwerwiegend eine erste Meldung an die Aufsichtsbehörde abzusetzen. Keine vier Stunden, um den Vorfall zu lösen. Keine vier Stunden für eine vollständige Analyse. Vier Stunden für eine strukturierte Erstmeldung – während der Incident aktiv läuft, während Teams in Krisentelefonate gebunden sind, und während häufig noch unklar ist, was genau passiert ist.
Die meisten IT-Teams, die DORA-pflichtig sind, haben diese Frist im Kalender. Was viele noch nicht haben, ist ein Prozess, der unter echtem Zeitdruck funktioniert: Wer entscheidet, dass ein Vorfall schwerwiegend ist? Wer formuliert die Meldung? Wer reicht sie ein, über welchen Kanal, mit welchem Inhalt?
Was DORA unter einem schwerwiegenden IKT-Vorfall versteht
Nicht jeder Ausfall löst die Meldepflicht aus. DORA Art. 18 definiert Schwellenwerte, nach denen Vorfälle einzustufen sind – die technischen Durchführungsstandards (ITS) der EBA konkretisieren diese. Relevant sind unter anderem die Anzahl betroffener Kunden, die Dauer des Ausfalls, die betroffenen Dienste und der finanzielle Schaden. Wer keinen dokumentierten Klassifizierungsprozess hat, der diesen Schwellenwert automatisch prüft, entscheidet im Krisenfall nach Bauchgefühl – was entweder zu verzögerten Meldungen führt oder zu unnötigen Meldungen, die Kapazitäten binden.
Wichtige Präzisierung zur 4-Stunden-Frist
Die Frist beginnt nicht mit der Entdeckung des Vorfalls, sondern mit seiner Klassifizierung als schwerwiegend. Wird ein Vorfall erst nach mehr als 24 Stunden als schwerwiegend eingestuft, beginnt die 4-Stunden-Frist ab diesem Klassifizierungszeitpunkt. Das klingt nach Spielraum – ist es aber nicht, weil die Klassifizierung selbst dokumentiert und vertretbar sein muss. Quelle: Delegierte Verordnung (EU) 2025/301, Art. 5 Abs. 1a.
Die drei Meldephasen: Fristen und Inhalte
Phase 1
Erstmeldung
Kurze, präzise Beschreibung des Vorfalls: Art des Vorfalls, betroffene Systeme und Dienste, initiale Auswirkungsbewertung, ob der Vorfall noch andauert, ob ein Geschäftsfortführungsplan aktiviert wurde. Eingereicht über das BaFin MVP-Portal (Melde- und Veröffentlichungsplattform) mittels standardisierter XML-Vorlagen nach ITS (EU) 2025/302. Freigabe: DORA-Beauftragter und CISO gemeinsam.
Phase 2
Zwischenmeldung
Detaillierte Analyse: Ausmaß des Vorfalls, Ursachenbewertung (soweit ermittelt), durchgeführte Gegenmaßnahmen, aktueller Wiederherstellungsstatus. Die Zwischenmeldung ist auch dann einzureichen, wenn sich gegenüber der Erstmeldung nichts geändert hat. Ergänzende Zwischenmeldungen sind unverzüglich einzureichen, sobald der reguläre Geschäftsbetrieb wiederaufgenommen wurde.
Phase 3
Abschlussmeldung
Vollständige Ursachenanalyse, finale Bewertung der Auswirkungen, Lessons Learned, konkrete Präventivmaßnahmen zur Vermeidung einer Wiederholung. Frist: spätestens einen Monat nach der letzten Zwischenmeldung. Sonderregel: Fällt das Fristende auf ein Wochenende oder einen Feiertag, verlängert sich die Frist bis 12:00 Uhr des nächsten Arbeitstages.
Wer meldet was an wen
In Deutschland ist die zuständige Behörde die BaFin. Die Meldung erfolgt ausschließlich über das MVP-Portal der BaFin, das XML-basierte Standardformulare nach ITS (EU) 2025/302 verwendet. Parallel besteht nach DORA Art. 19 Abs. 3 eine Pflicht zur Kundeninformation: Sind Kunden eines Finanzunternehmens von einem schwerwiegenden IKT-Vorfall betroffen, müssen sie unverzüglich informiert werden – eine horizontale Pflicht neben der vertikalen Meldung an die Behörde.
Drei Rollen müssen im Vorfall klar definiert sein, bevor der Ernstfall eintritt. Der Incident Owner überwacht den technischen Ablauf und koordiniert die Wiederherstellung. Der DORA-Beauftragte bewertet parallel, ob die Klassifizierungsschwelle erreicht ist, und verantwortet die Meldung gegenüber der BaFin. Das Leitungsorgan muss nach DORA Art. 5 aktiv in die IKT-Risikosteuerung eingebunden sein – was im Krisenfall bedeutet, dass der Vorstand informiert wird, nicht erst nachher.
Aggregierte Meldung bei Drittanbieter-Vorfällen
Geht ein schwerwiegender Vorfall von einem IKT-Drittdienstleister aus und sind mehrere Finanzunternehmen betroffen, die alle von derselben Behörde beaufsichtigt werden, kann der Drittdienstleister eine aggregierte Meldung für alle betroffenen Unternehmen einreichen – sofern die betroffenen Finanzunternehmen dieser Regelung zugestimmt haben. Diese Option ist in Verträgen mit kritischen IKT-Dienstleistern vorab zu verankern.
Warum die 4 Stunden ohne Vorbereitung nicht zu halten sind
Ein Vorfall, der die Meldepflicht auslöst, ist per Definition ein außergewöhnliches Ereignis. Systeme sind ausgefallen oder kompromittiert, Kommunikationskanäle sind überlastet, und die Ursache ist noch unklar. In diesem Zustand eine vollständige, formal korrekte Erstmeldung über ein XML-Portal einzureichen, ist ohne vorbereiteten Prozess nicht in vier Stunden zu leisten.
Was den Unterschied macht, ist nicht Schnelligkeit im Krisenmoment, sondern Strukturiertheit im Vorfeld: ein dokumentierter Klassifizierungsprozess mit eindeutigen Schwellenwerten, eine vorbereitete Meldevorlage für die Erstmeldung, definierte Verantwortlichkeiten und ein getesteter Zugang zum BaFin MVP-Portal. Wer das erste Mal unter Druck feststellt, dass der Portal-Zugang nicht eingerichtet ist oder die XML-Vorlage nicht vorliegt, hat die Frist bereits verloren.
Wie BAM DORA-Objekte den Prozess strukturieren
Das Brain-Media Audit Model enthält dedizierte DORA-Objekte, die den Meldeprozess als ausführbare Compliance-Artefakte abbilden: Die Klassifizierungsschwellenwerte nach Art. 18 sind als prüfbare Objekte hinterlegt, der dreistufige Meldeprozess ist mit Fristen, Inhalten und Verantwortlichkeiten dokumentiert, und der Nachweis der fristgerechten Meldung liegt als versioniertes Artefakt vor – nicht als nachträglich rekonstruiertes PDF.
Das BAM DORA-Objekt für die Erstmeldung enthält im Remediation-Feld die Pflichtangaben nach ITS (EU) 2025/302, im Evidence-Feld den erwarteten Audit-Nachweis (Eingangsbestätigung BaFin MVP-Portal, Zeitstempel, freigebende Personen) und im Control-Feld die organisatorische Voraussetzung: einen vorab getesteten Meldeprozess mit benanntem DORA-Beauftragten. Wer dieses Objekt nicht auf „umgesetzt" setzen kann, hat eine offene Gap – und weiß das, bevor der Incident eintritt.