Warum Löschung ohne Scope scheitert

Problem

Ein Data Subject Deletion Request (DSDR) klingt operativ einfach: Person X löschen. In der Praxis trifft das Ticket auf eine Landschaft, in der dieselbe Identität in Quellsystemen, Staging, Warehouse, Lake, Marts, BI-Caches, Exports und Ticket-Anhängen vorkommt. Jedes Team löscht „seine“ Tabelle. Keines besitzt die Gesamtmenge der Kopien.

Typische Ausfälle:

• die CRM-Zeile ist weg, der analytische Kundenmart enthält noch den Hash und die Historie;
• die Warehouse-Faktentabelle ist bereinigt, ein Downstream-Snapshot und ein Self-Service-Export nicht;
• Legal Hold und Retention stehen in Konflikt, ohne dass der Umfang beide Fälle trennt;
• Lineage zeigt Quellen, aber nicht Side Copies (Downloads, Ticket-Anhänge, Notebook-Outputs);
• Stewardship bestätigt „gelöscht“, weil das Ticket geschlossen ist — nicht weil Evidenz über alle Orte vorliegt.

Diese Serie behandelt Löschung, die hält: Scope, Strategie, Plattformpfad, Backup/Time Travel, Schattenkopien und Nachweis. Sie ersetzt nicht die Pillars. Für das Betriebsmodell der Anfrage selbst siehe DSDR Governance. Für Aufbewahrung und Stilllegung siehe Data Lifecycle & Retention. Für Klassifikation und Schutz personenbezogener Daten siehe PII & Privacy Governance. Hier geht es um die architektonische und operative Gewohnheit, Löschung als lokales Ticket statt als landschaftsweiten Scope zu behandeln.

Verwandte Nachbarn:

• Auskunfts- und Löschrechte Governance — Request-Anfrageweg, Fristen, Verantwortung, Nachweispflicht;
• Data Lifecycle & Retention — Retention vs. Löschungspflichten;
• personenbezogene Daten & Privacy Governance — was überhaupt als personenbezogen gilt;
• Serie: Löschung, die hält — Überblick aller Teile.

Scope-Risiko zeigt sich als operative Signaturen:

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

Ticket sagt        "Kunde 4812 gelöscht"
CRM                Zeile entfernt
Warehouse Hub      Customer-Key noch in Bridge + SCD2
BI-Dataset         Import vom letzten Sonntag, Key noch sichtbar
Export-Share       CSV vom Incident-Review mit voller Adresse
Backup             Point-in-Time enthält noch den Datensatz

Sechs Orte. Ein Ticket. Ein Status „done“. Kein gemeinsamer Scope.

Eine zweite Signatur ist der Partial Delete: nur die aktuelle Zeile, nicht Historie, Indizes, Suchcaches und abgeleitete Features. Eine dritte ist der Orphan Key: Primärschlüssel weg, aber Events, Logs und Marts referenzieren weiter denselben Identifier. Eine vierte ist der Unknown Copy: niemand hat den Export-Pfad oder das Nonprod-Refresh inventarisiert.

Nichts davon braucht ein neues Privacy-Tool als ersten Schritt. Es braucht eine Betriebsentscheidung: welche Systeme und Kopien gehören zum Löschungsfall — und welche sind bewusst out of scope mit Begründung.

Entscheidung

Behandeln Sie Löschungs-Scope als gesteuertes Artefakt, nicht als implizites Nebenergebnis einzelner Ticket-Kommentare.

Drei Prinzipien:

1. Kein Löschungsfall ohne Scope-Grenze. Primärsysteme, analytische Schichten, Side Copies, Backups und Nonprod sind eigene Scope-Zeilen — nicht Fußnoten.
2. Scope trennt „muss weg“ von „darf bleiben“. Retention, Legal Hold, aggregierte Nicht-Identifizierbarkeit und technische Logs brauchen explizite Disposition, nicht stilles Weglassen.
3. Scope ohne Owner ist Debt. Jede Scope-Zeile braucht System-Owner, Evidenzort und Bestätigungsmethode. „Irgendwer im Data Team“ ist kein Owner.

