Die am 16. September 2026 veröffentlichten Operational Instructions der Europäischen Aufsichtsbehörden (ESAs) ändern weder die materiellen DORA-Meldepflichten noch die geltenden Klassifikationsschwellen. Sie sind dennoch operativ bedeutsam: Ihr Ziel ist, die Qualität und Konsistenz von Meldungen schwerwiegender IKT-bezogener Vorfälle zwischen den Jurisdiktionen zu verbessern. Damit rücken Fehlerquellen in den Mittelpunkt, die unter Zeitdruck besonders häufig entstehen: uneinheitliche Identifikatoren, unvollständige Klassifikationsbegründungen, widersprüchliche Zeitangaben oder nicht nachvollziehbar fortgeschriebene Schätzwerte.
Für Finanzunternehmen sind die Hinweise daher vor allem ein Anlass, die eigene Meldefähigkeit praktisch zu testen. Entscheidend ist nicht allein, ob ein Incident-Management-Prozess existiert. Das Unternehmen muss in der Lage sein, aus einem dynamischen technischen Sachverhalt fristgerecht eine konsistente, belegbare und über mehrere Berichtsstufen steuerbare Aufsichtsmeldung zu machen.
Rechtsrahmen und Status der operativen Hinweise
Die verbindlichen Grundlagen ergeben sich aus der Verordnung (EU) 2022/2554 (DORA) sowie den zugehörigen technischen Regulierungs- und Durchführungsstandards. DORA verlangt einen IKT-Vorfallmanagementprozess, der IKT-bezogene Vorfälle erkennt, behandelt und meldet. Für schwerwiegende IKT-bezogene Vorfälle sieht Artikel 19 eine Erstmeldung, einen oder mehrere Zwischenberichte und einen Abschlussbericht vor.
Die Delegierte Verordnung (EU) 2024/1772 konkretisiert Klassifikationskriterien und Wesentlichkeitsschwellen. Inhalt und Fristen der einzelnen Berichtsstufen regelt die Delegierte Verordnung (EU) 2025/301; standardisierte Formulare, Vorlagen und Verfahren folgen aus der Durchführungsverordnung (EU) 2025/302.
Die ESA Operational Instructions sind demgegenüber kein Rechtsakt, keine verbindliche Rechtsauslegung und keine offizielle Position der ESAs. Sie werden ausdrücklich auf „best efforts“-Basis bereitgestellt und sollen anhand von Erfahrungen weiterentwickelt werden. Praktisch besitzen sie dennoch Gewicht als mit den zuständigen Behörden abgestimmte Aufsichtshilfe. Für in Luxemburg beaufsichtigte Unternehmen kommt hinzu, dass die CSSF erwartet, die ESA-Hinweise und ihre ergänzenden Instruktionen angemessen zu berücksichtigen.
Drei getrennte Entscheidungen im Melde-Runbook
Ein belastbares Runbook sollte drei Prozessentscheidungen klar trennen. Erstens wird ein technischer oder organisatorischer Sachverhalt detektiert und aufgenommen. Zweitens ist zu entscheiden, ob der IKT-bezogene Vorfall regulatorisch als schwerwiegend einzustufen ist. Drittens folgt die fristgerechte, formal vollständige Behördenmeldung. Ein SOC-Alarm, ein Ticket des Service Managements oder eine operative Prioritätseinstufung ersetzt keine Major-Klassifikation nach DORA.
Die regulatorische Bewertung ist breiter als eine technische Störungsanalyse. Zu berücksichtigen sind unter anderem Auswirkungen auf Kunden, Gegenparteien und Transaktionen, Reputationsauswirkungen, Dauer und Ausfallzeit, geografische Verbreitung, Datenverluste, die Kritikalität betroffener Dienste und wirtschaftliche Auswirkungen. Ein schwerwiegender IKT-bezogener Vorfall liegt nach der Delegierten Verordnung 2024/1772 vor, wenn kritische Dienste betroffen sind und entweder die Schwelle eines erfolgreichen böswilligen und unbefugten Zugriffs mit möglichem Datenverlust erreicht wird oder mindestens zwei weitere Wesentlichkeitsschwellen erfüllt sind.
Im Runbook sollten daher Übergabepunkte zwischen Incident Response, betroffenen Fachbereichen, IKT-Risikomanagement, BCM, Compliance und Meldewesen festgelegt sein. Ebenso erforderlich sind benannte Entscheidungsverantwortliche, Eskalationswege und eine nachvollziehbare Dokumentation, wann welche Information vorlag. Die Geschäftsleitung sollte nicht nur über den Incident, sondern auch über Major-Klassifikation, Fristenrisiken und wesentliche Unsicherheiten informiert werden.
Erstmeldung: Ein getestetes Mindestdatenpaket bereitstellen
Die Erstmeldung ist so früh wie möglich einzureichen, spätestens vier Stunden nach der Major-Klassifikation und spätestens 24 Stunden nach Kenntniserlangung vom IKT-bezogenen Vorfall. Unter diesem Zeitdruck darf die Informationsbeschaffung nicht erst beginnen. Die Vorgaben verlangen unter anderem die eigene Incident-Referenz, den Zeitpunkt der Entdeckung, die Klassifikation, eine Beschreibung, die angewendeten Klassifikationskriterien, betroffene Mitgliedstaaten, den Entdeckungsweg sowie – soweit verfügbar – die Ursache und Angaben zur Aktivierung eines Business-Continuity-Plans.
Ein vorab gepflegtes Mindestdatenpaket sollte deshalb mindestens folgende Elemente abbilden:
- eine eindeutige und über alle Berichtsstufen stabile Incident-Referenz;
- Zeitstempel für Entdeckung, Kenntniserlangung, Klassifikation, Meldung und Wiederherstellung;
- betroffene kritische Dienste, Geschäftsprozesse und Infrastrukturkomponenten;
- die Evidenz für erfüllte Klassifikationskriterien einschließlich Datenquellen, Annahmen und Schätzmethodik;
- bekannte betroffene Drittparteien, geografische Reichweite sowie den BCM-Aktivierungsstatus;
- zuständige Ansprechpartner und ein dokumentiertes Freigabemodell.
Unvollständige Faktenlagen lassen sich in einem frühen Stadium nicht immer vermeiden. Entscheidend ist dann eine kontrollierte Evidenzkette: Welche Quelle belegt einen Wert? Auf welchem Vergleichszeitraum beruht eine Schätzung? Wer hat sie verantwortet, welche Unsicherheit besteht und wann erfolgt die Neubewertung? Damit wird die Erstmeldung nicht künstlich endgültig, aber fachlich nachvollziehbar.
Zwischenberichte als versionierter Berichtszyklus
Die Meldung endet nicht mit dem Versand der Erstmeldung. Der erste Zwischenbericht ist spätestens 72 Stunden nach der Erstmeldung vorzulegen – auch dann, wenn sich Status oder Bearbeitung nicht verändert haben. Bei relevanten Änderungen sind aktualisierte Zwischenberichte unverzüglich einzureichen; jedenfalls ist bei Wiederherstellung der regulären Tätigkeiten ein Update erforderlich. Der Zwischenbericht erfasst unter anderem, wie die Klassifikationskriterien erfüllt wurden, welche Geschäftsprozesse und Infrastrukturkomponenten betroffen sind, welche Kundeninteressen berührt werden und welche temporären Wiederherstellungsmaßnahmen erfolgt oder geplant sind.
Technische Wiederherstellung beendet den Berichtszyklus daher nicht zwingend. Ursachenanalyse, Forensik oder Verlustermittlung können weiterlaufen. Für lang laufende Fälle erläutern die Operational Instructions als operative Erwartung mindestens einen weiteren Zwischenbericht pro Monat, wenn kein Abschlussbericht möglich ist.
Das Meldedossier oder Reporting-Tool sollte Stammdaten, bereits eingereichte Werte und Änderungen versioniert führen. Korrekturen dürfen nicht als isolierte Nachträge entstehen. Jede neue Stufe muss die zuletzt eingereichte Meldung konsistent fortschreiben. Ein Pre-Submission-Control sollte mindestens Pflichtfelder, Fristen, Zeitstempellogik, Werteformate, Währungen, Mengenangaben, Freitexte, Klassifikationsbegründung und Freigaben prüfen.
Abschlussbericht: Ursachen, Auswirkungen und dauerhafte Maßnahmen
Der Abschlussbericht ist spätestens einen Monat nach dem Zwischenbericht oder dem zuletzt aktualisierten Zwischenbericht einzureichen. Er setzt eine abgeschlossene Ursachenanalyse und verfügbare tatsächliche Auswirkungswerte voraus. Zu berichten sind insbesondere Ursache, Zeitpunkte der Behebung von Vorfall und Ursache, Angaben zur Lösung sowie direkte und indirekte Kosten und Verluste einschließlich finanzieller Rückflüsse. Gegebenenfalls sind auch wiederkehrende Vorfälle einzubeziehen.
Diese Inhalte verlangen eine organisierte Schnittstelle zwischen Incident Response, Problem Management, Forensik, Finance, Legal beziehungsweise Compliance, BCM und Drittparteimanagement. Kosten, Verluste und Rückflüsse sollten aus kontrollierten Quellen stammen; Ursachen- und Maßnahmenlage müssen zu den Aussagen früherer Meldungen passen. Bei einer absehbaren Verzögerung ist die zuständige Behörde spätestens bis zum Ablauf der jeweiligen Frist über Gründe zu informieren.
Melde-Runbooks mit realistischen Übungen nachweisen
Eine wirksame Prüfung verbindet Zeitdruck, Datenqualität und Rollensteuerung. Sinnvoll sind Tabletop-Übungen mit Erstmeldung, eine Fortsetzung bis zum 72-Stunden-Zwischenbericht und ein Szenario mit längerer Forensik sowie wiederkehrenden Zwischenberichten. Eine Abschlussbericht-Übung sollte zusätzlich Kosten- und Verlustdaten, Ursachenanalyse und dauerhafte Abhilfemaßnahmen einbeziehen. Ein Retest vergangener realer Vorfälle gegen die ESA-Hinweise kann Datenlücken und unklare Verantwortlichkeiten sichtbar machen.
Das Ziel ist kein formal perfektes Musterformular, sondern ein belastbarer Prozess: Detektion, Klassifikation, Evidenz, Freigabe, Übermittlung und Fortschreibung müssen auch unter realistischen Bedingungen zusammenwirken. Die Operational Instructions bieten dafür keinen neuen Rechtsrahmen, aber einen konkreten Prüfmaßstab für die Qualität der praktischen Umsetzung.