Klassifizierung des Schweregrads von Vorfällen für DORA, NIS2 und GDPR

Die Vorfallkonferenz um 02:17 Uhr, die zur regulatorischen Entscheidung wird

Um 02:17 Uhr an einem Donnerstagmorgen sieht Sarah, CISO von FinScale, die erste Warnmeldung: ungewöhnlicher API-Datenverkehr, sprunghaft ansteigende fehlgeschlagene Authentifizierungen und eine Latenz im Zahlungs-Dashboard von über 3000 ms. Innerhalb weniger Minuten meldet der Kundensupport Fehler beim Zahlungsstatus. Der Cloud-Anbieter teilt mit, dass kein plattformweiter Vorfall vorliegt. Das SOC erkennt verdächtige Zugriffstoken aus zwei geografischen Regionen. Das Produktteam bestätigt, dass das Dashboard nach 19 Minuten wieder online ist, doch zwölf Kunden haben bereits Tickets eröffnet.

Um 03:05 Uhr ist Sarah mit dem Incident Commander, der Rechtsabteilung, dem Datenschutzkoordinator, der Leitung des Cloud-Betriebs und dem verantwortlichen Sponsor aus der Geschäftsleitung in der Krisenbrücke. Die technische Frage ist hinreichend klar: Was ist mit dem API-Gateway passiert? Die regulatorischen Fragen sind schwieriger:

1. Ist dies ein schwerwiegender IKT-bezogener Vorfall nach DORA?
2. Ist es ein erheblicher Vorfall nach NIS2?
3. Liegt eine GDPR-relevante Verletzung des Schutzes personenbezogener Daten vor, die eine Meldung erfordert?
4. Kann die Organisation nachweisen, wie sie zu diesen Antworten gelangt ist?

Die falsche Antwort kann regulatorische Exponierung schaffen. Die langsame Antwort kann dazu führen, dass eine Meldefrist versäumt wird. Die undokumentierte Antwort kann Monate später in einem Audit nach ISO/IEC 27001:2022 scheitern.

Das ist die Herausforderung für die Vorfallreaktion im Jahr 2026. Viele Organisationen verfügen über einen Vorfallreaktionsplan, forensische Verfahren, Datenschutz-Playbooks und Vorlagen für Krisenkommunikation. Weniger Organisationen verfügen über ein belastbares Klassifizierungsmodell für den Schweregrad von Vorfällen, das ein verrauschtes Sicherheitsereignis in eine dokumentierte Entscheidung über DORA, NIS2, GDPR und die Nachweiserwartungen nach ISO/IEC 27001:2022 überführt.

Die Lösung besteht nicht aus drei getrennten Triage-Prozessen. Sie besteht aus einem gesteuerten Schweregradmodell mit separaten regulatorischen Prüfebenen, messbaren Schwellenwerten, Eskalationsregeln, Entscheidungsprotokollen und Anforderungen an die Beweissicherung. Praktisch bedeutet das: Der Schweregrad eines Vorfalls darf kein unter Druck vergebenes Etikett sein. Er muss eine kontrollierte Geschäftsentscheidung sein, die der Prüfung durch Aufsichtsbehörden, Auditoren, Mitglieder des Leitungsorgans, Kunden und den Datenschutzbeauftragten (DPO) standhält.

Warum die Klassifizierung des Schweregrads von Vorfällen heute eine Kontrolle auf Ebene des Leitungsorgans ist

Vorfallklassifizierung war früher überwiegend technisch geprägt: Schweregrad von Schadsoftware, betroffene Hosts, ausgenutzte Schwachstellen und die Frage, ob Daten exfiltriert wurden. Im Jahr 2026 ist sie zugleich rechtlich, finanziell, gesellschaftlich und vertraglich relevant.

DORA macht digitale operationale Resilienz zu einer Governance-Verpflichtung für Finanzunternehmen. Das Leitungsorgan muss den Rahmen für das IKT-Risikomanagement definieren, genehmigen und überwachen und bleibt dafür verantwortlich. Dazu gehören Aufrechterhaltung des IKT-Geschäftsbetriebs, Reaktions- und Wiederherstellungspläne, Meldekanäle für schwerwiegende Vorfälle, IKT-Drittparteienrisiken und Lessons Learned.

