Severity und Entscheidungsrechte
Incident-Severity und Entscheidungsrechte: wer eskaliert, wer freigibt und welche Schwellen Comms auslösen.
Begriffe vor dem Lesen
- Der Schweregrad beschreibt Wirkung und Dringlichkeit, nicht die technische Schwierigkeit der Reparatur.
- Ein Kommunikationsauslöser legt fest, ab welcher Lage bestimmte interne oder externe Empfänger informiert werden.
- Eine Neueinstufung passt den Schweregrad nachvollziehbar an, wenn neue Fakten den Umfang verändern.
- Der fachliche Owner bewertet die Auswirkung und trifft fachliche Entscheidungen; der Data Steward koordiniert Informationen und Nachweise; der technische Betrieb liefert Systemfakten und setzt technische Maßnahmen um.
Ausgangslage
Ein fehlerhaftes Dashboard, ein Datenabfluss und ein KI-System mit schädlicher Entscheidung brauchen nicht dieselbe Reaktion. Ohne vorab vereinbarte Kriterien wird der erste Vorfall verharmlost und der nächste unnötig zum unternehmensweiten Alarm. Der Schweregrad schafft eine gemeinsame Grundlage für Priorität, Kommunikationsumfang und Entscheidungsrechte.
Entscheidung
Das Operating Model legt vor dem nächsten Incident fest:
- Severity-Stufen (Impact, Datenkategorie, AI-Harm, Öffentlichkeit);
- Comms-Trigger je Stufe;
- Accountable für Freigabe (Data Owner) und Orchestrierung (Steward);
- Sprechverbot außerhalb der Rolle;
- Eskalationszeit und Stellvertretung.
Keine externe Message ohne Severity-Log — und kein Sev1 ohne Zeitstempel der Freigabe.
Severity-Workflow
1. Fakten sammeln
Der Custodian liefert Scope und Timeline: betroffene Systeme, Datenkategorien, Identifier-Kreis, Modellversion, Zeitfenster — ohne Spekulation. Der Steward trennt bekannte Fakten von Unbekanntem, bevor Severity gesetzt wird. Fakten aus Slack-Threads sind keine Timeline. Wird dieser Schritt übersprungen, setzt jemand Sev1 nach dem ersten Presse-Anruf — und die Lage ändert sich mit jedem neuen Gerücht.
2. Severity setzen
Der Steward schlägt die Stufe anhand vorab vereinbarter Kriterien vor (Impact, Datenkategorie, AI-Harm, Öffentlichkeit). Der Data Owner bestätigt Sev1/2 schriftlich; bei Sev3 reicht Steward plus Stellvertretung. Bauchgefühl ohne Kriterien produziert All-Hands oder Verharmlosung. Fehlt die Bestätigung, erklärt ein On-Call-Engineer Severity und pausiert ein Modell ohne Decision Rights.
3. Comms-Modus wählen
Die Stufe öffnet den Modus: intern, Partner, Regulator, öffentlich — nicht alle vier automatisch. Der Steward veröffentlicht Severity und Sprechregeln im Incident-Channel; Comms/Legal erhalten Freigabe-Rights nur für den gewählten Modus. AI-Harm ohne eigenes Kriterium landet fälschlich als „nur intern“. Wird der Modus übersprungen, schreibt jeder Manager eine eigene Summary — und LinkedIn ist schneller als das Pack.
4. Freigabe und Log
Jede externe Formulierung ist versioniert: Autor, Freigeber, Zeitstempel, Severity zum Zeitpunkt. Der Data Owner (oder benannte Comms/Legal Authority) gibt frei; der Steward schreibt das Severity-Log. Sev1 ohne Zeitstempel der Freigabe ist nicht auditierbar. Wird das Log vergessen, kann niemand rekonstruieren, wer wann sprechen durfte.
5. Re-Severity
Neue Custodian-Fakten können hoch- oder abstufen. Der Steward startet denselben Vorschlagsweg; der Data Owner bestätigt den Wechsel. Re-Severity ohne Log erzeugt zwei parallele Wahrheiten. Wird der Wechsel nicht geübt, bleibt das Team auf der ersten Stufe stehen — oder macht aus jeder neuen Einzelinformation einen unternehmensweiten Alarm.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Custodian | Steward | Impact-Fakten |
| Steward | Data Owner | Severity-Vorschlag |
| Data Owner | Comms/Legal | Freigabe-Rights |
| Steward | Incident-Channel | Severity + Sprechregeln |
| Steward | Evidence | Severity-Log |
Anti-Patterns
- Schweregrad nach Bauchgefühl ohne Kriterien
- Jeder aktualisiert LinkedIn
- Keine Stellvertretung für den Freigeber
- Sev1 ohne Zeitstempel der Freigabe
- KI-Harm nicht in Schweregrad-Kriterien
Im Betrieb verankern
Die folgenden Punkte werden an einem realistischen Übungsfall durchgespielt. Termine und Zuständigkeiten gehören in den verlinkten Arbeitsplan; fachliche Entscheidungen und Nachweise bleiben im Incident-Paket.
- Vier Severity-Stufen mit testbaren Beispielen schreiben (Datenvolumen, Kundenzahl, Model-Blast-Radius).
- Freigeber und Stellvertreter benennen und die Eskalationszeit festhalten.
- Sprechregeln im Incident-Channel veröffentlichen.
- Einen Tabletop mit Severity-Wechsel üben und das Log prüfen.
Crisis and incident communication
Part 2 of 5
View series