Incident-Management

Q: Was ist der Unterschied zwischen Incident- und Problem-Management?

Beim Incident-Management steht die schnelle Wiederherstellung eines gestörten Services im Vordergrund, damit der Geschäftsbetrieb weiterlaufen kann. Problem-Management nutzt anschließend die gewonnenen Erkenntnisse, um Ursachen wiederkehrender Störungen zu untersuchen und dauerhafte Lösungen abzuleiten.

Q: Was ist der Incident-Management-Prozess?

Der Incident-Management-Prozess führt von der Identifizierung eines Vorfalls über Kategorisierung, Priorisierung und Bearbeitung bis zum Abschluss. Die Information Technology Infrastructure Library (ITIL) liefert dafür einen bewährten Ansatz und unterstützt Unternehmen dabei, Servicequalität und Servicekontinuität systematisch zu steuern.

Incident-Management hilft Unternehmen, IT-Störungen strukturiert zu beherrschen und ihre Auswirkungen auf Nutzer, Services und Geschäftsprozesse klein zu halten. Der Artikel richtet sich an Verantwortliche aus IT, Service Management und Organisation und zeigt, wie Vorfälle priorisiert, eskaliert und bis zur Wiederherstellung sauber gesteuert werden.

Incident-Management – Auf einen Blick

Was ist Incident-Management?

Im Incident-Management werden ungeplante Störungen strukturiert bearbeitet, damit betroffene IT-Services möglichst schnell wieder verfügbar sind.

Wie läuft der Incident-Management-Prozess ab?

Von der Erfassung bis zum Abschluss durchläuft ein Incident mehrere feste Schritte, darunter Kategorisierung, Priorisierung, Bearbeitung und Wiederherstellung.

Wann wird ein Incident zum Major Incident?

Bei besonders hoher Auswirkung oder Dringlichkeit greifen verkürzte Eskalationswege und eine gebündelte Koordination.

Wer koordiniert kritische Incidents?

Für größere Vorfälle übernimmt häufig ein Incident-Manager die Abstimmung zwischen beteiligten Teams und Verantwortlichen im Informationssicherheitsmanagement.

Was versteht man unter Incident-Management?

Incident-Management organisiert den Umgang mit ungeplanten Störungen eines IT-Service und soll den normalen Servicebetrieb so schnell wie möglich wiederherstellen. Im Vordergrund steht zunächst eine funktionierende Lösung, bei Bedarf auch über einen Workaround.

Als Incident gilt nach ITIL beispielsweise eine ungeplante Unterbrechung oder eine spürbare Qualitätsminderung eines Service. Das kann vom ausgefallenen Benutzerkonto bis zum Stillstand einer zentralen Anwendung oder anderer Teile der IT-Infrastruktur reichen. Meldungen kommen über Nutzer, Monitoring-Systeme oder den Service-Desk und werden anschließend erfasst, bewertet und bearbeitet.

Im IT-Service-Management schafft Incident-Management dafür einen festen Ablauf. Jeder Vorfall erhält eine nachvollziehbare Dokumentation, eine Priorität und eine klare Zuständigkeit. So wissen IT-Teams, welcher Incident zuerst behandelt werden muss und wann weitere Support-Level oder ein Incident-Manager eingebunden werden.

Was gutes Incident-Management im Betrieb verbessert

Gut organisiertes Incident-Management verkürzt Ausfallzeiten und verhindert, dass kritische Störungen zwischen Service-Desk, IT-Teams und Fachabteilungen liegen bleiben. Gleichzeitig wird sichtbar, wer an einem Incident arbeitet, welche Tragweite besteht und wann mit einer Lösung zu rechnen ist.

Im Betrieb bringt das vor allem vier konkrete Vorteile:

Kürzere Ausfallzeiten: Kritische Incidents werden nach Auswirkung und Dringlichkeit priorisiert und bevorzugt bearbeitet.
Klare Verantwortung: Tickets werden gezielt dem passenden Team oder Level-Support zugewiesen, statt mehrfach weitergereicht zu werden.
Mehr Transparenz: Nutzer und Kunden erhalten einen nachvollziehbaren Status zur Bearbeitung und Wiederherstellung des betroffenen Service.
Messbare Servicequalität: Kennzahlen wie MTTR (Mean Time to Resolve) und die Einhaltung von Service Level Agreements zeigen, wo der Prozess funktioniert und wo Verbesserungen nötig sind. Eine sinkende MTTR erhöht zugleich die Verfügbarkeit der betroffenen Systeme und Services.

Wiederkehrende Incidents, häufige Workarounds oder auffällige Servicebereiche liefern konkrete Ansatzpunkte für das Problem-Management und die kontinuierliche Verbesserung der IT-Prozesse, etwa nach dem PDCA-Zyklus.

Schneller zurück zum Normalbetrieb

Bringen Sie Struktur in Störungen, Eskalationen und Verantwortlichkeiten. CSM Consulting unterstützt Sie dabei, Incident-Management so aufzusetzen, dass kritische Services schnell wieder verfügbar sind.

Der Incident-Management-Prozess

Ein klarer Incident-Management-Prozess führt Störungen strukturiert von der ersten Meldung bis zur Wiederherstellung des betroffenen Services. Dabei sorgen feste Zuständigkeiten, Prioritäten und Eskalationswege dafür, dass kritische Vorfälle schnell bearbeitet werden.

Incident erkennen und erfassen

Jeder Vorfall beginnt mit einer sauberen Erfassung. Für die Erfassung steht eine Vielzahl von Meldewegen zur Verfügung, etwa Nutzer, Monitoring-Systeme, Service-Desk oder Self-Service-Portal. Eine eindeutige Incident-ID und ein Zeitstempel schaffen später die nötige Nachvollziehbarkeit.

Im Ticket sollten mindestens folgende Informationen stehen:

betroffener Service oder betroffenes System
Zeitpunkt und kurze Beschreibung der Störung
meldende Person und Kontaktdaten
erkennbare Konsequenzen auf Nutzer oder Geschäftsprozesse
bereits durchgeführte Maßnahmen

Kategorisieren und priorisieren

Nach der Erfassung wird der Incident einer passenden Kategorie zugeordnet und bewertet. Kategorisierung hilft bei der schnellen Zuweisung zum richtigen Team, während die Priorisierung festlegt, wie schnell gehandelt werden muss.

In der Praxis werden dafür meist Auswirkung und Dringlichkeit kombiniert. Wie viele Prioritätsstufen ein Unternehmen verwendet und welche Reaktionszeiten daran hängen, wird individuell festgelegt. Mit wachsendem Reifegrad sollten Kategorien und Prioritätsregeln anhand realer Incidents regelmäßig angepasst werden.

Priorität	Auswirkung	Dringlichkeit	Beispiel
P1 – kritisch	hoch	hoch	Zentraler Service für viele Nutzer vollständig ausgefallen
P2 – hoch	hoch	mittel	Wichtiger Service stark beeinträchtigt
P3 – normal	mittel	mittel	Begrenzte Störung mit verfügbarem Workaround
P4 – niedrig	gering	gering	Einzelner Nutzer oder wenig kritische Funktion betroffen

First-Level-Support und weitere Support-Level

Der First-Level-Support ist häufig die erste Anlaufstelle für Incidents. Service-Desk-Mitarbeiter nehmen Meldungen auf, prüfen bekannte Lösungen und versuchen, den Service direkt wiederherzustellen. Reicht das vorhandene Wissen nicht aus, erfolgt die Weitergabe an weitere Support-Level:

First-Level-Support: Aufnahme, einfache Diagnose und bekannte Standardlösungen
Second-Level-Support: vertiefte technische Analyse durch spezialisierte IT- oder DevOps-Teams
Third-Level-Support: komplexe Fehlerbehebung durch Hersteller, Entwickler oder spezialisierte Experten

Incident bearbeiten und eskalieren