NIS2 erhöht die Governance-Anforderungen für wesentliche und wichtige Einrichtungen. Article 20 verlangt von Leitungsorganen, Cybersicherheits-Risikomanagementmaßnahmen zu genehmigen, deren Umsetzung zu überwachen und an Schulungen teilzunehmen. Außerdem verbindet NIS2 Versäumnisse im Risikomanagement und bei der Vorfallmeldung mit erheblichen aufsichtsrechtlichen Folgen. Für wesentliche Einrichtungen können die Obergrenzen der Verwaltungsgeldbußen mindestens 10.000.000 EUR oder 2 Prozent des gesamten weltweiten Jahresumsatzes betragen, je nachdem, welcher Betrag höher ist. Für wichtige Einrichtungen liegt die Ausgangsbasis bei mindestens 7.000.000 EUR oder 1,4 Prozent des Umsatzes, je nachdem, welcher Betrag höher ist.

GDPR ergänzt eine andere Perspektive. Eine Verletzung des Schutzes personenbezogener Daten ist nicht auf bestätigte öffentliche Offenlegung oder gestohlene Dateien beschränkt. Sie umfasst die unbeabsichtigte oder unrechtmäßige Vernichtung, den Verlust, die Veränderung, die unbefugte Offenlegung von oder den unbefugten Zugriff auf personenbezogene Daten. Verantwortliche müssen das Risiko für betroffene Personen bewerten und Rechenschaft darüber ablegen können, warum gemeldet oder nicht gemeldet wurde.

ISO/IEC 27001:2022 gibt diesen Verpflichtungen ein Nachweisrückgrat. Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, die Anforderungen interessierter Parteien, den Geltungsbereich, Schnittstellen und Abhängigkeiten versteht. Die Klauseln 5.1 bis 5.3 verlangen Führungsverpflichtung, Richtlinie, Rollen, Verantwortlichkeiten und Berichterstattung. Die Klauseln 6.1.1 bis 6.1.3 verlangen risikobasierte Planung, Risikobeurteilung, Risikobehandlung und eine Erklärung zur Anwendbarkeit. Die Klauseln 8.1 bis 8.3 verlangen operative Steuerung, Änderungskontrolle, aufbewahrte Nachweise und Neubewertung bei veränderten Risikobedingungen. ISO/IEC 27001:2022

Wenn die Vorfallkonferenz stattfindet, sollte die Frage nicht lauten: „Wer hält das für kritisch?“ Sie sollte lauten: „Was verlangen unsere genehmigten Kriterien, rechtlichen Auslöser, Nachweise und Eskalationsregeln jetzt von uns?“

Ein Ereignis, drei regulatorische Klassifizierungssysteme

DORA, NIS2 und GDPR verwenden für Vorfälle nicht dieselbe Sprache. Das ist der Kern­grund, warum Organisationen in der ersten Stunde Schwierigkeiten haben.

DORA Article 17 verlangt von Finanzunternehmen, einen IKT-bezogenen Vorfallmanagementprozess einzurichten, der IKT-Vorfälle erkennt, steuert und meldet, IKT-bezogene Vorfälle und erhebliche Cyberbedrohungen aufzeichnet, Ursachen adressiert, Frühwarnindikatoren nutzt, Vorfälle kategorisiert und klassifiziert, Rollen zuweist, Kommunikation steuert, schwerwiegende Vorfälle an das obere Management eskaliert und den sicheren Betrieb wiederherstellt.

DORA Article 18 verlangt eine Klassifizierung anhand von Kriterien wie betroffenen Kunden, betroffenen Gegenparteien, Transaktionen, Dauer, Ausfallzeit, geografischer Ausbreitung, Datenverlust mit Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Kritikalität der betroffenen Services und wirtschaftlichen Auswirkungen. DORA Article 19 verlangt die Meldung schwerwiegender IKT-bezogener Vorfälle und Kundenkommunikation, wenn finanzielle Interessen betroffen sind.

NIS2 Article 23 definiert einen erheblichen Vorfall als einen Vorfall, der eine schwerwiegende Betriebsstörung oder einen finanziellen Verlust verursacht hat oder verursachen kann oder der andere durch erheblichen materiellen oder immateriellen Schaden beeinträchtigt hat oder beeinträchtigen kann. Er verlangt eine Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden des erheblichen Vorfalls, eine Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichte auf Anfrage und einen Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung. Soweit anwendbar, müssen betroffene Leistungsempfänger auch über Maßnahmen oder Abhilfen informiert werden, die sie ergreifen können.

GDPR stellt eine Datenschutz-Risikofrage. Hat eine Sicherheitsverletzung zur Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum Zugriff auf personenbezogene Daten geführt? Wenn ja, muss der Verantwortliche das Risiko für die Rechte und Freiheiten natürlicher Personen bewerten. Wenn die Verletzung voraussichtlich zu einem Risiko führt, ist die Aufsichtsbehörde in der Regel innerhalb von 72 Stunden nach Bekanntwerden zu benachrichtigen. Wenn sie voraussichtlich zu einem hohen Risiko führt, müssen betroffene Personen gegebenenfalls unverzüglich informiert werden.

