DORA-Vorfallmeldung und ISO 27001-Maßnahmen im Jahr 2026

Es ist 08:17 Uhr an einem Dienstagmorgen im Jahr 2026. Sarah, CISO eines europäischen FinTechs, sieht ein Dashboard, das gelb blinkt, nicht rot. Eine kritische Plattform für den Zahlungsausgleich verlangsamt sich. Transaktionen schlagen nicht vollständig fehl, dauern aber dreimal länger, als es das Service Level Agreement zulässt. Das SOC erkennt ungewöhnliche Authentifizierungsversuche gegen ein Administratorkonto. Der Cloud-Infrastrukturanbieter meldet eine eingeschränkte Leistung in einer Verfügbarkeitszone. Der Kundensupport erhält erste Anrufe von Firmenkunden, die wissen möchten, warum Zahlungsdateien verspätet verarbeitet werden.

Noch weiß niemand, ob es sich um einen Cyberangriff, ein Versagen der operativen Resilienz, einen Lieferantenausfall, einen Datenschutzvorfall oder alles zugleich handelt.

Sarah hat ein DORA-Problem, bevor die technischen Fakten vollständig vorliegen. Ist dies ein schwerwiegender IKT-bezogener Vorfall? Betrifft er eine kritische oder wichtige Funktion? Hat er den internen Schweregradschwellenwert überschritten? Wer muss wann und mit welchen Nachweisen benachrichtigt werden? Wenn personenbezogene Daten betroffen sind, läuft dann auch die Meldefrist nach GDPR? Wenn ein IKT-Drittdienstleister Teil der Vorfallkette ist, wer ist für die Fakten verantwortlich?

An diesem Punkt erkennen Finanzunternehmen den Unterschied zwischen einem Incident-Response-Plan und einem auditierbaren Betriebsmodell für die DORA-Vorfallmeldung.

Die DORA-Vorfallmeldung im Jahr 2026 erfordert mehr als schnelle Eskalation. Sie erfordert eine belastbare Kette von der Erkennung zur Klassifizierung, von der Klassifizierung zur Meldung an die Aufsicht, von der Meldung zur Abhilfemaßnahme und von der Abhilfemaßnahme zu Lessons Learned. ISO/IEC 27001:2022 liefert die Struktur des Managementsystems. Die ISO/IEC 27002:2022 Anhang A-Maßnahmen definieren die praktischen Kontrollerwartungen. Die Richtlinien, der 30-Schritte-Fahrplan und der Cross-Compliance-Leitfaden von Clarysec überführen diese Erwartungen in eine nachweisfähige Umsetzung.

Warum DORA-Vorfallmeldungen unter Druck scheitern

Die meisten Fehler bei der DORA-Vorfallmeldung beginnen nicht mit Fahrlässigkeit. Sie beginnen mit Unklarheit.

Ein Sicherheitsanalyst sieht eine Warnmeldung, weiß aber nicht, ob sie als IKT-bezogener Vorfall nach DORA einzustufen ist. Der IT-Service-Manager behandelt die eingeschränkte Leistung als technisches Serviceproblem, während Compliance sie als regulatorisches Ereignis bewertet. Die Rechtsabteilung wartet auf Bestätigung, bevor sie eskaliert. Der Geschäftsverantwortliche kann die Kundenauswirkungen noch nicht quantifizieren. Der CISO benötigt Nachweise, aber die relevanten Protokolle sind über Cloud-Services, Endpunkte, Identitätssysteme, SIEM und Lieferantenplattformen verteilt.

Bis die Organisation sich auf eine Klassifizierung geeinigt hat, steht das Meldefenster bereits unter Druck.

DORA Articles 17 to 21 schaffen strukturierte Erwartungen an das Management IKT-bezogener Vorfälle, deren Klassifizierung, Meldung, Meldeinhalte und aufsichtliche Bearbeitung. Für Finanzunternehmen ist die praktische Anforderung klar: IKT-bezogene Vorfälle müssen überwacht, gesteuert, protokolliert, klassifiziert, gemeldet, aktualisiert und ausgewertet werden – so, dass der Vorgang später nachvollzogen werden kann.

Clarysecs Incident-Response-Richtlinie [IRP] verankert DORA direkt im Referenzrahmen:

EU DORA (2022/2554): Article 17: Anforderungen an die Meldung von IKT-Vorfällen durch Finanzinstitute an zuständige Behörden.

Dieselbe Richtlinie verbindet Incident Management mit ISO/IEC 27002:2022-Maßnahmen 5.25 bis 5.27 und deckt Verantwortlichkeiten für Vorfallbewertung, Reaktion, Kommunikation und Verbesserung ab.