Bei der Bearbeitung zählt zunächst die schnellstmögliche Wiederherstellung des Service. Dafür kann eine dauerhafte Lösung eingesetzt werden, häufig reicht zunächst aber auch ein dokumentierter Workaround. Kann ein Team den Incident innerhalb der vorgesehenen Zeit nicht lösen, greift die Eskalation.

Fachlich komplexe Störungen werden an Spezialisten weitergegeben; bei hoher geschäftlicher Auswirkung können zusätzlich der Incident-Manager oder weitere Verantwortliche eingebunden werden. Bei einer darüber hinausgehenden Gefährdung kann zusätzlich das Notfallmanagement aktiviert werden.

Service wiederherstellen und Incident abschließen

Ein Incident wird erst geschlossen, wenn der betroffene Service wieder funktionsfähig ist und die Lösung dokumentiert wurde. Vor dem Abschluss sollte geprüft werden, ob Nutzer wieder arbeiten können und ob offene Folgeaufgaben bestehen.

Zum Abschluss gehören typischerweise:

Lösung oder verwendeten Workaround dokumentieren
Wiederherstellung bestätigen
betroffene Nutzer informieren
Bearbeitungszeit und SLA-Einhaltung festhalten
wiederkehrende oder ungeklärte Fälle an das Problem-Management übergeben

Major Incident Management bei kritischen Störungen

Major-Incidents sind besonders schwerwiegende Vorfälle mit erheblichen Beeinträchtigungen für das Unternehmen und entsprechend hohem Zeitdruck. Für ihre Bearbeitung greifen verkürzte Eskalationswege, feste Verantwortlichkeiten und eine engere Koordination zwischen den beteiligten Teams.

Der Incident-Manager hält dabei den Überblick und bindet bei sicherheitsrelevanten Vorfällen je nach Organisation auch den CISO ein.

Zu den Aufgaben eines Incident-Managers gehören insbesondere:

beteiligte Teams und Support-Level koordinieren
Prioritäten und nächste Maßnahmen abstimmen
regelmäßige Statusinformationen bereitstellen
Eskalationen an Verantwortliche auslösen
Fortschritt und Wiederherstellung dokumentieren

Entwickelt sich ein Major-Incident zu einer Situation, die mit den regulären IT-Strukturen kaum noch beherrschbar ist, kann zusätzlich das Notfallmanagement aktiviert werden. Bei länger anhaltenden Unterbrechungen greifen gegebenenfalls auch vorbereitete Strukturen aus dem Business-Continuity-Management, etwa auf Basis der ISO 22301.

Incident-, Problem- und Notfallmanagement im Zusammenspiel

Incident-, Problem- und Notfallmanagement setzen an unterschiedlichen Punkten einer Störung an. Gemeinsam sorgen die Prozesse dafür, dass Services schnell wieder verfügbar werden, Ursachen untersucht und schwerwiegende Situationen kontrolliert bewältigt werden.

Bereich	Schwerpunkt	Typisches Ziel
Incident Management	akute Störung bearbeiten	Service schnell wiederherstellen
Problem Management	Ursache wiederkehrender Incidents untersuchen	erneute Störungen vermeiden
Notfallmanagement	kritische Ausnahmesituation bewältigen	Schäden begrenzen und Handlungsfähigkeit sichern

Incident-Management arbeitet vor allem reaktiv und konzentriert sich auf die schnelle Problemlösung und Wiederherstellung des Service. Taucht dieselbe Störung wiederholt auf oder bleibt die eigentliche Ursache unklar, setzt das eher proaktiv ausgerichtete Problem-Management mit der tiefergehenden Analyse an.

Gefährdet ein Incident zentrale Geschäftsprozesse oder übersteigt die Lage die regulären Supportstrukturen, wird daraus gegebenenfalls ein Fall für das Notfallmanagement.

IT-Sicherheitsvorfälle und regulatorische Anforderungen nach NIS2 und DORA