Ein einzelner Vorfall benötigt daher eine gleichzeitige Klassifizierung.

Für Finanzunternehmen ist DORA der sektorspezifische Rechtsakt der Union für IKT-Risikomanagement und Vorfallmeldepflichten, die sich mit NIS2 überschneiden. Das macht NIS2 nicht irrelevant. NIS2 kann weiterhin für Zusammenarbeit, Informationsflüsse, Services außerhalb des DORA-Perimeters, nichtfinanzielle Gruppengesellschaften, Cloud-Services, Managed Services und vertragliche Kundenverpflichtungen relevant sein. Das Schweregradmodell sollte nicht nur das Ergebnis, sondern auch die Anwendbarkeitslogik dokumentieren.

Clarysecs Modell: Das Ereignis klassifizieren, nicht die Emotion

Clarysec beginnt mit ISO/IEC 27002:2022 Maßnahme 5.25, Bewertung und Entscheidung über Informationssicherheitsereignisse, als regelwerksübergreifendem Compliance-Anker. In Zenith Controls: The Cross-Compliance Guide Zenith Controls wird dieses Thema über den Eintrag „Bewertung und Entscheidung über Informationssicherheitsereignisse“ für Maßnahme 5.25 abgebildet, unterstützt durch „Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen“ für Maßnahme 5.24 und „Beweissicherung“ für Maßnahme 5.28.

Der wichtigste Compliance-Moment ist häufig nicht die Eindämmung. Es ist die Weggabelung, an der ein Sicherheitsereignis zu einem regulatorischen Vorfall wird oder belastbar als Ereignis mit niedrigerem Schweregrad dokumentiert wird.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint beschreibt diesen Moment in der Phase „Controls in Action“, Schritt 23:

„Nicht jede Anomalie ist eine Katastrophe. Nicht jede Warnmeldung signalisiert eine Kompromittierung. In der Praxis werden Sicherheitsteams und Fachbereiche mit Rauschen überflutet: Anmeldeversuche, Protokollanomalien, geringfügige Richtlinienverstöße, Shadow-IT-Aktivitäten. Die eigentliche Herausforderung liegt nicht nur in der Erkennung, sondern darin, Harmloses von Schädlichem zu unterscheiden und zu wissen, was eine Eskalation erfordert.“

Dieser Satz beschreibt das operative Problem. Eine SIEM-Warnmeldung entspricht nicht automatisch einem schwerwiegenden DORA-Vorfall. Ein vorübergehender Ausfall ist nicht automatisch ein erheblicher NIS2-Vorfall. Eine verdächtige Datenbankabfrage ist nicht automatisch nach GDPR meldepflichtig. Jeder dieser Fälle kann meldepflichtig werden, abhängig von Auswirkungen, Umfang, Daten, betroffenen Parteien und Nachweisen.

Der Zenith Blueprint, Phase Risikomanagement, Schritt 10, empfiehlt außerdem, Auswirkungsdefinitionen an Geschäftsgröße und regulatorische Exponierung anzupassen:

„Bei der Definition von Auswirkungen ist es sinnvoll, die Stufen auf Ihre spezifische Geschäftsgröße zu beziehen. Beispiel: ‚Wesentliche finanzielle Auswirkung = Verlust > $100k‘ (an Ihren Kontext anpassen). Berücksichtigen Sie auch regulatorische Auswirkungen: Eine Datenpanne personenbezogener Daten kann beispielsweise aufgrund von GDPR-Bußgeldern und Meldepflichten automatisch als ‚Major‘ oder ‚Severe‘ eingestuft werden, selbst wenn der direkte finanzielle Verlust unklar ist.“

Das ist das Designprinzip für die Klassifizierung des Schweregrads von Vorfällen im Jahr 2026: Schweregrad ist Geschäftsauswirkung plus rechtliche Auswirkung plus Belastbarkeit der Nachweise.

Eine praxisnahe Taxonomie für den Schweregrad von Vorfällen nach DORA, NIS2 und GDPR

Eine belastbare Taxonomie muss internen Schweregrad und regulatorische Klassifizierung trennen. Der interne Schweregrad steuert Reaktionsdringlichkeit, Ressourcenzuteilung und Eskalation an Führungskräfte. Die regulatorische Klassifizierung steuert Meldung, rechtliche Prüfung und externe Kommunikation.

Der interne Schweregrad ist nicht die endgültige regulatorische Antwort. Er ist der Betriebsmodus. Ein SEV 3-Ereignis kann nach Protokollprüfung nach GDPR meldepflichtig werden. Ein SEV 2-Ausfall ist möglicherweise kein schwerwiegender DORA-Vorfall, wenn Auswirkungsschwellen nicht erreicht werden. Ein SEV 1-Ransomware-Vorfall kann gleichzeitig DORA, NIS2, GDPR, Kundenverträge und die Koordination mit Strafverfolgungsbehörden auslösen.

