Was dieser Deep Dive Ihnen zeigt
Wie Incident Reporting unter DORA strukturiert ist, welche Schwellenwerte gelten, wie die Bewertungsentscheidung nachvollziehbar wird – und warum die meisten Meldeprozesse an der Klassifikation und Schwellenwertbestimmung 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? Und – das Kernproblem – wie wird die Entscheidung über die Meldepflicht bei Unsicherheit nachvollziehbar und dokumentiert? DORA adressiert diese Unsicherheiten mit einer klaren, mehrstufigen Logik, die nicht nur technische, sondern auch geschäftliche und regulatorische Dimensionen vereint.
1. Die DORA-Logik: Drei Ebenen der Einstufung
| Ebene | Definition | Konsequenz |
|---|
| Event/Alert (interne operative Vorstufe) | Technisches Ereignis ohne unmittelbare Auswirkungen auf Dienstleistung oder Sicherheit. Keine gesetzliche DORA-Kategorie, sondern interne Taxonomie. | Keine Meldepflicht, Dokumentation empfohlen |
| ICT-related Incident (Rechtskategorie) | Ereignis mit tatsächlichen Auswirkungen auf Verfügbarkeit, Integrität oder Vertraulichkeit | Interne Eskalation, Klassifikation, Prüfung Meldepflicht |
| Major ICT-related Incident (Meldekategorie) | ICT-related Incident, der die Materialitätsschwellen erreicht. Die verbindlichen Kriterien und Schwellen ergeben sich detailliert aus der Delegierten Verordnung (EU) 2024/1772 (RTS) — u. a. betroffene Kunden/Gegenparteien/Transaktionen, Reputation, Dauer/Ausfallzeit, geografische Ausbreitung, Datenverluste, Kritikalität der Dienste, wirtschaftliche Auswirkungen. | Meldung an Aufsicht in drei Stufen (DORA Art. 19 + RTS): Erstmeldung (initial notification), Zwischenbericht (intermediate report), Abschlussbericht (final report) |
2. Drei Ansätze zur Bewertung von Incidents
A) Rein juristische Bewertung (allein nicht ausreichend)
Fokus auf formale Meldepflichten nach Rechtstext
Entscheidung erst nach abschließender rechtlicher Bewertung
Hohe Zurückhaltung bei Unsicherheit
Einordnung
Eine ausschließlich juristische Betrachtung führt häufig dazu, dass Vorfälle zu spät oder gar nicht gemeldet werden, da die regulatorische und geschäftliche Bedeutung unterschätzt wird.
B) Rein technische Bewertung (riskant)
Orientierung an Logs, Alerts oder Systemmetriken
Fokus auf Dauer, Verfügbarkeit oder technische Störungen
Geringe Einbindung von Business- und Governance-Perspektiven
Einordnung
Technische Bewertungen erfassen oft nicht die regulatorische und geschäftliche Tragweite eines Vorfalls. Auch ein relativ kurzer Ausfall (z. B. rund 40 Minuten) kann bei hoher Kritikalität oder erheblichen Auswirkungen meldepflichtig sein — die Dauer allein entscheidet aber nicht; die RTS arbeiten mit einer Kombination aus Kriterien und Schwellen.
C) Integrierte Bewertung (DORA-orientierter Ansatz)
Eine belastbare Einstufung berücksichtigt mehrere Dimensionen gleichzeitig:
Auswirkungen auf kritische oder wesentliche Funktionen
Auswirkungen auf Kundinnen und Kunden
Auswirkungen auf Vertraulichkeit, Integrität oder Verfügbarkeit von Daten
Auswirkungen auf Resilienz und Wiederherstellbarkeit
Dauer und Zeitpunkt des Vorfalls
Wiederholungs- oder Eskalationsrisiken
Potenzielle systemische Effekte sowie Abhängigkeiten zu Drittdienstleistern
DORA verlangt eine nachvollziehbare Governance-Kette, nicht nur technische Reaktionen oder isolierte juristische Urteile.
3. Typische Fehler und Schwachstellen
Alles wird als Incident eingestuft → Inflationsrisiko und Blindheit gegenüber echten Major Incidents
Oder: Vorfälle werden systematisch heruntergestuft → Regulatorische Blindheit und Reputationsrisiken
Fehlende Bewertungsmatrix → Entscheidungen erfolgen ad-hoc, nicht nachvollziehbar
Technische Teams entscheiden allein ohne Governance-Einbindung → Geschäftliche und regulatorische Perspektiven fallen weg
Legal und Compliance werden zu spät einbezogen → Entscheidungen im operativen Stress, ohne angemessene Bewertung
Entscheidungen werden nicht dokumentiert → Im Audit oder bei der Aufsicht kann der Entscheidungsprozess nicht nachgewiesen werden
Reputationssorge und Aufsichtsangst beeinflussen die Einstufung → Vorfälle werden verheimlicht oder verspätet gemeldet
Vorfälle bei Drittdienstleistern werden nicht bewertet → Regulatorische Lücke bei wesentlichen Zulieferern
4. Warum frühere Vorgehensweisen nicht mehr ausreichen
Vor DORA genügte häufig: "Wir melden, wenn es schlimm wird" oder "Wir entscheiden situationsbezogen." 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.
Entscheidend ist dabei nicht, dass jede Einstufung objektiv "richtig" sein muss – die Zukunft ist unsicher. Entscheidend ist, dass die Abwägung nachvollziehbar ist, Kriterien angelegt wurden und der Prozess dokumentiert ist. Im Zweifelsfall ist eine frühe Meldung mit Korrektur das deutlich kleinere Risiko als eine verheimlichte Meldung.
5. Fallstudie: Der 40-Minuten-Vorfall
Ausgangslage
Ein Zahlungsdienstleister erlebt einen rund 40-minütigen Ausfall seiner Autorisierungs-API. Alle ausstehenden Zahlungstransaktionen können nicht verarbeitet werden. Das operative Team erkennt den Fehler schnell und behebt ihn.
Interne Bewertung
Das technische Team stuft den Vorfall als "moderat" ein: "Die Dauer war kurz, das System ist selbstheilend."
Legal erkennt keine unmittelbare Datenschutzverletzung.
Operations befürchtet negative Außenwirkung und mangelndes Vertrauen, wenn eine Meldung erfolgt.
Ergebnis: Es wird entschieden, den Vorfall nicht zu melden.
Was danach passiert
Ein großer Kunde macht den Ausfall öffentlich. Die Aufsicht wird aufmerksam und fordert eine Erklärung.
Retrospektive Analyse
Eine kritische Funktion war betroffen – Autorisierung ist kernsystem.
Die Dauer war weniger entscheidend als die Auswirkungen auf Marktteilnehmer.
Die Service-Level-Vereinbarungen mit Kunden wurden verletzt.
Die relevanten Schwellenwerte wären voraussichtlich erreicht gewesen.
Konsequenzen
Erhöhte aufsichtliche Aufmerksamkeit und geschärfte Überwachung
Reputationsschaden durch öffentliche Affäre größer als bei proaktiver Meldung
Interne Untersuchungen und Nachsteuerung der Prozesse
Beweis, dass die Entscheidungsfindung nicht nachvollziehbar war
6. Incident Reporting unter DORA: Der richtige Prozess
Kritikalität festlegen: Welche Services betreffen Kunden, regulatorische Pflichten oder Kernprozesse? Diese müssen dokumentiert sein.
Incident-Kriterien definieren: Dauer, Verfügbarkeit, betroffene Prozesse, Auswirkungen – kombiniert, nicht isoliert. Wann beginnt die Schwelle? Es geht nicht um Perfektion, sondern um Nachvollziehbarkeit.
Sofortige Eskalation bei Unsicherheit: Wenn technisch unklar ist, ob Schwellenwerte erreicht werden, muss sofort zur integrierten Bewertung eskaliert werden. Operative Teams sollten nicht allein entscheiden.
Dokumentierte Abwägung: Auch bei Nicht-Meldung wird festgehalten: Welche Kriterien wurden geprüft? Welche Daten flossen ein? Wer war beteiligt? Das ist der Nachweis im Audit.
Governance klar regeln: Wer bewertet? Wer entscheidet? Wer dokumentiert? Wer meldet? Klare Rollen und Verantwortlichkeiten.
Review durch ICT Risk Management: Regelmäßige Überprüfung auf Konsistenz und Qualität der Entscheidungsfindung.
Praxis-Impuls
Incident Thresholding ist einer der anspruchsvollsten Teile der DORA-Umsetzung – nicht weil die Regeln fehlen, sondern weil Bewertungen unter Unsicherheit getroffen werden müssen. DORA verlangt keine perfekte Bewertung, sondern nachvollziehbare Entscheidungen. Die Klassifikationsentscheidung und ihre wesentlichen Grundlagen sollten in einem Umfang dokumentiert werden, der der Schwere und Grenzwertnähe des Vorfalls entspricht. Das ist der Beweis, den eine Aufsicht verlangt. Im Zweifelsfall ist eine frühe Meldung mit Nachbesserung sicherer als ein verheimlichter Vorfall.
Was bleibt
1
Frühere ad-hoc-Entscheidungen ohne Dokumentation sind unter DORA nicht mehr ausreichend – klare, vordefinierte Schwellenwerte und nachvollziehbare Governance sind nun verbindlich.
2
Die kritische Abgrenzung erfolgt in Governance, nicht Technik: Welche Services sind kritikalitätsrelevant? Wer entscheidet, ab welcher Schwelle? Das muss dokumentiert sein – nicht improvisiert.
3
Incident Thresholding ist eine Bewertung unter Unsicherheit, keine technische Berechnung. Es erfordert eine integrierte Perspektive: Technik allein oder Jus allein führt zu fehlerhaften Entscheidungen.
4
Reputationssorge ist keine juristische Kategorie. Die Angst vor Außenwirkung darf nicht dazu führen, dass ein meldepflichtiger Vorfall verheimlich wird. Der Reputationsschaden der verheimlichten Meldung ist größer.
5
Entscheidungen müssen auch bei Nicht-Meldung dokumentiert sein. Das ist die beste Verteidigungslinie in einem Audit. Unsicherheit ist normal – mangelnde Nachvollziehbarkeit ist ein Audit-Finding.