Postmortem → Contract-/Control-Loop

Ein Postmortem ohne Contract-/Control-Änderung ist eine Storystunde. Der Loop schließt erst, wenn Findings Owner, Termin und Evidence bekommen.

Dieser Teil schließt die Comms-Serie: Severity, Pack und Notify werden zu dauerhaften Zusagen.

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

Vorher: Externer und regulatorischer Notify-Pfad.

In einem Satz: Kein geschlossener Incident ohne Postmortem-Actions, Contract-/Control-Änderung und Evidence.

Entscheidung

Nach Sev1/2 (und ausgewählten Sev3) gilt:

1. Postmortem mit Timeline und Beitragsfaktoren;
2. Actions mit Data Owner, Steward oder Custodian als Owner;
3. Contract-/Control-Updates wo Zusagen gebrochen wurden;
4. Comms-Retro: was intern/extern zu spät oder unklar war;
5. Evidence-Pack für Audit und Lernakte.

Kein Schließen, wenn die Folie fertig ist — erst wenn Evidence vorliegt.

Postmortem-Loop

1. Blameless, aber accountable

Der Steward führt das Postmortem mit Timeline und Beitragsfaktoren, ohne Schuldzuweisung. Jede Action trägt Owner (Data Owner, Steward oder Custodian), Termin und Evidence-Ort. Ursachen ohne Owner sind Folientext. Wird dieser Schritt zur Storystunde, endet der Incident im Chat — und dieselbe Lücke trifft den nächsten Sev1.

2. Findings clustern

Findings werden nach Technik, Prozess, Comms, Vendor und Contract gruppiert — nicht nur nach dem technischen Fix. Die Comms-Retro prüft, was intern oder gegenüber der Aufsicht zu spät oder unklar war (Pack, Notify). Nur technische Fixes ignorieren den Comms-Fehler. Wird das Clustern übersprungen, bleibt der Contract unverändert, obwohl eine Zusage gebrochen wurde.

3. In den Betrieb übernehmen

Der Data Owner weist Action-Owner zu; der Steward schreibt Backlog-Zeilen mit Termin und Evidence-Ort. Typische Ziele: Contract-Änderung, Access Policy, Eval-Gate, Metrik-Publish-Regel, Severity-Kriterium. Ein Postmortem ohne Termin ist kein Backlog. Fehlt die Übernahme, bleibt die Finding ein Icon im Catalog — und der Control existiert nur auf der Folie.

4. Review

Offene Actions laufen im Governance-Takt, nicht als jährlicher Roman. Der Steward reportet Status an den Data Owner; überfällige Actions eskalieren wie eine überfällige TIA. Review ohne Evidence-Kriterium schließt nichts. Wird der Takt vergessen, sind die Actions nach zwei Wochen unsichtbar — genau dann, wenn der Auditor fragt.

5. Schließen

Der Custodian liefert Control-Fix-Evidence (Gate existiert, Policy updated, Drill done); der Steward schließt das Pack erst dann. Mündliche Zusagen und hübsche Slides sind kein Close. Wird „später ablegen“ akzeptiert, ist der Loop eine Storystunde — und der nächste Incident wiederholt denselben Comms- und Control-Fehler.

Handoffs

Anti-Patterns

• Nachanalyse ohne Termin
• Actions ohne verantwortliche Person
• Nur technische Fixes, Comms-Fehler ignorieren
• Vereinbarung unverändert trotz gebrochener Zusage
• Akte „später“ ablegen

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.

• Arbeitsplan — Governance Operations
• Lernpfad — Governance Operations

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. Postmortem-Template mit Action-Tabelle anlegen (Owner, Termin, Evidence-Ort).
2. Für den letzten Übungscase drei Actions mit Owner setzen und zwei Wochen tracken.
3. Eine Contract- oder Control-Änderung konkret benennen (Gate, Policy, Publish-Regel).
4. Schließkriterium „Evidence vorhanden“ festlegen und einmal anwenden.