Eine detailliertere Klassifizierungsmatrix hilft dem Team, von der Warnmeldung zur Handlung zu gelangen.

Das Modell muss in Richtlinien verankert sein und darf nicht der stärksten Stimme in der Krisenbrücke überlassen werden. Die KMU-Incident Response Policy-sme Incident Response Policy-sme - SME, Governance-Anforderungen, Klausel 5.3.1, legt fest:

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

Dieselbe KMU-Richtlinie ergänzt unter Risikobehandlung und Ausnahmen, Klausel 7.4.1:

„Wenn Kundendaten betroffen sind, muss der General Manager rechtliche Meldepflichten auf Grundlage der Anwendbarkeit von GDPR, NIS2 oder DORA bewerten.“

Für größere Organisationen formalisiert die Enterprise-Incident Response Policy Incident Response Policy, Governance-Anforderungen, Klausel 5.3, dasselbe Konzept:

„Die Vorfallklassifizierung muss einem abgestuften Modell folgen:“

Die Richtliniensprache ist wichtig, weil Aufsichtsbehörden und Auditoren fragen werden, ob Klassifizierungskriterien bereits vor dem Vorfall bestanden. Eine nachträglich erfundene Matrix ist ein schwacher Nachweis. Eine genehmigte, geschulte, geübte und konsistent verwendete Matrix ist belastbar.

Das Entscheidungsprotokoll: das wichtigste Nachweisartefakt

Wenn Auditoren, Aufsichtsbehörden oder Mitglieder des Leitungsorgans einen Vorfall überprüfen, fragen sie selten nur: „Was ist passiert?“ Sie fragen: „Wann wussten Sie es, wer hat entschieden, auf Basis welcher Nachweise, und warum haben Sie nicht früher gemeldet?“

Deshalb empfiehlt Clarysec für jedes SEV 3-Ereignis und höher sowie für jedes Ereignis mit personenbezogenen Daten, kritischen Services, Finanzkunden, Managed Services, Cloud-Infrastruktur oder grenzüberschreitenden Auswirkungen ein Entscheidungsprotokoll zum Schweregrad.

Dies bildet direkt auf ISO/IEC 27001:2022 ab. Klausel 8.1 verlangt, dass Prozesse geplant, umgesetzt und gesteuert werden und ausreichend dokumentierte Information aufbewahrt wird, um zu zeigen, dass sie wie geplant durchgeführt wurden. Die Klauseln 8.2 und 8.3 verlangen eine Neubewertung bei wesentlichen Änderungen und die Aufbewahrung von Nachweisen zur Risikobehandlung. Annex A-Maßnahmen A.5.24 bis A.5.28 bilden das Rückgrat des Vorfallmanagements: Planung und Vorbereitung, Ereignisbewertung und Entscheidung, Reaktion, Lernen aus Vorfällen und Beweissicherung.

Die KMU-Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Durchsetzung und Einhaltung, Klausel 8.3.2, unterstützt die GDPR-Seite des Modells:

„Der Datenschutzkoordinator bestimmt den Schweregrad, leitet Eindämmungsmaßnahmen ein und dokumentiert den Fall.“

Die Datenschutzbewertung darf nicht erst beginnen, wenn die regulatorische Uhr unangenehm wird. Sie gehört in den Triage-Workflow.

Praxisbeispiel: Klassifizierung von Sarahs API-Vorfall

Zurück zu FinScale. FinScale ist eine B2B-Fintech-Plattform, die Cloud-Infrastruktur, einen externen Anbieter für Betrugsanalysen und einen Managed-Security-Provider nutzt. Für einige Aktivitäten ist FinScale ein von DORA erfasstes Finanzunternehmen. Außerdem ist FinScale ein digitaler Diensteanbieter mit NIS2-relevanten Abläufen in einem Mitgliedstaat. Das Unternehmen verarbeitet personenbezogene Kundendaten als Verantwortlicher für Kontodienste und als Auftragsverarbeiter für einige Unternehmenskunden.

Um 02:17 Uhr wird ungewöhnlicher API-Datenverkehr erkannt. Um 02:35 Uhr wird das Vorfallticket eröffnet. Um 03:00 Uhr schließt Sarah die erste Triage mit dem Incident Commander ab.

Zuerst wird der interne Schweregrad festgelegt. Der Vorfall beeinträchtigte die Verfügbarkeit des Kunden-Dashboards für 19 Minuten, umfasste verdächtige Zugriffstoken und betraf eine kritische kundenbezogene Funktion. Er wird bis zur Bestätigung als SEV 3 Moderat klassifiziert, mit Eskalation an den Incident Commander, den Datenschutzkoordinator, die Rechtsabteilung und den Serviceverantwortlichen.