Für kleinere Finanztechnologieunternehmen und schlank aufgestellte regulierte Unternehmen macht Clarysecs Incident-Response-Richtlinie – KMU [IRP-SME] die Verpflichtung praktisch umsetzbar, indem sie betont, dass DORA Finanzunternehmen verpflichtet, IKT-bezogene Vorfälle und Störungen zu klassifizieren, zu melden und nachzuverfolgen.

Diese Formulierung ist entscheidend. DORA-Compliance ist nicht nur eine Meldevorlage. Die Organisation muss klassifizieren, melden und nachverfolgen. Das bedeutet Nachweise zum ursprünglichen Ereignis, zu Entscheidungskriterien, Schweregrad, Meldeentscheidung, Kommunikation, Wiederherstellungsmaßnahmen, Lieferantenbeteiligung und Nachverfolgung.

ISO/IEC 27001:2022 als DORA-Steuerungsinstanz für Vorfälle

Ein ausgereiftes Informationssicherheitsmanagementsystem nach ISO/IEC 27001:2022 darf nicht zu einem weiteren Compliance-Silo neben DORA werden. Es sollte die Steuerungsinstanz für die DORA-Vorfallmeldung bilden.

Das ISMS verlangt bereits Risikoverantwortung, Maßnahmenselektion, interne Audits, Managementbewertung, dokumentierte Informationen, kontinuierliche Verbesserung und Nachweise über den Betrieb der Maßnahmen. DORA erhöht den branchenspezifischen Meldedruck, aber ISO/IEC 27001:2022 liefert die Governance-Struktur, um den Prozess wiederholbar zu machen.

Clarysecs Zenith Blueprint: 30-Schritte-Fahrplan für Auditoren [ZB] stärkt diese Integration in Schritt 13, Planung der Risikobehandlung und Anwendbarkeitserklärung. Der Blueprint empfiehlt, Maßnahmen zur Nachvollziehbarkeit Risiken und Klauseln zuzuordnen, einschließlich der Ergänzung einer Anhang A-Maßnahmenreferenz bei Risiken und des Hinweises, wann Maßnahmen GDPR, NIS2 oder DORA unterstützen.

Für Sarahs Vorfall beim Zahlungsausgleich könnte der Eintrag im Risikoregister lauten:

„Störung oder Kompromittierung der Plattform zur Zahlungsabwicklung.“

Die zugeordneten ISO/IEC 27001:2022 Anhang A-Maßnahmen würden 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 und 8.16 umfassen, ergänzt um einen DORA-Hinweis zur Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle.

Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden [ZC] dient anschließend als Kompass für Cross-Compliance. In Zenith Controls ordnet Clarysec ISO/IEC 27002:2022-Maßnahmen anderen ISO/IEC 27001:2022-Maßnahmen, verwandten Standards, Auditerwartungen und Vorschriften wie DORA, GDPR und NIS2 zu. Es werden keine separaten „Zenith Controls“ geschaffen. Der Leitfaden zeigt, wie die bestehenden ISO-Maßnahmen zusammenwirken und wie sie geprüft werden.

Der DORA-Meldeworkflow lässt sich als Maßnahmenkette betrachten:

Sie können nicht melden, was Sie nicht erkannt haben. Sie können nicht klassifizieren, was Sie nicht bewertet haben. Sie können eine Meldeentscheidung nicht ohne Aufzeichnungen begründen. Sie können sich nicht verbessern ohne eine Nachbesprechung nach Vorfällen.

Maßnahme 6.8: Die DORA-Uhr startet bei den Menschen

In Sarahs Szenario kommt das erste verwertbare Signal möglicherweise nicht aus dem SOC. Es kann von einem Kundenbetreuer kommen, der Kundenbeschwerden hört, von einem Fachanwender im Finanzbereich, der fehlgeschlagene Settlement-Batches sieht, oder von einem Engineer, dem eine ungewöhnliche Latenz auffällt.

Deshalb ist ISO/IEC 27001:2022 Anhang A-Maßnahme 6.8, Meldung von Informationssicherheitsereignissen, für DORA wesentlich. Sie macht die Meldung zur Verantwortung der gesamten Belegschaft und nicht nur zu einer Funktion des Sicherheitsbetriebs.

Im Zenith Blueprint, Schritt 16, People Controls II, stellt Clarysec fest:

Ein wirksames Incident-Response-System beginnt nicht mit Werkzeugen, sondern mit Menschen.

Schritt 16 empfiehlt klare Meldekanäle, Sensibilisierungsschulungen, eine Kultur ohne Schuldzuweisung, Triage, Vertraulichkeit und regelmäßige Simulationen. Die wichtigste praktische Botschaft ist einfach:

„Im Zweifel melden.“

Das ist ein DORA-Kontrollgrundsatz. Wenn Mitarbeitende warten, bis sie sicher sind, verliert die Organisation Zeit. Wenn sie frühzeitig melden, kann die Organisation bewerten, klassifizieren und entscheiden.

In Zenith Controls wird 6.8 als aufdeckende Maßnahme abgebildet, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist mit 5.24 verbunden, weil Meldekanäle Teil des Vorfallplans sein müssen. Sie speist 5.25, weil Ereignisse nur bewertet werden können, wenn sie gemeldet wurden. Sie löst 5.26 aus, weil die formale Reaktion nach der Bewertung von Meldungen beginnt.

Für DORA unterstützt dies Articles 17 and 18, nach denen Finanzunternehmen schwerwiegende IKT-bezogene Vorfälle und erhebliche Cyberbedrohungen managen, klassifizieren und melden müssen. Es unterstützt außerdem GDPR Article 33 und Recital 85, weil die interne Meldung bestimmt, wie schnell eine Verletzung des Schutzes personenbezogener Daten erkannt und eskaliert wird.

Eine praktische Clarysec-Umsetzung ist ein einseitiges Merkblatt „So melden Sie einen IKT-Vorfall“. Es sollte enthalten:

• Was zu melden ist, einschließlich Ausfälle, verdächtige E-Mails, verlorene Geräte, ungewöhnliches Systemverhalten, vermutete Lieferantenkompromittierung, unbefugter Zugriff, Datenabfluss und servicebezogene Beeinträchtigungen mit Kundenauswirkung.
• Wie zu melden ist, etwa über ein überwachtes Postfach, eine Ticketkategorie, eine Hotline, einen Kollaborationskanal oder ein SOC-Portal.
• Welche Angaben erforderlich sind, z. B. Zeitpunkt, System, Benutzer, Geschäftsprozess, beobachtete Auswirkung, Screenshots, sofern sicher, und ob Kunden oder personenbezogene Daten betroffen sein könnten.
• Was nicht zu tun ist, einschließlich Protokolle nicht zu löschen, kritische Systeme nicht ohne Anweisung neu zu starten, Kunden nicht ohne Freigabe extern zu kontaktieren und nicht über die eigene Rolle hinaus zu untersuchen.
• Was als Nächstes geschieht, einschließlich Triage, Klassifizierung, Eskalation, Reaktion, Beweissicherung und möglicher regulatorischer Bewertung.

Ziel ist nicht, jeden Mitarbeitenden zum Ermittler zu machen. Ziel ist, jeden Mitarbeitenden zu einer verlässlichen Signalquelle zu machen.

Maßnahme 5.25: Der DORA-Entscheidungspunkt für die Klassifizierung

Die Meldung schwerwiegender IKT-bezogener Vorfälle nach DORA hängt an der Klassifizierung. Hier wird ISO/IEC 27001:2022 Anhang A-Maßnahme 5.25, Bewertung und Entscheidung über Informationssicherheitsereignisse, zentral.

Der Zenith Blueprint, Schritt 23, erläutert die praktische Herausforderung:

Nicht jede Anomalie ist eine Katastrophe. Nicht jede Warnmeldung signalisiert eine Kompromittierung.

Anschließend beschreibt er den Zweck von 5.25 wie folgt:

das Harmlose vom Schädlichen zu unterscheiden und zu wissen, was eine Eskalation erfordert.

Für DORA ist dies der Moment, in dem ein Sicherheitsereignis, eine Servicebeeinträchtigung, ein Lieferantenausfall, eine Datenexposition oder eine Betriebsstörung gegen die Kriterien für schwerwiegende Vorfälle bewertet wird. Die Organisation muss operative Auswirkungen, betroffene Services, kritische oder wichtige Funktionen, betroffene Kunden und Transaktionen, Dauer, geografische Ausbreitung, Datenauswirkungen, Reputationsfolgen und wirtschaftliche Auswirkungen berücksichtigen.

In Zenith Controls ist 5.25 direkt DORA Article 18, Klassifizierung schwerwiegender IKT-Vorfälle, zugeordnet. Es handelt sich um den strukturierten Bewertungsprozess, mit dem festgestellt wird, ob ein beobachtetes Ereignis als Sicherheitsvorfall einzustufen ist. Die Maßnahme ist außerdem mit 8.16, Überwachungstätigkeiten, verbunden, weil Warnmeldungen und Protokolldaten triagiert werden müssen, sowie mit 5.26, weil die Klassifizierung die Reaktion auslöst.

