Vorlagen und Aufzeichnungen · ISO 20000 · Abschnitt 8.6.1

IT-Incident-Protokoll nach ISO 20000-1

Jede ungeplante Unterbrechung eines Service oder Minderung seiner Qualität, von der Erkennung bis zum Abschluss, mit besonderer Behandlung für schwerwiegende Fälle.

In einem Satz

Das Incident-Protokoll erfasst jede Unterbrechung oder Verschlechterung eines Service mit Klassifizierung, Priorität nach Auswirkung und Dringlichkeit, Eskalation, ergriffenen Maßnahmen, Lösung und Abschluss und behandelt schwerwiegende Incidents mit einem dokumentierten Verfahren, zugewiesenem Verantwortlichen, Information der Leitung und anschließendem Bericht, denn Abschnitt 8.6.1 der ISO/IEC 20000-1 verlangt, jeden Incident aufzuzeichnen, zu klassifizieren, zu priorisieren, zu eskalieren, zu lösen und abzuschließen.

Inhalt überprüft am 17. Oktober 2026

Wo die Norm es verlangt: ISO 20000 · Abschnitt 8.6.1 Die Abschnitte werden nach der Nummerierung der gültigen Ausgabe ISO/IEC 20000-1:2018 zitiert, die auch die Akademie verwendet.
Art der Information: Pflichtaufzeichnung Aufzeichnung jedes Incidents und der ergriffenen Maßnahmen (8.6.1)
Wer sie ausfüllt: Service Desk Die Supportgruppen lösen; der Major-Incident-Manager koordiniert, wo zutreffend
Wann: Sobald er erkannt oder gemeldet wird Einschließlich der vom Monitoring erkannten, bevor der Kunde sie bemerkt
Wie lange sie aufbewahrt wird: Legt die Organisation fest Die Norm verlangt, Aufbewahrung und Verfügung über den Verbleib dokumentierter Information zu lenken (7.5.3), ohne Fristen zu nennen. Üblich ist, mindestens den dreijährigen Zertifizierungszyklus abzudecken oder die Vertragslaufzeit mit dem Kunden, wenn sie länger ist.

Was die Norm verlangt

Was ISO 20000 fordert und was Ihrem Ermessen überlassen bleibt

Incidents werden aufgezeichnet und klassifiziert, unter Berücksichtigung von Auswirkung und Dringlichkeit priorisiert, bei Bedarf eskaliert, gelöst und abgeschlossen. Die Aufzeichnung wird mit den ergriffenen Maßnahmen aktualisiert.

Die Organisation legt fest, was ein schwerwiegender Incident ist. Diese werden nach einem dokumentierten Verfahren behandelt: Die oberste Leitung wird informiert, eine verantwortliche Person wird benannt, und nach der Lösung werden ein Bericht erstellt und Verbesserungsmöglichkeiten geprüft.

Die Norm trennt Incidents von Serviceanfragen (8.6.2): Die Anlage eines Benutzers ist kein Incident und darf nicht in dessen SLA einfließen.

Im Zusammenhang lesen: Serviceerbringung und Support, in der Akademie zu ISO 20000

Aufbau

Felder, die die Vorlage enthalten sollte

Nummer, Datum und Uhrzeit der Erfassung
Herkunft: Anwender, Monitoring, Lieferant
Betroffener Service und betroffenes Konfigurationselement
Beschreibung und Symptome
Kategorie
Auswirkung, Dringlichkeit und resultierende Priorität
Zugewiesene Gruppe und Eskalationen
Ergriffene Maßnahmen und Mitteilungen an den Anwender
Lösung, vermutete Ursache und Verknüpfung mit einem Problem
Lösungszeit, Bestätigung durch den Anwender und Abschluss
Falls schwerwiegend: Verantwortlicher, Information der Leitung und anschließender Bericht

Beispiel

Beispiel: schwerwiegender Incident durch E-Mail-Ausfall

Unternehmen, Personen und Zahlen sind erfunden: Das Beispiel zeigt nur, wie eine sauber ausgefüllte Aufzeichnung aussieht.

Feld	Inhalt
Nummer	INC-26-0318 · 14. April 2026, 09:02 · Monitoring-Alarm
Service	SRV-04 E-Mail und Zusammenarbeit · Element CI-MAIL-01
Symptome	Mail-Clients verbinden sich nicht: Zertifikatsfehler
Priorität	Auswirkung hoch (alle Anwender) · Dringlichkeit hoch · P1 · schwerwiegend
Verantwortlich	Major-Incident-Manager · Information der Leitung um 09:10
Lösung	Erneuerung des Zertifikats um 10:20 · Service wiederhergestellt
Dauer	78 Minuten · innerhalb des P1-Ziels, beeinträchtigt aber die monatliche Verfügbarkeit
Bericht	Major-Incident-Bericht vom 16. April · Problem PRB-26-021 eröffnet

Im Audit

Fehler, die Auditoren häufig feststellen

Serviceanfragen und Rückfragen als Incidents erfasst, was die Kennzahlen verzerrt.
Priorität nach dem Anrufer statt nach Auswirkung und Dringlichkeit vergeben.
Incidents ohne Bestätigung des Anwenders geschlossen.
Schwerwiegende Incidents ohne anschließenden Bericht und ohne Prüfung von Verbesserungen.
Wiederkehrende Incidents werden nicht mit einem Problem verknüpft.

In Kimobox

So wird diese Aufzeichnung in Kimobox geführt

1Jeder Incident wird mit Priorität und Lösungszeit erfasst.
2Wiederkehrende Incidents werden mit einer Problemaufzeichnung samt Grundursachenanalyse verknüpft.
3Serviceanfragen werden über das Kunden- oder Mitarbeiterportal bearbeitet.
4Die SLA-Erfüllung ist im Dashboard sichtbar.

Häufige Fragen

Was man uns vor dem Start fragt

Was ist der Unterschied zwischen Incident und Serviceanfrage?

Der Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung des Service; die Serviceanfrage ist ein Wunsch nach etwas, das der Service bereits vorsieht, etwa die Anlage eines Benutzers oder ein Passwortwechsel. ISO/IEC 20000-1 behandelt sie in getrennten Abschnitten.

Wer entscheidet, was ein schwerwiegender Incident ist?

Die Organisation, mit dokumentierten Kriterien – etwa Anzahl betroffener Anwender oder ausgefallene kritische Services – und oft in Abstimmung mit dem Kunden.

Führen Sie die Aufzeichnungen zu ISO 20000 ohne verstreute Vorlagen

Wir zeigen Ihnen das Modul im Einsatz, mit Daten, die Ihren ähneln.

Demo anfragen

Weiter entdecken