Zweitens wird die DORA-Prüfung abgeschlossen. Das Team prüft betroffene Kunden, Gegenparteien, Transaktionen, Dauer, Ausfallzeit, geografische Ausbreitung, Datenverlust, Kritikalität und wirtschaftliche Auswirkungen. Es werden keine fehlgeschlagenen oder veränderten Transaktionen bestätigt. Die Ausfallzeit ist begrenzt. Ein Datenverlust ist nicht nachgewiesen. Da jedoch eine kritische Komponente eines Finanzdienstes und finanzielle Kundeninteressen betroffen sein können, bleibt der Vorfall unter DORA-Überwachung und kann neu klassifiziert werden.

Drittens wird die NIS2-Prüfung dokumentiert. Das Team hält fest, dass DORA das primäre sektorspezifische Melderegime für die Verpflichtungen des erfassten Finanzunternehmens ist. Es prüft außerdem, ob der Vorfall Services oder Kunden außerhalb des DORA-Perimeters betrifft. Zu diesem Zeitpunkt ist keine schwerwiegende Betriebsstörung und kein erheblicher Schaden bestätigt.

Viertens wird die GDPR-Prüfung gestartet. Die verdächtigen Token könnten Zugriff auf Daten im Kunden-Dashboard ermöglicht haben. Der Datenschutzkoordinator dokumentiert Datenkategorien, betroffene Benutzer, Token-Umfang, geprüfte Protokolle, ob Daten eingesehen oder exportiert wurden, sowie Schutzmaßnahmen wie Token-Ablauf und Zugriffskontrollen.

Um 04:20 Uhr zeigt die Protokollanalyse, dass zwei Token verwendet wurden, um auf Dashboard-Metadaten von 41 Kunden zuzugreifen, einschließlich Namen, Kontokennungen und Transaktionsstatus, jedoch ohne Zahlungszugangsdaten oder Ausweisdokumente. Das Team stuft den Vorfall auf SEV 2 Schwerwiegend hoch, weil die Vertraulichkeit personenbezogener Daten betroffen war und Kundenkommunikation erforderlich sein kann. Der DPO bewertet das GDPR-Risiko für betroffene Personen. Die DORA-Entscheidung wird auf Grundlage von Kundenwirkung, Transaktionswirkung und wirtschaftlicher Auswirkung erneut geprüft.

Das ist der praktische Wert des Modells. Die Erstklassifizierung ist keine endgültige rechtliche Schlussfolgerung. Sie ist eine nachweisgestützte Entscheidung, die aktualisiert werden kann, wenn sich die Faktenlage entwickelt.

Protokollierung, Überwachung und forensische Nachweise: die Beweisschicht

Ein Schweregradmodell ohne Nachweise ist eine Sitzungsmeinung. Die Erwartung im Jahr 2026 lautet, dass die Klassifizierung durch Protokolle, Überwachung, gesicherte Artefakte und eine dokumentierte Beweismittelkette gestützt wird.

Die KMU-Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Durchsetzung und Einhaltung, Klausel 8.3.4, legt fest:

„Untersuchungen von Verstößen müssen durch angemessene Protokolle unterstützt werden, um dem Rechenschaftsprinzip nach GDPR und DORA zu entsprechen.“

Der forensische Umgang ist ebenso wichtig. Die KMU-Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Governance-Anforderungen, Klausel 5.3.1, verlangt:

„Für jeden Vorfall muss ein einfaches Protokoll zur Übertragungskette geführt werden (z. B. Excel-Datei oder Vorlagendokument).“

Für Enterprise-Umgebungen verlangt die Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Governance-Anforderungen, Klausel 5.5:

„Alle gesammelten Beweismittel müssen eindeutig identifiziert, gekennzeichnet und in einem sicheren Repository gespeichert werden mit:“

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, erklärt, warum dies für ISO/IEC 27002:2022 Maßnahme 5.28 relevant ist:

„Wenn ein Informationssicherheitsvorfall auftritt, ist einer der kritischsten und dennoch häufig übersehenen Bestandteile der Reaktion der Nachweis. Nicht Protokolle, nicht Screenshots, nicht lose Erzählungen, sondern ordnungsgemäß gesicherte, die Übertragungskette respektierende und manipulationsresistente Beweismittel.“

Ein praxisnahes Nachweispaket für einen schwerwiegenden oder potenziell meldepflichtigen Vorfall sollte enthalten:

• Vorfallticket und Zeitachse
• Entscheidungsprotokoll zum Schweregrad und Historie der Neuklassifizierung
• SIEM-Warnmeldungen, EDR-Warnmeldungen, Cloud-Protokolle und Identitätsprotokolle
• Datenzugriffsprotokolle und Exportprotokolle
• Einträge im Inventar betroffener Assets und Services
• Bewertung der Auswirkungen auf Kunden, Transaktionen und geografische Bereiche
• Arbeitsblatt zur DORA-, NIS2- und GDPR-Prüfung
• Bewertung durch DPO oder Rechtsabteilung
• Kommunikationsfreigaben und versandte Nachrichten
• Dokumentation der Beweismittelkette
• Ursachenanalyse
• Korrekturmaßnahmen und Lessons Learned

Dieses Nachweispaket unterstützt auch ISO/IEC 27001:2022 Annex A-Maßnahmen A.8.15 Protokollierung, A.8.16 Überwachungstätigkeiten, A.5.28 Beweissicherung, A.5.27 Lernen aus Informationssicherheitsvorfällen, A.5.31 rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen sowie A.5.34 Datenschutz und Schutz personenbezogener Daten.

Mapping über mehrere Regelwerke: einmal aufbauen, viele Auditoren beantworten

Die stärksten Modelle zur Klassifizierung des Schweregrads von Vorfällen werden einmal aufgebaut und mehrfach abgebildet. Zenith Controls ist für diese Arbeit als Kompass für regelwerksübergreifende Compliance konzipiert. Für dieses Thema sind die zentralen Einträge aus ISO/IEC 27002:2022: 5.24 Planung und Vorbereitung des Managements von Informationssicherheitsvorfällen, 5.25 Bewertung und Entscheidung über Informationssicherheitsereignisse, 5.26 Reaktion auf Informationssicherheitsvorfälle, 5.27 Lernen aus Informationssicherheitsvorfällen und 5.28 Beweissicherung.

Diese Maßnahmen lassen sich natürlich in das Managementsystem nach ISO/IEC 27001:2022 einordnen. Die Klauseln 4, 5, 6 und 8 definieren Geltungsbereich, Führung, Risikokriterien, Behandlung und operative Nachweise. ISO/IEC 27002:2022 liefert die Sprache zur Umsetzung der Maßnahmen. Denken im Stil von ISO 22301 zur Aufrechterhaltung des Geschäftsbetriebs unterstützt Schwellenwerte für Störungen, Wiederherstellungsprioritäten und Krisenmanagement. Praktiken im Stil von ISO/IEC 27035 zum Vorfallmanagement unterstützen strukturierte Erkennung, Meldung, Bewertung, Reaktion und Lernen. Datenschutz-Governance im Stil von ISO/IEC 27701 unterstützt Rollen bei Verletzungen des Schutzes personenbezogener Daten, Überlegungen zu Verantwortlichen und Auftragsverarbeitern, Datenschutznachweise und Rechenschaftspflicht.

Dasselbe Modell lässt sich auf das NIST Cybersecurity Framework 2.0 abbilden. Die GOVERN Function verlangt, dass rechtliche, regulatorische, vertragliche, datenschutzbezogene sowie bürgerrechtliche Verpflichtungen verstanden und gesteuert werden. Außerdem erwartet sie, dass Risikobereitschaft, Rollen, Befugnisse, Richtlinien und Aufsicht definiert sind. Die DETECT-, RESPOND- und RECOVER Functions unterstützen Triage, Analyse, Eskalation, Eindämmung, Wiederherstellung, Kommunikation und Verbesserung.

Der Nutzen ist praktisch. Wenn eine DORA-Aufsichtsbehörde nach der Begründung für einen schwerwiegenden IKT-bezogenen Vorfall fragt, eine NIS2-Behörde nach der Entscheidung zur 24-Stunden-Frühwarnung, eine Datenschutzaufsichtsbehörde danach, warum eine GDPR-Meldung erfolgt ist oder nicht erfolgt ist, und ein ISO-Auditor danach, ob das ISMS wie geplant betrieben wurde, kann die Organisation aus demselben Nachweissatz antworten.

Wie Auditoren und Aufsichtsbehörden Ihr Modell prüfen werden

Ein Auditor für ISO/IEC 27001:2022 beginnt in der Regel mit dem Geltungsbereich und den rechtlichen Anforderungen. Er wird fragen, ob DORA, NIS2, GDPR, Kundenverträge und IKT-Drittparteienverpflichtungen als Anforderungen interessierter Parteien identifiziert wurden. Anschließend folgt er der Spur zu Risikokriterien, Erklärung zur Anwendbarkeit, Vorfallverfahren, operativen Aufzeichnungen und Nachweisaufbewahrung. Er möchte Belege dafür, dass der Klassifizierungsprozess nicht während des Vorfalls erfunden wurde.