An dieser Stelle scheitern viele Organisationen in Audits. Sie haben Tickets, aber keine Klassifizierungsaufzeichnungen. Sie haben Schweregradkennzeichnungen, aber keine Kriterien. Sie haben regulatorische Meldungen, aber keinen Entscheidungsnachweis, der belegt, warum ein Vorfall als schwerwiegend oder nicht schwerwiegend bewertet wurde.

Clarysec adressiert dies, indem die DORA-Klassifizierung in das Modell für Vorfallschweregrade eingebettet wird. In der unternehmensweiten Incident-Response-Richtlinie enthält Klausel 5.3.1 ein klares Beispiel für Tier 1:

Tier 1: Kritisch (z. B. bestätigte Datenschutzverletzung, Ransomware-Ausbruch, Kompromittierung eines Produktivsystems)

Für kleinere Organisationen ergänzt die Incident-Response-Richtlinie – KMU eine straffe operative Vorgabe:

Der General Manager muss mit Unterstützung des IT-Dienstleisters alle Vorfälle innerhalb einer Stunde nach Benachrichtigung nach Schweregrad klassifizieren.

Dieses Klassifizierungsziel von einer Stunde ist wirkungsvoll, weil es Governance-Disziplin erzwingt. Ein kleineres reguliertes Unternehmen verfügt möglicherweise nicht über ein 24/7-SOC, kann aber dennoch festlegen, wer klassifiziert, wer berät und wie schnell die Entscheidung erfolgen muss.

Ein DORA-zu-ISO-Triage-Datensatz für Vorfälle

Um die Klassifizierung belastbar zu machen, sollte in Ihrem Ticketing-, GRC- oder Incident-Management-System ein DORA-Triage-Datensatz angelegt werden. Der Datensatz muss für jedes potenziell wesentliche IKT-Ereignis erstellt werden, auch wenn es später herabgestuft wird.

Fügen Sie eine Entscheidungsnotiz hinzu:

„Aufgrund der Störung eines Zahlungsdienstes mit Auswirkung auf einen kritischen Geschäftsprozess, ungeklärter Ursache und potenzieller Kundenauswirkung wird das Ereignis als potenziell schwerwiegender IKT-bezogener Vorfall eskaliert. Compliance und Rechtsabteilung bewerten die regulatorischen Meldepflichten. Die Beweissicherung wurde eingeleitet.“

Dieser einzelne Datensatz unterstützt DORA Article 17-Nachverfolgung, Article 18-Klassifizierung, Article 19-Meldeentscheidungen, ISO/IEC 27001:2022 Anhang A 5.25-Bewertung, 6.8-Meldung, 5.26-Reaktion und 5.28-Umgang mit Beweismitteln.

Maßnahmen 5.24 und 5.26: Planung, Rollen und Reaktion

Wenn ein DORA-Vorfall eintritt, muss der Reaktionsplan unbequeme Fragen bereits beantworten.

Wer hat die Befugnis zur Klassifizierung? Wer kontaktiert die zuständige Behörde? Wer genehmigt die Erstmeldung? Wer kommuniziert mit Kunden? Wer kontaktiert den IKT-Drittdienstleister? Wer entscheidet, ob der Vorfall auch eine GDPR-Meldung auslöst? Wer sichert Beweismittel? Wer ist für den Abschlussbericht verantwortlich?

ISO/IEC 27001:2022 Anhang A-Maßnahme 5.24, Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, beantwortet diese Fragen vor der Krise. Maßnahme 5.26, Reaktion auf Informationssicherheitsvorfälle, stellt sicher, dass der Plan während des Vorfalls in kontrolliertes Handeln übergeht.

In Zenith Controls ist 5.24 mit DORA Articles 17 to 21 verknüpft, weil sie eine dokumentierte, getestete und überprüfte Incident Response operationalisiert, einschließlich interner Eskalation, externer regulatorischer Meldung, Kommunikation mit Stakeholdern und Lessons Learned.

ISO/IEC 27035-1:2023 unterstützt dies, indem es Incident Management über Reaktionsverfahren hinaus auf Richtlinien, Planung, Fähigkeiten, Beziehungen, Unterstützungsmechanismen, Sensibilisierung, Schulung und regelmäßige Tests ausweitet. ISO/IEC 27035-2:2023 beschreibt den Incident-Management-Prozess von der Vorbereitung bis zu Lessons Learned detaillierter.

Der Zenith Blueprint, Schritt 23, gibt eine direkte Umsetzungsanweisung:

Stellen Sie sicher, dass ein aktueller Incident-Response-Plan (5.24) vorliegt, der Vorbereitung, Eskalation, Reaktion und Kommunikation abdeckt.

