Löschungsnachweis und Wiederauftreten-Kontrollen

Löschung, die niemand beweisen und niemand gegen Wiederauftreten absichern kann, hält nicht. Evidence und Recurrence Controls schließen den Betriebsloop — und machen aus Artefakten der Teile 1–5 einen prüfbaren Zustand.

zählung.

Lösung: Behandeln Sie Evidence und Recurrence als Pflichtprodukte jedes Löschungsfalls, nicht als optionale Audit-Kosmetik.

In einem Satz: Behandeln Sie Evidence und Recurrence als Pflichtprodukte jedes Löschungsfalls, nicht als optionale Audit-Kosmetik.

Problem

Viele DSDR-Fälle enden mit Ticket-Kommentaren: „erledigt“, „Job gelaufen“, „nicht mehr in CRM“. Auditoren und Privacy-Teams brauchen mehr: welche Scope-Zeilen, welche Strategie, welche Verify-Queries, welches Backup-Fenster, welche Side Copies, wer wann signiert hat. Ohne Pack bleibt Löschung eine Erzählung.

Ebenso fehlt oft die zweite Hälfte: Controls gegen Recurrence. Restore, Nonprod-Refresh, dbt-Rebuild und späte Exports holen Subjects zurück. Ohne KPIs und wiederkehrende Checks driftet die Landschaft in Silent Undelete.

Typische Ausfälle:

• Nachweis nur aus einem System, obwohl die Umfang Matrix zehn Zeilen hat;
• Screenshots statt reproduzierbarer Query-Hashes und Job-Logs;
• kein Re-Verify nach Restore oder nach Nicht-Produktion-Refresh;
• KPIs messen Ticket-Closure-Zeit, nicht Residual-Finds;
• Recurrence wird als neues Ticket behandelt statt als Kontrollregel-Failure;
• Lessons bleiben in Postmortems und erreichen Runbook/Vereinbarung nicht.

Diese Serie hat Scope, Strategie, Plattformpfad, Backup-Contract und Side-Copy Inventory geliefert. Pillars bleiben die normative Basis: DSDR Governance, Data Lifecycle & Retention, PII & Privacy Governance. Hier geht es um Nachweis und Dauerhaftigkeit.

Verwandte Nachbarn:

• Nicht-Produktion, Exports, Caches und Schattenkopien — Side-Copy-Steuerung;
• Backups, Snapshots und Time-Travel-Löschung — Restore→Re-Delete;
• Serie: Löschung, die hält.

Evidence-Risiko zeigt sich so:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Ticket: closed
Evidence: "CRM delete OK"
Missing: warehouse verify, BI extract, backup window note, side-copy check
T+14: subject found in nonprod refresh + old export
KPI: still "100% on-time closure"

Closure ohne Pack. KPI ohne Wahrheit. Recurrence ohne Control.

Eine zweite Signatur ist One-Shot Verify: Prüfung nur am Löschungstag. Eine dritte ist Orphan Evidence: Logs ohne Bezug zu Scope-IDs. Eine vierte ist Schein-Metrik: Durchlaufzeiten grün, Residual-Rate unbekannt.

Entscheidung

Behandeln Sie Evidence und Recurrence als Pflichtprodukte jedes Löschungsfalls, nicht als optionale Audit-Kosmetik.

Drei Prinzipien:

1. Kein Case-Close ohne Evidence Pack. Das Pack referenziert Scope Matrix, Decision Card, Runbook-Steps, Backup-Contract-Disposition und Side-Copy-Aktionen — mit Verify-Resultaten.
2. Recurrence ist ein Control-Event. Restore, Refresh und Rebuild triggern Re-Verify; Funde erhöhen Residual-KPIs und öffnen Corrective Actions, nicht nur neue Einzel-Tickets ohne Lernschleife.
3. KPIs messen Haltbarkeit, nicht nur Tempo. On-time closure bleibt relevant (DSDR Governance); ergänzt um Residual-Finds, Re-Delete-SLA nach Restore und Pack-Vollständigkeit.

Mindest-KPIs (Startset):

• Pack completeness rate (Pflichtfelder gefüllt);
• residual find rate (Funde nach Closure / Fälle);
• restore re-delete on-time rate;
• side-copy control coverage (Inventory-Klassen mit verantwortliche Person);
• mean time to evidence (von Purge bis Pack ready).

Das Pack ist kein zweites Ticket-System. Es ist die gebündelte Nachweisakte zum Fall: Verweise statt Datenfriedhof, Hashes und Logs statt Anekdoten. Wo Roh-PII im Evidence-Store landen würden, speichern Sie Referenzen und aggregierte Verify-Resultate und halten Zugriff need-to-know — Evidence darf Privacy nicht selbst verletzen.

Checkliste

Schließen Sie den Betriebsloop für den Pilot:

• definieren Sie Nachweis-Pflichtfelder je Case;
• mappen Sie jedes Pflichtfeld auf Artefakte aus Teilen 1–5;
• legen Sie Verify-Queries und Aufbewahrung der Resultate fest;
• verdrahten Sie Restore- und Refresh-Events an Re-Verify;
• setzen Sie Residual-Find-Triage und verantwortliche Person;
• publizieren Sie das KPI-Startset an Privacy/Data Governance;
• speichern Sie Packs ticketzentriert und zugriffsbeschränkt;
• reviewen Sie monatlich Recurrence-Funde gegen Runbook/Vereinbarung;
• stoppen Sie, wenn ein abgeschlossener Pilotfall ein vollständiges Pack und einen Recurrence-Check-Plan hat.

Artefakt

Erstellen Sie ein Deletion Evidence Pack plus Recurrence Controls.

Evidence Pack — Pflichtfelder:

• Case-/Auskunfts- und Löschrechte-ID, Subject-Klassen (keine unnötigen Klartext-personenbezogene Daten im Pack-Index);
• Links: Umfang Matrix, Decision Card, Runbook-Run-ID, Backup Vereinbarung, Side-Copy Inventory;
• Step-Sign-offs mit Zeitstempel und Rolle;
• Verify-Resultate (Query-ID/Hash, Count/Token-Status, System);
• bekannte Residuen (Backup-Fenster, Hold) mit Kommunikation;
• Ausnahmen und Freigaben;
• Closer und Close-Datum.

Recurrence Controls — Pflichtfelder:

• Trigger: restore, nonprod-refresh, dbt-rebuild, export-scan, scheduled-reverify;
• kontrollOwner und SLA;
• Nachweisort der Re-Verify;
• Residual-KPI-Feeds;
• Corrective-Action-Workflow zurück in Runbook/Vereinbarung/Inventory;
• Review-Cadence (z. B. monatlich).

Ergebnisse: prüfbare Closure, erkennbare Undeletes, Steuerungsgrößen für Haltbarkeit.

Tools

Ticket-/Case-System mit Evidence-Checkliste. Job-Log- und Query-Result-Store (zugriffsbeschränkt). Orchestrierungs-Hooks für Re-Verify. KPI-Board oder gesteuertes Workbook. Katalog/Policy-Links. Least Privilege: Packs enthalten Nachweis, nicht unnötig Roh-PII.

Ressourcen

Interne Quellen: Audit-Anforderungen, DSDR-SOPs, DR-Restore-Logs, Nonprod-Refresh-Kalender, Privacy-Board-Packs, Residual-Incident-Reviews.

Nachbarn: DSDR Governance, Data Lifecycle & Retention, PII & Privacy Governance, gesamte Serie: Löschung, die hält.