Eine DORA-Aufsichtsbehörde oder ein internes Auditteam wird nach einem Lebenszyklus suchen: Vorfallmanagementprozess, Frühwarnindikatoren, Klassifizierungskriterien, Eskalation schwerwiegender Vorfälle, Kundenkommunikation, Ursache, endgültige Auswirkungszahlen, Resilienztests und Aufsicht durch das Leitungsorgan. Außerdem wird gefragt, ob IKT-Drittparteienabhängigkeiten berücksichtigt wurden, insbesondere wenn Cloud-, SaaS-, Managed-Security- oder Outsourcing-Anbieter beteiligt waren.

Ein NIS2-fokussierter Auditor oder eine Behörde wird prüfen, ob die Einrichtung erhebliche Vorfälle identifizieren, gestufte Fristen einhalten, mit betroffenen Leistungsempfängern kommunizieren und Nachweise für die Bewertung grenzüberschreitender Auswirkungen vorlegen kann. Dabei wird der Umgang mit Vorfällen mit den Risikomanagementmaßnahmen nach Article 21 verknüpft, einschließlich Aufrechterhaltung des Geschäftsbetriebs, Krisenmanagement, Sicherheit der Lieferkette, Zugriffskontrolle, Asset-Management und Schulung.

Ein GDPR-DPO oder eine Aufsichtsbehörde wird untersuchen, ob die Organisation personenbezogene Daten, Rollen, betroffene Personen, Kategorien, betroffene Systeme, Art der Verletzung und Risiko für betroffene Personen identifiziert hat. Geprüft wird, ob der Verantwortliche Rechenschaftspflicht nachweisen kann und ob Meldungen von Auftragsverarbeitern an Verantwortliche rechtzeitig und vollständig waren.

Ein Auditor mit ISACA- oder COBIT 2019-Perspektive konzentriert sich auf Governance-Nachweise. Wer hat die Schweregradtaxonomie genehmigt? Wer ist Risikoverantwortlicher? Welche Kennzahlen werden an das Management berichtet? Wie werden Ausnahmen behandelt? Wie werden Lessons Learned in Verbesserungen von Kontrollen überführt?

Häufige Fehlermuster bei der Vorfallklassifizierung

Das erste Fehlermuster ist Ein-Etikett-Denken. Teams klassifizieren ein Ereignis als hoch, mittel oder niedrig, bewerten aber DORA-, NIS2- und GDPR-Auslöser nicht getrennt. Das Ergebnis ist ein Schweregradetikett, das eine Meldeentscheidung nicht erklären kann.

Das zweite Fehlermuster ist der Bestätigungsbias bei Datenschutzverletzungen. Teams warten auf absoluten Nachweis einer Exfiltration, bevor Datenschutz oder Rechtsabteilung einbezogen werden. Eine GDPR-Bewertung beginnt häufig bereits bei möglichem unbefugtem Zugriff, Verlust, Veränderung oder Offenlegung, nicht erst bei bestätigter Veröffentlichung von Daten.

Das dritte Fehlermuster ist Zeitverwirrung. NIS2- und GDPR-Fristen hängen von Bekanntwerden und Bewertung ab. Wenn das Vorfallticket den Zeitpunkt des Bekanntwerdens, den Klassifizierungszeitpunkt und den Eskalationszeitpunkt nicht erfasst, kann die Organisation Schwierigkeiten haben, Rechtzeitigkeit nachzuweisen.

Das vierte Fehlermuster ist Forensik nach der Bereinigung. Technische Teams rotieren Schlüssel, bauen Hosts neu auf und löschen temporäre Beweismittel, bevor Untersuchungsbereitschaft aktiviert wird. Dadurch können Nachweise zerstört werden, die für regulatorische, vertragliche oder rechtliche Prüfungen erforderlich sind.

Das fünfte Fehlermuster ist Lieferantenblindheit. DORA, NIS2 und NIST CSF 2.0 betonen alle Drittparteien- und Lieferkettenrisiken. Wenn ein Cloud-Anbieter, Managed Service Provider, Zahlungsabwickler, Identitätsanbieter oder SaaS-Anbieter Teil der Vorfallkette ist, muss das Klassifizierungsmodell Lieferantenauswirkungen und vertragliche Meldepflichten einbeziehen.

Eine Clarysec-Checkliste zur Umsetzung für 2026

Um ein belastbares Klassifizierungsmodell für den Schweregrad von Vorfällen operativ umzusetzen, empfiehlt Clarysec die folgende Reihenfolge:

1. Bestätigen Sie die regulatorische Anwendbarkeit über DORA, NIS2, GDPR, Kundenverträge und sektorspezifische Vorschriften hinweg.
2. Aktualisieren Sie den ISMS-Geltungsbereich und die Anforderungen interessierter Parteien nach ISO/IEC 27001:2022.
3. Definieren Sie interne Schweregradstufen mit messbaren Schwellenwerten für Ausfallzeit, Daten, Kunden, Geografie, finanziellen Verlust und Kritikalität.
4. Ergänzen Sie den Vorfallticket-Workflow um separate Prüfungsfragen zu DORA, NIS2 und GDPR.
5. Definieren Sie Eskalationsauslöser für Incident Commander, DPO, Rechtsabteilung, oberes Management und Leitungsorgan.
6. Erstellen Sie eine Vorlage für das Entscheidungsprotokoll zum Schweregrad.
7. Verknüpfen Sie Klassifizierung mit Beweissicherung und Verfahren zur Beweismittelkette.
8. Validieren Sie die Protokollabdeckung für Identitäts-, Cloud-, Anwendungs-, Datenbank-, Netzwerk- und Lieferantenereignisse.
9. Führen Sie Tabletop-Übungen für Szenarien zu schwerwiegenden DORA-Vorfällen, erheblichen NIS2-Vorfällen und GDPR-relevanten Datenschutzverletzungen durch.
10. Speisen Sie Lessons Learned in Risikobehandlung, Erklärung zur Anwendbarkeit, Schulung und Resilienztests ein.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 16, stärkt die menschliche Seite dieses Modells: Meldungen müssen protokolliert, triagiert, über den Vorfallreaktionsplan eskaliert und auch geringfügige Ereignisse verfolgt werden, weil Trends Kontrollschwächen sichtbar machen. Er fördert eine Meldekultur mit niedriger Schwelle: „Im Zweifel melden.“

Dieser kulturelle Aspekt ist kritisch. Ein Schweregradmodell scheitert, wenn Mitarbeitende Meldungen verzögern, weil sie Überreaktionen fürchten. Ziel sind schnelle Meldung, disziplinierte Triage und belastbare Klassifizierung.

Vorfallunsicherheit in auditbereite Nachweise überführen

Im Jahr 2026 ist die Klassifizierung des Schweregrads von Vorfällen keine reine SOC-Entscheidung mehr. Sie ist ein regulierter Governance-Prozess, der Kriterien für schwerwiegende IKT-bezogene Vorfälle nach DORA, Schwellenwerte für erhebliche Vorfälle nach NIS2, Risiken aus Verletzungen des Schutzes personenbezogener Daten nach GDPR und Nachweise nach ISO/IEC 27001:2022 verbinden muss.

Die Organisationen, die in Vorfällen am besten abschneiden, sind nicht diejenigen mit dem dicksten Reaktionsordner. Es sind diejenigen, die vier Fragen schnell beantworten und jede Antwort später belegen können:

• Was ist passiert?
• Wie schwerwiegend ist es?
• Welche regulatorischen Verpflichtungen können anwendbar sein?
• Welche Nachweise stützen die Entscheidung?

Clarysec unterstützt Organisationen dabei, diese Brücke durch Richtlinienvorlagen, Schweregradtaxonomien, Entscheidungsprotokolle, Tabletop-Szenarien und regelwerksübergreifende Mappings aufzubauen. Beginnen Sie mit den Vorfallrichtlinien, validieren Sie Ihre Risikokriterien im Zenith Blueprint Zenith Blueprint, und nutzen Sie Zenith Controls Zenith Controls, um die ISO/IEC 27002:2022-Maßnahmen 5.24, 5.25, 5.26, 5.27 und 5.28 über DORA, NIS2, GDPR, NIST CSF und Auditerwartungen hinweg abzubilden.

Wenn Ihr Team innerhalb der ersten Stunde nicht beantworten kann: „Ist dies ein schwerwiegender DORA-IKT-Vorfall, ein erheblicher NIS2-Vorfall oder nach GDPR meldepflichtig?“, ist der nächste Schritt nicht ein weiterer generischer Vorfallreaktionsplan. Der nächste Schritt ist ein belastbares Betriebsmodell zur Klassifizierung des Schweregrads von Vorfällen, das getestet wurde, bevor die nächste Vorfallkonferenz um 02:17 Uhr beginnt.

Bereit, Panik durch Prozess zu ersetzen? Laden Sie Clarysecs Richtlinienvorlagen für Vorfallreaktion und Beweissicherung herunter, prüfen Sie Ihre aktuelle Schweregradtaxonomie anhand des Zenith Blueprint oder fordern Sie ein Clarysec Readiness Assessment an, um ein auditbereites Klassifizierungsmodell für Vorfälle nach DORA, NIS2, GDPR und ISO/IEC 27001 aufzubauen.