ISMS · Incident Management
Incident Management: Sicherheitsvorfälle erkennen, behandeln und melden
Lesezeit etwa 7 Minuten · Stand Oktober 2026
Incident Management in der Informationssicherheit ist der geregelte Umgang mit Sicherheitsvorfällen: erkennen, bewerten, eindämmen, beheben und aus dem Vorfall lernen. Es sorgt dafür, dass ein Angriff oder eine Panne schnell bemerkt und beherrscht wird und dass gesetzliche Meldefristen eingehalten werden. Die ISO/IEC 27001 regelt es in den Controls A.5.24 bis A.5.28.
Nicht der Vorfall entscheidet über den Schaden,
sondern wie schnell und geordnet die Reaktion erfolgt.
Was ist Incident Management in der Informationssicherheit?
Incident Management ist der Prozess, der Sicherheitsvorfälle von der Erkennung bis zur Nachbereitung steuert. Ein Sicherheitsvorfall ist jedes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen tatsächlich gefährdet, etwa ein Ransomware-Befall, ein Datenabfluss oder ein übernommenes Benutzerkonto. Ziel ist, den Schaden zu begrenzen und den Normalbetrieb geordnet wiederherzustellen.
Der Prozess ist fester Bestandteil eines gelebten Informationssicherheits-Managementsystems. Die ISO/IEC 27001 verlangt in den Controls A.5.24 bis A.5.28 eine geplante Vorfallbehandlung mit klaren Zuständigkeiten, einer Bewertung und Reaktion sowie dem Lernen aus Vorfällen. Ohne diesen Rahmen bleibt die Reaktion auf einen Angriff Zufall und hängt davon ab, wer gerade im Haus ist.
Wie läuft der Vorfallprozess in 4 Phasen ab?
Der Vorfallprozess durchläuft 4 Phasen, die ineinandergreifen: Erkennung, Klassifizierung, Reaktion und Nachbereitung. Jede Phase hat ein klares Ziel und übergibt definierte Informationen an die nächste. Eine Meldung aus der Belegschaft oder ein Alarm aus einem System startet den Ablauf, ein Abschlussbericht mit den gelernten Lektionen beendet ihn.
| Phase | Ziel | Kernaktivität |
|---|---|---|
| Erkennung | Vorfall bemerken und erfassen | Meldewege, Monitoring, zentrale Annahmestelle |
| Klassifizierung | Schwere und Dringlichkeit einstufen | Kategorie, Priorität, mögliche Meldepflicht prüfen |
| Reaktion | Schaden eindämmen und beheben | Sofortmaßnahmen, Beseitigung, Wiederherstellung |
| Nachbereitung | aus dem Vorfall lernen | Ursachenanalyse, Maßnahmen, Dokumentation |
Die vierte Phase wird am häufigsten vernachlässigt und ist doch die wertvollste. In der Nachbereitung werden Ursachen analysiert und daraus Verbesserungen abgeleitet, die über das Maßnahmenmanagement im ISMS nachverfolgt werden. So schließt sich der Regelkreis und derselbe Vorfall wiederholt sich nicht aus denselben Gründen.
Welche Meldefristen gelten nach NIS2?
Unternehmen, die unter die NIS2-Richtlinie fallen, müssen erhebliche Sicherheitsvorfälle in einem dreistufigen Verfahren melden. Die Richtlinie (EU) 2022/2555 schreibt in Artikel 23 eine Frühwarnung binnen 24 Stunden, eine ausführliche Meldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats vor. In Deutschland setzt das BSI-Gesetz diese Fristen um, zentrale Meldestelle ist das BSI.
| Stufe | Frist | Inhalt |
|---|---|---|
| Frühwarnung | binnen 24 Stunden | erster Hinweis, Verdacht auf eine rechtswidrige Ursache |
| Meldung | binnen 72 Stunden | Bewertung, Schweregrad, erste Erkenntnisse |
| Abschlussbericht | binnen 1 Monat | Ursachen, ergriffene Maßnahmen, Auswirkungen |
Meldepflichtig ist ein Vorfall, wenn er schwere Betriebsstörungen oder finanzielle Verluste verursacht oder andere Personen durch erhebliche Schäden beeinträchtigen kann. Ob ein Unternehmen überhaupt betroffen ist, klärt der Ratgeber zur NIS2-Betroffenheit, die konkreten Pflichten ordnet der Beitrag zu den NIS2-Maßnahmen nach § 30 BSIG ein. Das interne Incident Management ist die Voraussetzung dafür, diese Fristen überhaupt halten zu können.
Hält Ihr Vorfallprozess einer echten Meldefrist stand?
Im Strategiegespräch prüfen wir Ihren Incident-Management-Prozess, benennen Lücken bei Meldewegen und Rollen und zeigen, wie Sie die Fristen nach NIS2 im Ernstfall sicher einhalten.
Welche Rollen braucht die Vorfallbehandlung?
Eine geordnete Reaktion braucht vorher benannte Rollen, nicht erst im Ernstfall gesuchte Zuständigkeiten. Im Kern sind das eine zentrale Annahme- und Koordinationsstelle, ein Entscheider mit Mandat, fachliche Bearbeiter aus IT und Betrieb sowie Schnittstellen zu Kommunikation, Datenschutz und Geschäftsleitung. Wer welche Entscheidung treffen darf, muss vor dem ersten Vorfall feststehen.
Die fachliche Koordination liegt meist beim Informationssicherheitsbeauftragten, der den Prozess steuert und die Leitung informiert. Bei schweren Vorfällen entscheidet die Geschäftsleitung über Eskalation, externe Unterstützung und Meldungen. Klar verteilte Rollen verhindern, dass im Stress Doppelarbeit entsteht oder ein wichtiger Schritt wie eine fristgerechte Meldung liegen bleibt.
Welche Kennzahlen machen Incident Management messbar?
2 Kennzahlen zeigen, wie gut die Vorfallbehandlung funktioniert: die mittlere Zeit bis zur Erkennung (MTTD) und die mittlere Zeit bis zur Behebung (MTTR). Je kürzer beide sind, desto geringer ist in der Regel der Schaden. Ergänzend zählen die Zahl der Vorfälle je Kategorie, die Melderate aus der Belegschaft und die Quote fristgerecht abgeschlossener Meldungen.
| Kennzahl | Bedeutung | Aussage |
|---|---|---|
| MTTD | mittlere Zeit bis zur Erkennung | wie schnell Vorfälle auffallen |
| MTTR | mittlere Zeit bis zur Behebung | wie schnell der Normalbetrieb zurückkehrt |
| Melderate | Anteil gemeldeter Auffälligkeiten | wie wach die Organisation ist |
Diese Werte gehören in das Berichtswesen an die Leitung und in die Managementbewertung. Wie sich Sicherheitskennzahlen für die Geschäftsführung sinnvoll auswählen und darstellen lassen, zeigt der Ratgeber zu den ISMS-Kennzahlen. Kennzahlen sind dabei kein Selbstzweck, sondern sie machen Fortschritt sichtbar und decken auf, wo der Prozess noch hakt.
Welche Fehler bremsen die Vorfallbehandlung?
Die häufigsten Schwächen sind organisatorisch. Vorfälle werden zu spät erkannt, Meldewege sind unklar, Zuständigkeiten ungeregelt und die Nachbereitung fällt aus. Oft fehlt eine zentrale Stelle, an der alle Informationen zusammenlaufen, sodass niemand den Gesamtüberblick hat und Fristen unbemerkt verstreichen.
- Keine zentrale Annahmestelle, Meldungen versanden in einzelnen Postfächern.
- Keine Klassifizierung, deshalb bleibt unklar, ob eine Meldepflicht besteht.
- Reaktion ohne Plan, Entscheidungen werden im Stress improvisiert.
- Keine Nachbereitung, dieselbe Ursache führt erneut zum Vorfall.
- Vorfälle und Maßnahmen werden getrennt geführt, der Nachweis fehlt im Audit.
Ein zentrales Werkzeug nimmt diesen Fehlern den Boden. In VANTARIS laufen Vorfälle an einer Stelle zusammen, werden klassifiziert, mit Maßnahmen und Controls verknüpft und speisen die Kennzahlen für die Leitung. So entsteht aus der Reaktion auf einen Vorfall ein nachvollziehbarer Vorgang statt einer Sammlung von Mails. Der Nachweis für Audit und Meldepflicht liegt vor, wenn er gebraucht wird.
Vorfälle, Maßnahmen und Nachweise an einer Stelle
In VANTARIS laufen Sicherheitsvorfälle zusammen, werden klassifiziert und mit Maßnahmen verknüpft. Die Demo zeigt, wie Kennzahlen und der Nachweis für die Meldepflicht nebenbei entstehen.
Häufige Fragen zum Incident Management
Was ist der Unterschied zwischen einem Ereignis und einem Sicherheitsvorfall?
Ein Ereignis ist jede beobachtbare Auffälligkeit in einem System, etwa ein fehlgeschlagener Login. Ein Sicherheitsvorfall ist ein Ereignis oder eine Reihe von Ereignissen, die die Informationssicherheit tatsächlich gefährden. Nicht jedes Ereignis ist ein Vorfall, aber jeder Vorfall beginnt als Ereignis, das richtig eingeordnet werden muss.
Welche Meldefristen gelten für Sicherheitsvorfälle nach NIS2?
Die NIS2-Richtlinie verlangt ein dreistufiges Verfahren: eine Frühwarnung binnen 24 Stunden, eine ausführliche Meldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats. Die Fristen laufen ab dem Zeitpunkt, zu dem das Unternehmen Kenntnis von dem erheblichen Vorfall erlangt. In Deutschland ist das BSI die zuständige Meldestelle.
Wann ist ein Sicherheitsvorfall meldepflichtig?
Meldepflichtig sind erhebliche Vorfälle. Als erheblich gilt ein Vorfall, der schwere Betriebsstörungen oder finanzielle Verluste auslöst oder der anderen durch erhebliche materielle oder immaterielle Schäden schaden kann. Die genaue Schwelle hängt von Sektor und Einstufung ab. Die Kriterien sollten vorab feststehen, damit im Ernstfall schnell entschieden werden kann.
Was ist der Unterschied zwischen Incident Management und Business Continuity?
Incident Management behandelt den einzelnen Sicherheitsvorfall von der Erkennung bis zur Behebung. Business Continuity setzt eine Stufe höher an und sorgt dafür, dass kritische Geschäftsprozesse auch bei einem großflächigen Ausfall weiterlaufen oder schnell wieder anlaufen. Ein schwerer Vorfall kann den Notfall auslösen, dann greifen beide Prozesse ineinander.
Was bedeuten MTTD und MTTR?
MTTD steht für die mittlere Zeit bis zur Erkennung eines Vorfalls, MTTR für die mittlere Zeit bis zu seiner Behebung. Beide Kennzahlen messen die Reaktionsfähigkeit der Organisation. Kurze Zeiten senken in der Regel den Schaden, weil Angreifer weniger lange unentdeckt bleiben und der Normalbetrieb schneller zurückkehrt.
Braucht ein kleines Unternehmen einen Incident-Management-Prozess?
Ja, in angemessenem Umfang. Auch ein kleines Unternehmen braucht klare Meldewege, eine koordinierende Person und eine einfache Einstufung der Schwere. Der Prozess muss nicht umfangreich sein, aber er muss vor dem ersten Vorfall feststehen. Im Ernstfall entscheidet die Vorbereitung darüber, ob eine Meldefrist gehalten wird.
Fakten und Quellen auf einen Blick
- Incident Management steuert Sicherheitsvorfälle in 4 Phasen: Erkennung, Klassifizierung, Reaktion und Nachbereitung.
- Normbezug: ISO/IEC 27001, Controls A.5.24 bis A.5.28 (Management von Informationssicherheitsvorfällen).
- NIS2-Meldefristen nach Artikel 23: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats.
- Zentrale Kennzahlen: MTTD (mittlere Zeit bis zur Erkennung) und MTTR (mittlere Zeit bis zur Behebung).
- Quellen: Richtlinie (EU) 2022/2555; ISO/IEC 27001; BSI; Stand Oktober 2026.
