Was ist Incident Management?
Incident Management nimmt Störungen von IT-Diensten an, bewertet sie und behebt sie, bis der Dienst wieder so läuft wie vereinbart. Ein Incident ist jede ungeplante Unterbrechung oder spürbare Qualitätsminderung eines Dienstes: der ausgefallene Mailserver ebenso wie eine Anwendung, die seit dem Morgen deutlich langsamer antwortet. Was als normaler Betrieb gilt, legt das Service Level Agreement (SLA) fest, sofern eines vereinbart ist.
Im IT-Service-Management beschreibt das Rahmenwerk ITIL die Disziplin; ITIL 4 führt Incident Management als eine seiner Management Practices. Im Deutschen heißt die Disziplin auch Störungsmanagement oder Vorfallmanagement.
Incident, Problem, Service Request und Sicherheitsvorfall
Die Abgrenzung entscheidet, wer zuständig ist und ob eine gesetzliche Frist läuft.
| Begriff | Was es ist | Ziel | Beispiel |
|---|---|---|---|
| Incident | ungeplante Unterbrechung oder Qualitätsminderung eines Dienstes | Dienst schnell wiederherstellen | VPN-Gateway nicht erreichbar |
| Problem | Ursache eines oder mehrerer Incidents | Ursache finden und beseitigen | fehlerhaftes Firmware-Update am Gateway |
| Service Request | geplante Anfrage ohne Störung | Leistung im vereinbarten Rahmen erbringen | neuer VPN-Zugang für eine Mitarbeiterin |
| Sicherheitsvorfall | Beeinträchtigung von Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen | Schaden begrenzen, Beweise sichern, Meldepflichten prüfen | Anmeldung mit gestohlenen Zugangsdaten am Gateway |
Ein Sicherheitsvorfall, der einen Dienst beeinträchtigt, ist zugleich ein Incident. Umgekehrt gilt das nicht: Ob der Ausfall einer defekten Festplatte auch als Sicherheitsvorfall zählt, hängt von Ihrer festgelegten Einstufung ab. Die sicherheitsspezifische Behandlung beschreibt der Eintrag Incident Response.
Der Prozess in acht Schritten
- Erkennen und melden: Nutzer, Service Desk oder Monitoring melden die Störung.
- Erfassen: Ein Ticket hält Zeitpunkt, betroffenen Dienst, Symptome und meldende Person fest.
- Kategorisieren: Dienst, Komponente und Art der Störung zuordnen und den Sicherheitsbezug prüfen.
- Priorisieren: Die Priorität ergibt sich aus Auswirkung (wie viele Nutzer, welcher Geschäftsprozess) und Dringlichkeit (wie schnell der Schaden wächst).
- Diagnostizieren: Der 1st Level analysiert und gleicht mit bekannten Fehlern und Workarounds ab.
- Eskalieren: funktional an den 2nd oder 3rd Level, hierarchisch an Incident Manager oder Leitung, wenn Frist oder Auswirkung es verlangen.
- Lösen und wiederherstellen: Der Dienst läuft wieder, notfalls per Workaround, und die meldende Person bestätigt es.
- Abschließen und auswerten: Lösung dokumentieren und bei wiederkehrenden oder schweren Störungen ein Problem anlegen.
Für Störungen, die das Standardverfahren übersteigen, legen Sie vorab ein Verfahren für Major Incidents fest, mit eigener Leitung und verpflichtender Nachbetrachtung.
Die Sicherheitsprüfung in Schritt 3
Gesetzliche Meldefristen laufen ab Kenntnis des Vorfalls, nicht ab dem Schließen des Tickets. Schritt 3 braucht deshalb feste Prüffragen. Ist eine erfüllt, läuft neben dem Ticket eine eigene Bewertung mit eigener Uhr.
| Prüffrage bei der Kategorisierung | Wenn ja | Frist |
|---|---|---|
| Sind Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen beeinträchtigt, etwa durch fremde Anmeldung, Schadsoftware oder Datenabfluss? | Sicherheitsvorfall: Incident Response starten, Informationssicherheitsbeauftragten einbeziehen | nach eigener Vorgabe |
| Sind personenbezogene Daten betroffen? | Prüfung als Datenpanne nach Art. 33 DSGVO | unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden |
| Ist die Organisation eine besonders wichtige oder wichtige Einrichtung, und kann der Vorfall erheblich sein? | Prüfung nach § 32 BSIG | frühe Erstmeldung unverzüglich, spätestens 24 Stunden nach Kenntniserlangung; Meldung unverzüglich, spätestens nach 72 Stunden |
| Ist die Organisation ein Finanzunternehmen nach DORA? | Klassifizierung nach Art. 18 DORA statt § 32 BSIG (§ 28 Abs. 6 Nr. 1 BSIG) | bei Einstufung als schwerwiegend: Erstmeldung binnen 4 Stunden danach, spätestens 24 Stunden nach Kenntnis |
Die DORA-Fristen stehen in Art. 5 der Delegierten Verordnung (EU) 2025/301. Wird ein Vorfall erst nach 24 Stunden als schwerwiegend eingestuft, gilt die Vier-Stunden-Frist ab der Einstufung (Art. 5 Abs. 2). Auch für Betreiber öffentlicher Telekommunikationsnetze, Anbieter öffentlich zugänglicher Telekommunikationsdienste und Energieunternehmen, die den §§ 5c bis 5e EnWG unterliegen, gilt § 32 BSIG nach § 28 Abs. 5 BSIG grundsätzlich nicht.
Beispiel (fiktiv): Das VPN-Gateway fällt um 8:10 Uhr aus. Nach einem Neustart läuft es wieder, und das Ticket wird um 9:30 Uhr geschlossen. Bei der Auswertung am nächsten Tag zeigt das Anmeldeprotokoll eine Anmeldung mit gestohlenen Zugangsdaten kurz vor dem Ausfall. Hätte Schritt 3 das Protokoll geprüft, wäre die Bewertung als Sicherheitsvorfall noch am Morgen angelaufen.
Halten Sie im Ticket fest, wer die Prüffragen wann beantwortet hat.
Rollen: Service Desk, Support-Level, Incident Manager
| Rolle | Aufgabe |
|---|---|
| Service Desk (1st Level) | nimmt Meldungen an, erfasst, kategorisiert, löst Standardfälle |
| 2nd Level Support | Fachteams für Netzwerk, Anwendungen oder Arbeitsplatz; tiefere Diagnose |
| 3rd Level Support | Entwicklung, Hersteller, externe Dienstleister |
| Incident Manager | verantwortet Prozess, Priorisierung, Eskalation und Kennzahlen |
| Major-Incident-Team | leitet schwere Störungen und koordiniert Technik, Kommunikation und Geschäftsleitung |
| Informationssicherheitsbeauftragter | bewertet bei Sicherheitsbezug, ob ein Sicherheitsvorfall vorliegt |
Welche Kennzahlen gibt es?
| Kennzahl | Was sie misst |
|---|---|
| MTTA (Mean Time to Acknowledge) | Zeit von der Meldung bis zur Annahme durch eine zuständige Person |
| MTTD (Mean Time to Detect) | Zeit vom Eintritt einer Störung bis zu ihrer Erkennung |
| MTTR (Mean Time to Resolve oder Restore) | Zeit bis zur Wiederherstellung; die Abkürzung wird unterschiedlich aufgelöst, nennen Sie die Definition im Bericht |
| Erstlösungsquote | Anteil der Incidents, die der 1st Level ohne Weitergabe löst |
| SLA-Erfüllung | Anteil der Incidents innerhalb der vereinbarten Reaktions- und Lösungszeiten |
| Wiedereröffnungsquote | Anteil geschlossener Tickets, die erneut geöffnet werden |
Zielwerte leiten Sie aus SLAs und der Kritikalität des Dienstes ab. Wie Kennzahlen für die Geschäftsleitung aufbereitet werden, beschreibt der Eintrag Sicherheitskennzahlen (KPI).
Was ISO 27001, BSIG und DORA verlangen
Keines dieser Regelwerke schreibt einen ITIL-Prozess vor. Sie verlangen einen geregelten Umgang mit Sicherheitsvorfällen, der auf dem bestehenden Incident-Prozess aufsetzen kann.
| Regelwerk | Fundstelle | Kern der Anforderung |
|---|---|---|
| ISO/IEC 27001:2022 | Anhang A 5.24 bis 5.28 und 6.8 | Vorfallbehandlung planen, Ereignisse bewerten, reagieren, aus Vorfällen lernen, Beweise sichern; Beschäftigte melden Ereignisse über festgelegte Wege |
| BSIG | § 30 Abs. 2 Satz 2 Nr. 2 BSIG | Bewältigung von Sicherheitsvorfällen als Risikomanagementmaßnahme |
| DORA | Art. 17 der Verordnung (EU) 2022/2554 | Prozess, um IKT-bezogene Vorfälle zu erkennen, zu behandeln und zu melden; alle Vorfälle erfassen; Ursachen ermitteln, dokumentieren und angehen |
| BSI IT-Grundschutz | Baustein DER.2.1 „Behandlung von Sicherheitsvorfällen“ im IT-Grundschutz-Kompendium (Edition 2023) | Behandlung von Sicherheitsvorfällen |
Wie Vorfallbehandlung, Meldewege und Nachbetrachtung in ein ISMS eingebettet werden, beschreibt der Ratgeber ISMS einführen.
Incident-Management in Rizzqo
Ist ein System von einem Vorfall betroffen, etwa ein VPN-Gateway, zeigt Rizzqo, welche Prozesse davon abhängen, ob es personenbezogene Daten enthält und wer dafür verantwortlich ist. Die Maßnahmen aus der Nachbereitung erfassen Sie als Aufgaben, die sich in beide Richtungen mit Jira synchronisieren, und sehen, wie stark jede das Risiko senkt.