Zum Inhalt springen
Search the hub
Severity und Entscheidungsrechte

Severity und Entscheidungsrechte

Incident-Severity und Entscheidungsrechte: wer eskaliert, wer freigibt und welche Schwellen Comms auslösen.

Category
Data Governance
Reading time
4 min
Published
Tags
severity decision-rights incident escalation crisis
Download PDF

Ohne Severity-Schwellen und Entscheidungsrechte wird jeder Incident entweder bagatellisiert oder zum All-Hands. Comms braucht klare Trigger.

Dieser Teil definiert Severity und Rights — bevor Stakeholder-Pack und Regulator-Pfad darauf aufsetzen.

Anschluss an Quality-Proof Incidents, Governance Operations und AI Assurance.

Vorher: Data-/AI-Incidents brauchen Comms-Playbooks. Weiter: Internes Stakeholder-Comms-Pack.

zum All-Hands. Comms braucht klare Trigger.

Lösung: Das Operating Model legt vor dem nächsten Incident Severity-Stufen, Comms-Trigger je Stufe, Accountable für Freigabe und Orchestrierung, ein Sprechverbot außerhalb der Rolle sowie Eskalationszeit und Stellvertretung fest.

In einem Satz: Keine Incident-Comms ohne Severity-Schwelle, benannten Freigeber und Sprechregeln.

Entscheidung

Das Operating Model legt vor dem nächsten Incident fest:

  1. Severity-Stufen (Impact, Datenkategorie, AI-Harm, Öffentlichkeit);
  2. Comms-Trigger je Stufe;
  3. Accountable für Freigabe (Data Owner) und Orchestrierung (Steward);
  4. Sprechverbot außerhalb der Rolle;
  5. 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 eskaliert jedes Delta zum All-Hands.

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

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

  1. Vier Severity-Stufen mit testbaren Beispielen schreiben (Datenvolumen, Kundenzahl, Model-Blast-Radius).
  2. Freigeber und Stellvertreter benennen und die Eskalationszeit festhalten.
  3. Sprechregeln im Incident-Channel veröffentlichen.
  4. Einen Tabletop mit Severity-Wechsel üben und das Log prüfen.

Crisis and incident communication

Part 2 of 5

View series

Knowledge check

Tour