Ein DORA-fähiger Incident-Response-Plan muss Folgendes definieren:

• Das IKT-Incident-Response-Team und Stellvertretungen.
• Befugnisse für Schweregradklassifizierung und Eskalation der DORA-Meldung.
• Verantwortlichkeiten von Rechtsabteilung, Compliance, Datenschutz, Kommunikation, IT, Sicherheit, Lieferanten und Geschäftsverantwortlichen.
• Kriterien für die Klassifizierung schwerwiegender IKT-bezogener Vorfälle.
• Verfahren für Erstmeldungen, Zwischenmeldungen und Abschlussmeldungen an Aufsichtsbehörden.
• Bewertung von Auslösern für GDPR-, NIS2-, vertragliche, Cyberversicherungs- und Leitungsorgansbenachrichtigungen.
• Schritte für Eindämmung, Beseitigung, Wiederherstellung und Validierung.
• Anforderungen an die Beweissicherung.
• Verfahren für Lieferanteneskalation und Zugriff auf Protokolle.
• Nachverfolgung von Lessons Learned und Korrekturmaßnahmen.

Die Incident-Response-Richtlinie – KMU verbindet Reaktionsfristen außerdem mit gesetzlichen Anforderungen:

Reaktionsfristen, einschließlich Datenwiederherstellung und Benachrichtigungspflichten, müssen dokumentiert und an gesetzliche Anforderungen ausgerichtet sein, etwa an die GDPR-Pflicht zur Meldung einer Verletzung des Schutzes personenbezogener Daten innerhalb von 72 Stunden.

Dies ist wesentlich, weil ein einzelner IKT-Vorfall zu einem schwerwiegenden DORA-Vorfall, einer Verletzung des Schutzes personenbezogener Daten nach GDPR, einem erheblichen NIS2-Vorfall, einem vertraglichen Benachrichtigungsereignis gegenüber Kunden und einem Lieferantenmanagementthema werden kann. Der Plan muss diese Überlagerungen koordinieren, statt sie als getrennte Welten zu behandeln.

Maßnahmen 8.15 und 8.16: Protokolle machen die Meldung belastbar

DORA-Vorfallmeldungen hängen von Fakten ab. Fakten hängen von Protokollierung und Überwachung ab.

Im Szenario des Zahlungsausgleichs muss Sarah wissen, wann die Beeinträchtigung begann, welche Systeme betroffen waren, ob privilegierte Konten genutzt wurden, ob Daten die Umgebung verlassen haben, ob der Ausfall des Cloud-Anbieters mit der internen Telemetrie übereinstimmt und wann die Wiederherstellung abgeschlossen war.

ISO/IEC 27001:2022 Anhang A-Maßnahme 8.15, Protokollierung, und 8.16, Überwachungstätigkeiten, stützen diese Nachweisbasis. In Zenith Controls sind beide mit 5.24 verbunden, weil die Incident-Response-Planung nutzbare Protokolldaten und Überwachungsfähigkeiten enthalten muss. Maßnahme 8.16 ist außerdem mit 5.25 verbunden, weil Warnmeldungen in Entscheidungen überführt werden müssen.

Clarysecs Richtlinie zur Protokollierung und Überwachung – KMU [LMP-SME] enthält eine praktische Eskalationsanforderung:

Warnmeldungen mit hoher Priorität müssen innerhalb von 24 Stunden an den GM und den Datenschutzkoordinator eskaliert werden.

Für DORA-regulierte Unternehmen erfordern potenziell schwerwiegende IKT-Vorfälle in der Regel ein schnelleres operatives Eskalationsmodell, insbesondere wenn kritische oder wichtige Funktionen betroffen sind. Das Governance-Muster ist dennoch korrekt: Warnmeldungen mit hoher Priorität dürfen nicht in der IT verbleiben. Sie müssen Geschäfts-, Datenschutz- und Managementrollen erreichen.

Ein DORA-fähiges Protokollierungsmodell muss Folgendes umfassen:

• Zentrale Protokollierung für kritische Systeme, Identitätsplattformen, Endpunkte, Cloud-Services, Netzwerksicherheitswerkzeuge und Geschäftsanwendungen.
• Zeitsynchronisierung über Systeme hinweg, damit Vorfallzeitachsen verlässlich sind.
• Alarmkategorisierung, die auf Vorfallschweregrad und DORA-Klassifizierung ausgerichtet ist.
• Protokollaufbewahrung, die an regulatorischen, vertraglichen und forensischen Anforderungen ausgerichtet ist.
• Zugriffskontrollen, die die Integrität von Protokollen schützen.
• Verfahren zur Erfassung von Log-Snapshots während schwerwiegender Vorfälle.
• Anforderungen an den Zugriff auf Lieferantenprotokolle für kritische IKT-Services.

