Incident-Schweregrad einstufen: Entscheidungsbaum P1 bis P4
Entscheidungsbaum zur Einstufung des Incident-Schweregrads: Verfügbarkeit, Umfang, geschäftliche Auswirkung und Datengefährdung führen bis zu P1, P2, P3 oder P4.
So funktioniert es
Benennen Sie die Bahnen nach Ihren echten Entscheidungsbefugnissen
Ersetzen Sie Service Desk, Service Owner, Incident Manager sowie Recht und Compliance durch die Rollen, die jede dieser Entscheidungen bei Ihnen tatsächlich halten. Wenn außerhalb der Geschäftszeiten niemand die Frage nach der Daten- oder Sicherheitsgefährdung verantwortet, ist das eine Lücke im Bereitschaftsplan, die Sie schließen sollten, bevor Sie die Bahn umzeichnen.
Schreiben Sie Ihre Umfangsschwellen an das Diagramm
Öffnen Sie „Wie viele Nutzer oder Standorte betroffen?“ und ersetzen Sie den Kommentar durch Ihre eigenen Definitionen von mehreren Standorten, einem Team und einem einzelnen Nutzer: eine Region, eine Kundenklasse, ein Prozentsatz der aktiven Nutzer, eine namentliche Kundenliste. Schwellen, die nicht aufgeschrieben sind, werden bei jedem Vorfall neu verhandelt.
Definieren Sie nicht verfügbar gegenüber eingeschränkt für Ihre Services
Legen Sie Service für Service fest, was Nicht verfügbar bedeutet, einschließlich der Fälle teilweiser Verfügbarkeit: Nur-Lese-Betrieb, eine ausgefallene Region oder eine Warteschlange, die zwar noch annimmt, aber nichts mehr verarbeitet. Unschärfe an dieser Stelle verschiebt den gesamten Baum um eine Stufe.
Legen Sie die Workaround-Prüfung ehrlich an
Entscheiden Sie, was einen Workaround tragfähig macht: dokumentiert, zulässig, innerhalb der vorhandenen Kapazität und für die betroffenen Nutzer heute nutzbar. Ein manueller Ersatzweg, der Schulung, zusätzliches Personal oder eine Ausnahme von einer Richtlinie braucht, ist kein Workaround — ihn als solchen zu behandeln, ist der häufigste Weg, auf dem ein P1 als P2 erfasst wird.
Hängen Sie an jedes Ergebnis eine eigene Reaktionszusage
„P1 kritisch, Bridge aktiv“, „P2 hoch, Behebung läuft“, „P3 mittel, Frist überwacht“ und „P4 niedrig, geplante Arbeit“ sollten je eigene Alarmierungsregeln, Update-Takte und Zielzeiten tragen. Führen zwei Stufen zu identischem Verhalten, führen Sie sie zusammen, statt eine Stufe zu behalten, die niemand unterscheiden kann.
Legen Sie fest, wer neu einstufen darf, und dokumentieren Sie den Grund
Die Entscheidung „Auswirkung beim nächsten Update verändert?“ ist der einzige zugelassene Weg, eine Stufe zu ändern. Benennen Sie, wer ihn gehen darf, verlangen Sie, dass die Prüfungen erneut durchlaufen und nicht die Stufe neu verhandelt wird, und halten Sie die neuen Nachweise samt Uhrzeit fest, damit die Nachbereitung erkennt, wann sich das Bild geändert hat.
Lassen Sie das Diagramm freigeben und versionieren Sie es
Schweregradkriterien nützen nur, wenn sie die abgestimmten sind. Geben Sie das Diagramm an das Service Management, die Service Owner und die Rechtsabteilung zur Freigabe und bewahren Sie die freigegebene Fassung auf, damit die Definitionen, die Sie üben, auch die sind, die Sie veröffentlichen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Schweregrad und Priorität eines Incidents?
Der Schweregrad ist eine Aussage über die Auswirkung: Wie viel des Service ist gestört, für wie viele Menschen, und was blockiert das. Die Priorität ist eine Aussage über die Reihenfolge: Was nimmt sich das Team als Nächstes vor. ITIL kennt „Severity“ gar nicht als formalen Begriff, sondern leitet die Priorität aus Auswirkung und Dringlichkeit ab. Viele Entwicklungs- und SRE-Teams verwenden den Schweregrad als Kurzform für die Auswirkungshälfte, und so nutzt ihn auch dieses Diagramm. Die praktische Regel lautet: Der Schweregrad steuert die Reaktion, die Sie schulden — Alarmierung, Bridge, Update-Takt — und ändert sich nur, wenn sich die Nachweise ändern; die Priorität steuert die Warteschlange und darf täglich neu gesetzt werden. Je ein eigenes Feld dafür zu führen verhindert, dass jemand die Auswirkungsbewertung neu verhandelt, um schneller bedient zu werden.
Worin unterscheidet sich das von einem Flussdiagramm zum Incident-Management-Prozess?
Beide beantworten unterschiedliche Fragen zum selben Gegenstand. Dieses Diagramm ist ein Entscheidungsbaum: Welchen Schweregrad bekommt dieser Vorfall, und wer darf das entscheiden. Es ist eine Kette von Prüfungen, die in benannten Ergebnissen endet, und es hört auf, sobald die Stufe gesetzt ist. Ein Flussdiagramm zum Incident-Management-Prozess ist eine bereichsübergreifende Prozesslandkarte: Was passiert als Nächstes und wer tut es — von der Erfassung über Diagnose, Eskalation und Behebung bis zum Abschluss. Die meisten Teams brauchen beides, und sie berühren sich an genau einem Punkt: dem Schritt, in dem eine Stufe vergeben wird.
Wie viele Schweregradstufen sollten wir haben?
Vier ist der verbreitete Standard und die Wahl dieses Diagramms; manche Organisationen setzen darüber noch ein P0 oder SEV0 für existenzbedrohende Ereignisse. Wichtiger als die Anzahl ist, ob jede Stufe eine eigene, schriftlich festgelegte Reaktion trägt. Führen P3 und P4 zur selben Alarmierungsregel, zu denselben Zielzeiten und zum selben Update-Takt, dann haben Sie drei Stufen und ein ungenutztes Etikett. Weniger Stufen, konsequent angewendet, schlagen mehr Stufen, lax angewendet — denn der Wert der Einstufung liegt darin, dass alle Nachgelagerten ohne Rückfrage handeln können.
Wer darf ein P1 ausrufen?
Benennen Sie die Rolle vorab und halten Sie die Liste kurz. In diesem Diagramm liegt das Ausrufen in der Bahn des Incident Managers, und drei getrennte Zweige münden dort ein: ein standortübergreifender Ausfall, eine blockierte kritische Funktion ohne tragfähigen Workaround und eine bestätigte Daten- oder Sicherheitsgefährdung. Diese Struktur ist Absicht: Ein P1 sollte aus mehreren Richtungen durch Nachweise erreichbar sein, aber von einer Rolle ausgerufen werden, die zugleich die Reaktion zusagen kann. Anfordern darf ein P1 jeder; bestätigen darf es eine benannte Rolle.
Macht eine Daten- oder Sicherheitsgefährdung einen Vorfall automatisch zu einem P1?
In diesem Diagramm ja, und der Gefährdungszweig umgeht die Prüfung der Nutzerzahl vollständig. Der Grund ist, dass eine Gefährdung eine Frist auslöst, die ab Kenntnis und nicht ab Behebung läuft — ein kleiner Vorfall kann also eine große Pflicht tragen. Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Kenntniserlangung zu melden; die Benachrichtigung der betroffenen Personen nach Art. 34 ist eine eigene Prüfung und an ein voraussichtlich hohes Risiko geknüpft. Andere Regelungen wie NIS2 und vertragliche Zusagen setzen eigene Fristen, und Kundenmeldefristen sind oft kürzer als die gesetzlichen. Tragen Sie deshalb die für Sie geltenden Fristen an der Entscheidung ein. Viele Organisationen leiten Gefährdungen zusätzlich vollständig aus diesem Baum heraus in einen Incident-Response-Prozess.
Wann sollte ein einmal gesetzter Schweregrad geändert werden?
Wenn sich die Nachweise ändern, nicht wenn sich der Druck ändert. Dieses Diagramm gibt dafür genau einen Weg: die Entscheidung „Auswirkung beim nächsten Update verändert?“, deren Zweig Auswirkung gewachsen ein P2 zurück in das Ausrufen von P1 schickt. Durchlaufen Sie die Prüfungen erneut, statt die Diskussion wieder aufzumachen, und halten Sie fest, welche neuen Nachweise wann eingegangen sind. Für Herabstufungen gilt dasselbe, und sie sollten ausdrücklich behandelt werden — denn ein Vorfall, der auf P1 bleibt, nachdem die Auswirkung zurückgegangen ist, erzieht die Beteiligten leise dazu, die Stufe zu ignorieren.