Bei IT-Sicherheitsvorfällen reicht die technische Behebung allein häufig nicht aus. Abhängig von Branche und Schweregrad können zusätzlich Melde-, Dokumentations- und Eskalationspflichten aus NIS2 oder der DORA-Verordnung greifen.

Erhebliche Sicherheitsvorfälle müssen bewertet und innerhalb festgelegter Fristen gemeldet werden. Dafür braucht das Incident-Management einen klaren Übergang von der technischen Bearbeitung zur regulatorischen Bewertung und Kommunikation.

Im Finanzsektor stellt DORA zusätzliche Anforderungen an den Umgang mit schwerwiegenden IKT-bezogenen Incidents. Klassifizierung, Dokumentation und Meldung sind deshalb eng mit dem operativen Incident-Prozess verzahnt.

Hilfreich sind Schnittstellen zu einem bestehenden ISMS nach ISO 27001 und zur Informationssicherheit. Dort lassen sich Verantwortlichkeiten, Meldewege und Nachweise so verankern, dass bei einem kritischen Ereignis schnell feststeht, wer technische, organisatorische und regulatorische Aufgaben übernimmt.

Incident-Management im Unternehmen einführen

Als Teil des Informationssicherheitsmanagements funktioniert Incident-Management erst dann zuverlässig, wenn Prioritäten, Verantwortlichkeiten und Eskalationswege vor dem ersten kritischen Vorfall feststehen. Für die Einführung lohnt sich deshalb ein schlanker Prozess, der sich später mit wachsendem Reifegrad erweitern lässt.

Ein praktikabler Aufbau umfasst fünf Schritte:

Services und Zuständigkeiten festlegen: Kritische IT-Services beispielsweise über eine Schutzbedarfsanalyse bestimmen sowie Service Owner, Service Desk und zuständige Support-Level definieren. Für größere Incidents sollte zusätzlich klar sein, wann ein Incident-Manager übernimmt.
Kategorien und Prioritäten bestimmen: Wiederkehrende Störungen in verständliche Kategorien einteilen und eine Prioritätsmatrix aus potenziellem Schadensausmaß und der akuten Dringlichkeit festlegen. So landen kritische Incidents schneller beim richtigen Team.
Bearbeitung und Eskalation organisieren: Regeln für First-Level-Support, weitere Support-Level, Major Incidents und funktionale oder hierarchische Eskalationen festlegen.
ITSM-Tool einrichten: Ticketverwaltung, Status, SLA-Überwachung und Dokumentation sollten an einer Stelle zusammenlaufen. Ein Self-Service-Portal kann zusätzlich die Aufnahme einfacher Serviceanfragen und Störungen erleichtern.
Kennzahlen auswerten: MTTR, SLA-Einhaltung, wiederkehrende Incidents und Eskalationen zeigen, wo der Prozess funktioniert und wo Anpassungen nötig sind.

Häufige Fragen und Antworten

Was ist der Unterschied zwischen Incident- und Problem-Management?

Beim Incident-Management steht die schnelle Wiederherstellung eines gestörten Services im Vordergrund, damit der Geschäftsbetrieb weiterlaufen kann. Problem-Management nutzt anschließend die gewonnenen Erkenntnisse, um Ursachen wiederkehrender Störungen zu untersuchen und dauerhafte Lösungen abzuleiten.

Was ist der Incident-Management-Prozess?

Der Incident-Management-Prozess führt von der Identifizierung eines Vorfalls über Kategorisierung, Priorisierung und Bearbeitung bis zum Abschluss. Die Information Technology Infrastructure Library (ITIL) liefert dafür einen bewährten Ansatz und unterstützt Unternehmen dabei, Servicequalität und Servicekontinuität systematisch zu steuern.

Was sind die Aufgaben eines Incident-Managers?

Ein Incident-Manager koordiniert bei größeren Vorfällen die beteiligten Teams, überwacht Eskalationen und hält den Status für IT-Abteilung, Management und weitere Verantwortliche transparent. Ziel ist die schnelle Rückkehr zum Normalzustand und die Reduktion negativer Auswirkungen auf Nutzer und Geschäftsprozesse.