Auditoren werden „das SIEM hat es“ nicht als ausreichenden Nachweis akzeptieren. Sie werden fragen, ob die richtigen Protokolle vorhanden waren, ob Warnmeldungen überprüft wurden, ob die Eskalation rechtzeitig erfolgte und ob Protokolle gesichert wurden, sobald der Vorfall potenziell meldepflichtig wurde.

Maßnahme 5.28: Beweissicherung und Beweismittelkette

Bei einem schwerwiegenden IKT-bezogenen Vorfall dienen Beweismittel drei Zwecken: technische Untersuchung, regulatorische Rechenschaftspflicht und rechtliche Belastbarkeit.

Wenn Beweismittel unvollständig, überschrieben, verändert oder nicht dokumentiert sind, kann die Organisation Schwierigkeiten haben nachzuweisen, was geschehen ist. Sie kann auch Schwierigkeiten haben, ihre Klassifizierungsentscheidung zu begründen.

Clarysecs Richtlinie zur Beweissicherung und Forensik [ECF] legt fest:

Ein Protokoll zur Beweismittelkette muss alle physischen oder digitalen Beweismittel vom Zeitpunkt der Erfassung bis zur Archivierung oder Übertragung begleiten und Folgendes dokumentieren:

Die KMU-Version, Richtlinie zur Beweissicherung und Forensik – KMU [ECF-SME], hält die Anforderung einfach:

Jedes digitale Beweismittel muss protokolliert werden mit:

Die operative Lehre ist klar. Der Umgang mit Beweismitteln darf nicht erst beginnen, wenn die Rechtsabteilung danach fragt. Er muss in die Incident Response eingebettet sein.

ISO/IEC 27006-1:2024 verstärkt diese Auditerwartung, indem Verfahren zur Identifizierung, Sammlung und Sicherung von Beweismitteln aus Informationssicherheitsvorfällen betont werden. Für DORA kann derselbe Nachweissatz die Erstmeldung, Zwischenaktualisierungen, den Abschlussbericht, die Nachbesprechung nach dem Vorfall und Fragen der Aufsicht unterstützen.

Eine praktische Nachweis-Checkliste für DORA-bezogene Vorfälle sollte Folgendes enthalten:

• Vorfallticket und Triage-Notizen.
• Zeitachse von Erkennung, Eskalation, Klassifizierung, Meldung, Eindämmung, Wiederherstellung und Abschluss.
• SIEM-Warnmeldungen und korrelierte Protokolle.
• Artefakte von Endpunkten und Servern.
• Identitäts- und PAM-Protokolle.
• Zusammenfassungen des Netzwerkverkehrs.
• Status- und Audit-Protokolle des Cloud-Anbieters.
• Lieferantenkommunikation und Vorfallstellungnahmen.
• Aufzeichnungen zu Geschäftsauswirkungen, einschließlich Kunden, Services, Transaktionen und Ausfallzeiten.
• Entwürfe und Einreichungen regulatorischer Meldungen.
• Managemententscheidungen und Genehmigungen.
• Ursachenanalyse.
• Lessons Learned und Korrekturmaßnahmen.

Die Beweismittel müssen sowohl technische Fakten als auch Governance-Entscheidungen zeigen. Bei der DORA-Meldung geht es nicht nur darum, was mit Systemen geschehen ist. Es geht auch darum, wie das Management den Vorfall erkannt, bewertet, eskaliert, kontrolliert und daraus Verbesserungen abgeleitet hat.

Maßnahme 5.27: Lessons Learned und kontinuierliche Verbesserung

Ein DORA-Vorfall ist nicht abgeschlossen, wenn der Abschlussbericht eingereicht wurde. Er ist abgeschlossen, wenn die Organisation daraus gelernt, Korrekturmaßnahmen zugewiesen, Maßnahmen aktualisiert und Verbesserungen verifiziert hat.

ISO/IEC 27001:2022 Anhang A-Maßnahme 5.27, Lernen aus Informationssicherheitsvorfällen, verbindet die DORA-Meldung mit dem Zyklus der kontinuierlichen Verbesserung nach ISO/IEC 27001:2022. In Zenith Controls ist 5.24 mit 5.27 verknüpft, weil Incident Management ohne Ursachenanalyse, Lessons Learned und Verbesserung von Maßnahmen unvollständig ist.

