Wissensraum · Deep Dive 5 von 27
Der Unterschied zwischen Ereignis, Störung und meldepflichtigem Vorfall
Was dieser Deep Dive Ihnen zeigt
Wie Incident Reporting unter DORA strukturiert ist, welche Meldefristen gelten – und warum die meisten Meldeprozesse an der internen Klassifikation scheitern.
DORA etabliert verbindliche Anforderungen für den Umgang mit ICT-Vorfällen. Unternehmen sind verpflichtet, klare Kriterien und Prozesse festzulegen für Klassifikation, Priorisierung, Meldepflichten, Eskalationswege sowie Dokumentation und Nachweise.
In der Praxis bereitet vor allem die Abgrenzung Schwierigkeiten: Was ist ein ICT-Event? Wann wird daraus ein ICT-Incident? Ab wann liegt ein meldepflichtiger Major Incident vor? DORA adressiert diese Unsicherheiten mit einer klaren, mehrstufigen Logik.
| Ebene | Definition | Konsequenz |
|---|---|---|
| ICT-Event | Technisches Ereignis ohne unmittelbare Auswirkungen auf Dienstleistung oder Sicherheit | Keine Meldepflicht, Dokumentation empfohlen |
| ICT-Incident | Ereignis mit tatsächlichen Auswirkungen auf Verfügbarkeit, Integrität oder Vertraulichkeit | Interne Eskalation, Klassifikation, Prüfung Meldepflicht |
| Major Incident (meldepflichtig) | ICT-Incident, der definierte Schwellenwerte erreicht (Dauer, Nutzer, wirtschaftliche Auswirkungen) | Meldung an Aufsicht: Early Warning, Initial Report, Final Report |
Alles wird als Incident eingestuft → Inflationsrisiko
Oder: Vorfälle werden systematisch heruntergestuft → regulatorische Blindheit
Fehlende Bewertungsmatrix
Technische Teams entscheiden ohne Governance-Einbindung
Legal und Compliance werden zu spät einbezogen
Entscheidungen werden nicht dokumentiert
DORA verlangt eine nachvollziehbare Governance-Kette, nicht nur technische Reaktionen.
Vor DORA genügte häufig: „Wir melden, wenn es schlimm wird“ oder „Wir entscheiden situativ.“ DORA verlangt stattdessen vordefinierte Schwellenwerte, strukturierte und nachvollziehbare Bewertung, konsistente Anwendung über Organisationseinheiten hinweg und prüfbare Dokumentation der Entscheidungsfindung. Ad-hoc-Entscheidungen ohne Dokumentation sind damit nicht mehr ausreichend.
Ausgangssituation
Ein Dienstleister verzeichnet eine 45-minütige Störung seines Authentifizierungsdienstes. Das operative Team stuft den Vorfall als „reines Performance-Problem“ ein.
Was im Audit festgestellt wird
Der Dienst ist kritisch, da alle Kunden-Onboardings daran hängen
Mehrere Aufträge konnten nicht ausgeführt werden
Kundenbeschwerden gingen ein
Keine dokumentierten Bewertungsgrundlagen vorhanden
Eine Meldung an die Aufsicht erfolgte nicht
Warum es dazu kam
Keine definierte Incident-Klassifikationsmatrix
Kritikalität der Services nicht dokumentiert
Legal und Compliance nicht eingebunden
Entscheidung erfolgte intuitiv und ohne Dokumentation
Konsequenz
Die Aufsicht fordert nachträglich Erläuterungen und strukturelle Maßnahmen.
Kritikalität festlegen: Welche Services betreffen Kunden, regulatorische Pflichten oder Kernprozesse?
Incident-Kriterien definieren: Dauer, Verfügbarkeit, betroffene Prozesse, Auswirkungen.
Governance klar regeln: Wer bewertet? Wer entscheidet? Wer dokumentiert? Wer meldet?
Begründungen dokumentieren: Auch dann, wenn ein Vorfall nicht gemeldet wird.
Review durch ICT Risk Management: Regelmäßige Überprüfung auf Konsistenz.
Praxis-Impuls
DORA verlangt keine perfekte Bewertung, sondern nachvollziehbare Entscheidungen. Stellen Sie sicher, dass jeder Incident – gemeldeter und nichtgemeldeter – dokumentiert und begründet ist. Das ist der Beweis, den eine Aufsicht verlangt.