Verbieten Sie nicht parallele Löschung in mehreren Teams. Verbieten Sie die Gewohnheit, „gelöscht“ zu melden, bevor die Scope Matrix geschlossen ist. DSDR-Prozesse und Retention-Regeln bleiben in den Pillars; diese Serie liefert den operativen Scope- und Strategie-Rahmen darunter.

Benachbarte Probleme unterscheiden:

Der erste Betriebsschritt ist Sichtbarkeit: Scope inventarisieren, bevor Strategien und Runbooks verfeinert werden.

Checkliste

Bauen Sie eine erste Deletion-Scope-Sicht, ohne die gesamte Landschaft auszukochen:

• wählen Sie einen repräsentativen Auskunfts- und Löschrechte- oder Löschungsfall (eine Domain, eine Personenklasse);
• listen Sie Primärsysteme, die den Subject Identifier führen;
• listen Sie analytische Schichten: Raw/Landing, Curated, Marts, Feature Stores;
• markieren Sie BI-Semantik, Caches, Extracts und gebuchte Reports;
• erfassen Sie bekannte Side Copies: Exports, Ticket-Anhänge, Notebook-Outputs, Shared Drives;
• notieren Sie Backup-, Snapshot- und Time-Travel-Fenster (Detail in Teil 4);
• flaggen Sie Nicht-Produktion-Refresh und Masking-Lücken (Detail in Teil 5);
• trennen Sie Legal-Hold- und Retention-Zeilen von löschpflichtigen Zeilen;
• benennen Sie Owner und Evidenzmethode je Umfang-Zeile;
• stoppen Sie, wenn Sie beantworten können: welche Kopien würden den Claim „gelöscht“ morgen widerlegen?

Artefakt

Erstellen Sie eine Deletion Scope Matrix mit einer Zeile pro System, Schicht oder Side-Copy-Klasse im Löschungsfall.

Pflichtfelder:

• stabile Umfang-ID und Business-Label;
• Umfang-Klasse: source, pipeline, warehouse, lake, mart, bi, export, cache, backup, nonprod, other;
• Identifier-Typen (Customer-ID, E-Mail-Hash, Device-ID, …);
• Owner und bestätigende Rolle;
• Disposition: in-scope-delete, in-scope-anonymize, retain-legal-hold, retain-retention, out-of-scope, unknown;
• Evidenzmethode: query, job-log, ticket, attestation, none;
• Abhängigkeiten / Downstream-Zeilen;
• Blast-Radius-Tags: pii, financial, customer-facing, orphan-key, unknown-copy;
• Status: inventoried, confirmed, executed, verified;
• Verweis auf Auskunfts- und Löschrechte-Ticket und nächstes Serien-Follow-up (Teile 2–6).

Ergebnisse: die landschaftsweite Löschungsgrenze, die Unknown-Copy-Hotlist und der Backlog für Strategie, Plattform-Runbook und Evidenz.

Tools

Lineage und Katalog für System- und Tabelleninventar. DSDR-/Ticket-System für Request-ID und Fristen. Report Inventory für BI-Extracts. Repo- und Job-Suche nach Identifier-Spalten. Retention- und Hold-Register aus Lifecycle-Governance. Least Privilege beim Scannen personenbezogener Orte.

Ressourcen

Nützliche interne Quellen: DSDR-Playbooks, Systemlandschaftskarten, Warehouse-/Lake-Schemas, BI-Workspace-Inventare, Export-Freigaben, Incident-Tickets mit Titel „Daten noch sichtbar nach Löschung“, Steward-Interviews.

Architektur-Nachbarn: DSDR Governance, Data Lifecycle & Retention, PII & Privacy Governance, Serie: Löschung, die hält, Serie: Mails & Dokumente vor AI.