Der Zenith Blueprint, Schritt 23, weist Organisationen an, den Plan anhand der Lessons Learned zu aktualisieren und gezielte Schulungen zu Incident Response und Umgang mit Beweismitteln bereitzustellen. Dies ist für DORA besonders wichtig, weil wiederkehrende Klassifizierungsverzögerungen, fehlende Lieferantennachweise, schwache Protokolle oder unklare Kommunikation zu aufsichtsrechtlichen Bedenken werden können.

Eine Vorlage für Lessons Learned sollte erfassen:

• Was wann geschehen ist.
• Welche kritischen oder wichtigen Funktionen betroffen waren.
• Ob die Klassifizierung rechtzeitig und zutreffend war.
• Ob DORA-Meldeentscheidungen mit ausreichenden Nachweisen getroffen wurden.
• Ob GDPR-, NIS2-, vertragliche oder kundenbezogene Benachrichtigungsauslöser bewertet wurden.
• Ob Lieferanten innerhalb vereinbarter Fristen reagiert haben.
• Ob Protokolle und forensische Beweismittel gesichert wurden.
• Welche Maßnahmen versagt haben oder fehlten.
• Welche Richtlinien, Playbooks, Schulungen oder technischen Maßnahmen verbessert werden müssen.
• Wer für jede Korrekturmaßnahme verantwortlich ist und bis wann.

Dies fließt auch in die ISO/IEC 27001:2022-Managementbewertung ein. Vorfalltrends sollten durch die Leitung überprüft und nicht in technischen Postmortems verborgen werden.

Cross-Compliance: DORA, GDPR, NIS2, NIST und COBIT 2019

DORA steht für Finanzunternehmen im Mittelpunkt, doch Vorfallmeldungen gehören selten nur zu einem Rahmenwerk.

Ein einzelner IKT-Vorfall kann die DORA-Meldung schwerwiegender IKT-bezogener Vorfälle, die GDPR-Meldung einer Verletzung des Schutzes personenbezogener Daten, die NIS2-Meldung eines erheblichen Vorfalls, vertragliche Kundenpflichten, Cyberversicherungsbenachrichtigungen und Berichte an das Leitungsorgan betreffen.

Zenith Controls hilft, diese Komplexität zu reduzieren, indem ISO/IEC 27002:2022-Maßnahmen rahmenwerkübergreifend zugeordnet werden. Beispiel:

Aus NIST-Perspektive unterstützt dasselbe Modell die Ergebnisse Detect, Respond und Recover. Aus COBIT 2019- und ISACA-Auditperspektive steht Governance im Vordergrund: ob Incident Management, Kontinuität, Risiko, Compliance, Lieferantenverantwortlichkeiten und Leistungsüberwachung kontrolliert werden.

Die reifsten Organisationen erstellen keine separaten Workflows für jedes Rahmenwerk. Sie schaffen einen Incident-Management-Prozess mit regulatorischen Überlagerungen. Das Ticket erfasst die Kerndaten einmal und verzweigt dann bei Bedarf in DORA-, GDPR-, NIS2-, vertragliche, versicherungsbezogene oder branchenspezifische Meldungen.

Wie Auditoren Ihren DORA-Vorfallprozess prüfen werden

Ein DORA-fähiger Prozess zur Vorfallmeldung muss verschiedenen Auditperspektiven standhalten.

Ein ISO/IEC 27001:2022-Auditor wird prüfen, ob das ISMS relevante Anhang A-Maßnahmen ausgewählt und umgesetzt hat, ob die Anwendbarkeitserklärung diese Maßnahmen stützt, ob Vorfallaufzeichnungen vorhanden sind und ob internes Audit und Managementbewertung die Vorfallleistung berücksichtigen.

Zenith Controls verweist für 5.24, 5.25 und 6.8 auf die Auditmethodik nach ISO/IEC 19011:2018. Für 5.24 prüfen Auditoren den Incident-Response-Plan auf Vorfallarten, Schweregradklassifizierungen, zugewiesene Rollen, Kontaktlisten, Eskalationswege, Anweisungen für regulatorische Meldungen und Kommunikationsverantwortlichkeiten. Für 5.25 prüfen sie, ob dokumentierte Klassifizierungskriterien existieren, etwa Schweregradmatrizen oder Entscheidungsbäume auf Basis von Systemauswirkung, Datensensitivität und Dauer. Für 6.8 bewerten sie Meldewege, Time-to-Report-Kennzahlen und Nachweise, dass gemeldete Ereignisse protokolliert, triagiert und gelöst werden.

