Incident Management
Incident Management ist die Praxis im IT-Service-Management, die ungeplante Unterbrechungen oder Qualitätsminderungen eines Services erfasst, priorisiert und möglichst schnell behebt. Ziel ist, den normalen Betrieb wiederherzustellen und die Auswirkungen für Nutzende gering zu halten, nicht die Ursache dauerhaft zu beseitigen.
Was dahinter steckt
ITIL 4 definiert einen Incident als ungeplante Unterbrechung eines Services oder Minderung seiner Qualität. Ein Incident darf auch erfasst werden, bevor ein SLA-Wert verletzt ist, um die Auswirkungen zu begrenzen. Der Ablauf folgt meist diesen Schritten:
- Erkennen und erfassen, durch Meldung oder Überwachung
- Kategorisieren und priorisieren
- Diagnose, Lösung im First Level oder Eskalation
- Behebung und Wiederherstellung des Betriebs
- Abschluss mit Rückmeldung an die meldende Person
Die Priorität ergibt sich aus Auswirkung (wie viele Nutzende oder Prozesse betroffen sind) und Dringlichkeit (wie schnell es gelöst sein muss). Eine verbreitete Matrix mit fünf Stufen:
| Auswirkung | Dringlichkeit hoch | Dringlichkeit mittel | Dringlichkeit niedrig |
|---|---|---|---|
| hoch | 1 | 2 | 3 |
| mittel | 2 | 3 | 4 |
| niedrig | 3 | 4 | 5 |
Abzugrenzen ist das Problem Management: Es sucht die Ursache wiederkehrender Incidents und beseitigt sie dauerhaft.
Sicherheitsvorfälle wie Angriffe, Schadsoftware oder Datenabfluss laufen oft als eigener Prozess (Security Incident Management) mit Beweissicherung. Sie können Meldepflichten auslösen. Datenschutzverletzungen sind nach der DSGVO möglichst binnen 72 Stunden der Aufsichtsbehörde zu melden. Einrichtungen unter NIS2 melden erhebliche Vorfälle in Deutschland binnen 24 Stunden vorab und binnen 72 Stunden ausführlich an das BSI.
Warum das für IT-Dienstleister wichtig ist
Bei Störungen spüren Kunden die Qualität eines IT-Dienstleisters am stärksten. Eine klare Priorisierung sorgt dafür, dass der Ausfall der Warenwirtschaft vor dem defekten Drucker bearbeitet wird und die SLA-Fristen halten.
Dazu gehört verlässliche Kommunikation: Wer eine Störung meldet, will wissen, dass sie bearbeitet wird und wann mit einer Lösung zu rechnen ist. Gemessen wird das Incident Management meist an der mittleren Zeit bis zur Wiederherstellung (MTTR) und am Anteil der Incidents, die innerhalb der SLA-Fristen gelöst werden.
Kaufmännisch ist wichtig, wer den Aufwand trägt: Behebung im Rahmen der Pauschale, Abrechnung nach Aufwand oder Kulanz, wenn der Fehler beim Dienstleister selbst lag.
Beispiel
Ein Managed Service Provider bearbeitet im Monat 240 Incidents mit durchschnittlich 50 Minuten Aufwand, zusammen 200 Stunden. Die Auswertung zeigt: 60 davon gehen auf denselben fehlerhaften Druckertreiber zurück, das sind 50 Stunden. Die Ursache zu beseitigen kostet einmalig 12 Stunden im Problem Management. Schon im ersten Monat bleiben 38 Stunden frei, ab dem zweiten Monat 50 Stunden.
So unterstützt timo365
Liegt die Ursache einer Störung beim Dienstleister selbst, setzt die Projektleitung die Zeiten im Projektleiter-Cockpit von timo365 ERP auf Kulanz: Sie erscheinen auf dem Leistungsnachweis, werden aber mit 100 % Rabatt nicht berechnet. Bei Stundenkontingenten entscheidet die Projektleitung je Zeile, ob die Zeit vom Kontingent abgeht.
Verwandte Begriffe
Häufige Fragen
Was ist der Unterschied zwischen Incident und Problem?
Ein Incident ist die einzelne Störung, die möglichst schnell behoben werden soll, notfalls mit einer Übergangslösung. Ein Problem ist die Ursache hinter einem oder mehreren Incidents. Das Problem Management analysiert sie und beseitigt sie dauerhaft, damit die Störung nicht wiederkehrt.
Wann gilt eine Störung als Priorität 1?
Das legt jeder Vertrag selbst fest. Üblich ist Priorität 1, wenn ein geschäftskritischer Service für viele Nutzende ausfällt und es keine Umgehung gibt, etwa beim kompletten Ausfall von E-Mail oder ERP-System. Für diese Stufe gelten die kürzesten Reaktions- und Lösungszeiten.
Stand: 05.11.2026