Eine DORA-Aufsichtsprüfung wird sich darauf konzentrieren, ob schwerwiegende IKT-bezogene Vorfälle gemäß regulatorischen Erwartungen erkannt, klassifiziert, gemeldet, aktualisiert und abgeschlossen werden. Der Prüfer kann einen Beispielvorfall anfordern und ihn von der ersten Warnmeldung bis zum Abschlussbericht nachverfolgen.

Ein Datenschutzauditor wird prüfen, ob das Risiko einer Verletzung des Schutzes personenbezogener Daten bewertet wurde und ob Pflichten aus GDPR Article 33 und Article 34 ausgelöst wurden. BS EN 17926:2023 ist hier relevant, weil sie Verantwortlichkeiten bei Datenschutzvorfällen, Benachrichtigungskriterien, Fristen und die Ausrichtung an Erwartungen zur Offenlegung gegenüber Aufsichtsbehörden ergänzt.

Dieselben Nachweise können mehrere Auditfragen beantworten, wenn sie von Anfang an korrekt strukturiert sind.

Checkliste zur DORA-Vorfallmeldebereitschaft für 2026

Prüfen Sie Ihre Organisation vor der nächsten Tabletop-Übung, dem nächsten internen Audit oder der nächsten Aufsichtsprüfung anhand dieser Checkliste:

• Wissen Mitarbeitende, wie vermutete IKT-Vorfälle zu melden sind?
• Gibt es einen dedizierten Meldekanal für Vorfälle?
• Werden Sicherheitsereignisse konsistent protokolliert und triagiert?
• Gibt es eine dokumentierte Schweregrad- und DORA-Klassifizierungsmatrix für schwerwiegende Vorfälle?
• Muss die Klassifizierung innerhalb einer definierten Frist nach Benachrichtigung erfolgen?
• Sind kritische oder wichtige Funktionen Systemen und Lieferanten zugeordnet?
• Werden DORA-, GDPR-, NIS2-, vertragliche, versicherungsbezogene und kundenbezogene Benachrichtigungsauslöser in einem Workflow bewertet?
• Sind Vorfallrollen über IT, Sicherheit, Rechtsabteilung, Compliance, Datenschutz, Kommunikation und Geschäftsverantwortliche hinweg definiert?
• Reichen Protokolle aus, um Vorfallzeitachsen zu rekonstruieren?
• Werden Beweismittel mit Beweismittelkette gesichert?
• Werden Vorfallpflichten von Lieferanten und Rechte auf Protokollzugriff getestet?
• Werden Tabletop-Übungen mit realistischen DORA-Szenarien durchgeführt?
• Werden Lessons Learned bis zu Korrekturmaßnahmen nachverfolgt?
• Werden Vorfallkennzahlen in der Managementbewertung überprüft?
• Ist die Anwendbarkeitserklärung auf DORA-relevante ISO/IEC 27001:2022-Maßnahmen abgebildet?

Wenn die Antwort auf eine dieser Fragen „teilweise“ lautet, ist das Problem nicht nur Compliance. Es ist operative Resilienz.

Aufbau eines nachweisfähigen DORA-Modells für die Vorfallmeldung

Die DORA-Vorfallmeldung im Jahr 2026 ist ein Test für Governance unter Druck. Gut abschneiden werden nicht die Organisationen mit den längsten Incident-Response-Dokumenten. Gut abschneiden werden die Organisationen mit klaren Meldekanälen, schneller Klassifizierung, verlässlichen Protokollen, gesicherten Beweismitteln, geschulten Menschen, getesteter Lieferanteneskalation und rahmenwerkübergreifender Nachvollziehbarkeit.

Clarysec kann Ihnen helfen, dieses Betriebsmodell aufzubauen.

Beginnen Sie damit, Ihre Vorfallrisiken und die Anwendbarkeitserklärung mit dem Zenith Blueprint: 30-Schritte-Fahrplan für Auditoren abzubilden. Richten Sie anschließend Ihre Vorfallmaßnahmen an Zenith Controls: Der Cross-Compliance-Leitfaden aus. Operationalisieren Sie den Prozess mit Clarysecs Incident-Response-Richtlinie, Incident-Response-Richtlinie – KMU, Richtlinie zur Protokollierung und Überwachung – KMU, Richtlinie zur Beweissicherung und Forensik und Richtlinie zur Beweissicherung und Forensik – KMU.

Wenn Ihre Geschäftsleitung vor dem nächsten echten Vorfall Sicherheit gewinnen möchte, führen Sie mit dem Clarysec-Toolkit eine Tabletop-Übung zu einem schwerwiegenden IKT-bezogenen DORA-Vorfall durch und erstellen Sie das Nachweispaket, das ein Auditor oder eine Aufsichtsbehörde erwarten würde.