Betroffenenrechte und Löschpflicht als Betriebsvertrag

z; technische Stack-Löschung verweist auf die Spezialserie.

In einem Satz: Betreibe DSR als vierstufigen Pfad mit Owner, Scope und Evidenz; technische Stack-Löschung verweist auf die Spezialserie.

Problem

Betroffenenanfragen landen in Postfächern; Locate stoppt an einer Tabelle; Löschung wird mit „Account deaktiviert“ verwechselt.

Der kritische Fehler ist die Gleichsetzung technischer Schutzmaßnahmen mit rechtmäßiger oder vollständiger Privacy-Governance. Maskierung, Tags und Zugriffskontrollen können Risiken senken; sie ersetzen weder Zweckentscheidung noch Rechtsgrundlage noch Betroffenenrechte. Verbindliche Auslegung bleibt bei Privacy oder Legal.

Entscheidung

Betreibe DSR als vierstufigen Pfad mit Owner, Scope und Evidenz; technische Stack-Löschung verweist auf die Spezialserie.

Der Pilot gilt nur für ein konkretes Analytics- oder AI-Produkt mit personenbezogenen oder potenziell personenbezogenen Pfaden. Erfolgreich ist er nicht bei maximaler Dokumentenmenge, sondern wenn eine reale Änderung und eine Zugriff- oder Rechteentscheidung mit nachvollziehbarer Accountability laufen.

Scope und gewünschtes Ergebnis

Scope-in umfasst das ausgewählte Produkt, produktive und nichtproduktive Umgebungen, Identitäten, Upstream-Quellen, Downstream-Consumer, Exporte und relevante Betriebsprozesse. Privilegien und Notfallwege gehören hinein.

Scope-out wird konkret benannt. Benachbarte Domänen und historische Plattformen werden als bekannte Abhängigkeiten oder spätere Wellen registriert.

Das gewünschte Ergebnis ist ein kleiner Betriebsvertrag: Wer entscheidet? Wo wird umgesetzt? Wie wird Wirkung getestet? Wo liegt Evidenz? Wann wird neu geprüft?

Praktischer Workflow

Der Workflow beginnt mit einem realen Produkt und einer bevorstehenden Änderung. Ein abstraktes Zielbild ohne Change, Access Request oder Incident liefert keine belastbare Probe.

Operating Model und Entscheidungsrechte

• Business oder Data Owner: bestätigt Bedeutung, erlaubten Zweck, Risikotoleranz und Priorität.
• Data Steward: bereitet Entscheidungen vor, pflegt Kontext und verfolgt Reviews sowie offene Evidenz.
• technischer Betreiber: implementiert die freigegebene Entscheidung sicher und betreibt den Durchsetzung-Punkt.
• kontrollverantwortliche Person: definiert das erwartete Kontrollergebnis, die Testmethode und den Ausnahmeprozess.
• Security, Privacy oder Legal: entscheidet oder berät innerhalb des ausdrücklich festgelegten Mandats.
• Nutzer verantwortliche Person: bestätigt Abhängigkeit, Nutzung, Migrationsfähigkeit und Kommunikationsweg.

Pro Entscheidung gibt es genau ein Accountable. Mehrere Teams dürfen beitragen, prüfen oder ausführen; geteilte Accountability erzeugt jedoch Wartezeiten und unklare Eskalation. Wenn unterschiedliche Entscheidungen vorliegen, werden sie als getrennte Decision Objects geschnitten.

Die beteiligten Fach- und Kontrollfunktionen liefern unterschiedliche Entscheidungen und Prüfungen; keine einzelne Rolle darf stillschweigend für alle anderen sprechen. Technical Custodians setzen freigegebene Controls um und erzeugen Betriebsnachweise. Sie entscheiden weder über rechtliche Anwendbarkeit noch über fachliche Risikoakzeptanz oder unabhängige Prüfung.

Acht Arbeitsschritte für diese Entscheidung

1. Intake-Kanal, Fristen und accountable Koordination festlegen

Das Team muss Intake-Kanal, Fristen und accountable Koordination festlegen. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

2. Identitätsprüfung und Missbrauchsschutz vom Locate trennen

Das Team muss Identitätsprüfung und Missbrauchsschutz vom Locate trennen. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

3. Locate-Scope über Warehouse, Lake, BI, Export und Cache definieren

Das Team muss den Locate-Scope über Warehouse, Lake, BI, Export und Cache definieren. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

4. Act-Typen unterscheiden: Auskunft, Berichtigung, Einschränkung, Löschung

Das Team muss Act-Typen unterscheiden: Auskunft, Berichtigung, Einschränkung, Löschung. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

5. Legal Holds und Aufbewahrungspflichten als Konflikte sichtbar machen

Das Team muss Legal Holds und Aufbewahrungspflichten als Konflikte sichtbar machen. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

6. Evidence: was wurde gefunden, was getan, was bewusst ausgenommen

Das Team muss Evidence: was gefunden, was getan und was bewusst ausgenommen wurde dokumentieren. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

7. Wiederauftreten-Kontrollen nach Löschung planen

Das Team muss Wiederauftreten-Kontrollen nach Löschung planen. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

8. Übergabe an technische Löschungsserie für Stack-Details

Das Team muss die Übergabe an die technische Löschungsserie für Stack-Details festlegen. Dokumentiert werden Ausgangszustand, Entscheidung, ausführende Änderung, erwartetes Ergebnis und zuständige Rolle. Die Arbeit gilt erst als abgeschlossen, wenn ein anderer Beteiligter den Nachweis finden und dem betroffenen Produkt sowie der wirksamen Version zuordnen kann.

Für den Pilot genügt eine repräsentative Stichprobe. Sie muss jedoch den produktiven Pfad abbilden und darf nicht durch einen vereinfachten Demo-Zugang oder eine isolierte Testkonfiguration ersetzt werden.

Rechte brauchen Locate über den Stack — Technik braucht eine eigene Serie

Die Foundation definiert den Betriebsvertrag: wer nimmt an, wer sucht, wer handelt, wer belegt. Ob Soft-Delete, Crypto-Shred oder Backup-Löschung greifen, klärt Löschung, die hält. DSDR als Säule: DSDR Governance.

Legal Hold und Analytics-Retention können kollidieren — Konflikte sichtbar machen, nicht still „löschen und hoffen“.

Identität, Zugriff und Trennung von Aufgaben

Identity ist eine End-to-End-Kette. Corporate Group, Plattformrolle, Service Account, Ressourcengruppe und wirksames Privileg werden gemeinsam betrachtet. Ein sauberer Gruppenname beweist keinen effektiven Zugriff, wenn direkte Grants, lokale Rollen, Verantwortung-Rechte oder Notfallkonten daneben existieren.

Mindestens vier Tests werden protokolliert: erlaubter Standardzugriff, verweigerter Zugriff, Service-Zugriff und privilegierter Bypass. Der Test nennt Identität, Zeitpunkt, Ressource, erwartetes Ergebnis, tatsächliches Ergebnis und verknüpfte Policy-Version.

Metadaten, Lineage und kontrollierte Änderungen

Metadaten werden nicht pauschal an einer Stelle autoritativ. Technische Objekt- und Laufzeitdaten stammen aus der Plattform; fachliche Bedeutung und zulässige Nutzung aus dem freigegebenen Governance-Workflow; Identitäten aus dem Identity Provider; Transformationen aus Code und Deployment-Pipeline.

Eine Änderung ist materiell, wenn sie Bedeutung, Zugriff, Klassifikation, Consumer-Kompatibilität, Retention, Kontrollwirkung oder Betriebsrisiko verändert. Materielle Änderungen erhalten Impact Assessment, Entscheidung, getestete Umsetzung, Kommunikationsplan und gegebenenfalls Migrationsfrist.

Evidenz, Tests und Ausnahmen

Der minimale Evidence Pack enthält Scope-Entscheidungen, Anforderungsreferenzen, Zweckbereich-Mapping, Control-Zuordnung und Review-Protokolle. Jeder Nachweis trägt Produkt-Identifier, Control- oder Policy-Version, Erzeugungszeitpunkt, Owner, Gültigkeitszeitraum und Link zur zugrunde liegenden Entscheidung.

Eine Exception ist eine zeitlich begrenzte Entscheidung, kein Kommentar im Ticket. Sie enthält Scope, Risiko, Begründung, kompensierende Maßnahmen, accountable Genehmiger, Ablaufdatum, Remediation Owner und ein Signal für die automatische Wiedervorlage.

Betrieb, Incidents und Review-Kadenz

Governance wird in Change-, Access-, Incident- und Produktprozesse eingebaut. Der Katalog dient als Navigationspunkt; Arbeit und Primärnachweise bleiben in den operativen Systemen.

Ein Incident erhält einen Produktbezug, betroffene Consumer, technischen Coordinator, fachliche Risikoentscheidung, Kommunikationsweg und Closure Evidence. Monatlich werden offene Ausnahmen, überfällige Reviews und fehlgeschlagene Tests betrachtet.

Häufige Anti-Patterns

Das Tool wird zum Owner erklärt

Eine Plattform zeichnet Konfiguration auf, kann aber kein Geschäftsrisiko akzeptieren oder konkurrierende Zwecke entscheiden.

Maskierung ersetzt Rechtmäßigkeit

Technischer Schutz reduziert Risiko, beantwortet aber nicht allein Rechtsgrundlage, Zweckbindung oder Betroffenenrechte.

Vollständigkeit ersetzt Priorität

Tausende indexierte Objekte können verdecken, dass kritische Produkte keine getesteten Controls besitzen.

Evidenz wird vor dem Audit gebaut

Nachgebaute Evidenz ist teuer und repräsentiert möglicherweise nicht den tatsächlich betriebenen Zustand.

Ausnahmen haben kein Ablaufdatum

Dauerhaft temporärer Zugriff wird zu einem undokumentierten alternativen Operating Model.

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 — DSGVO Foundations
• Lernpfad — DSGVO Foundations

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.

Schritt 1: Grenze und Baseline

Produkt, Owner, Consumer, Identitäten, Datenflüsse, Controls, Ausnahmen und aktuelle Nachweise aufnehmen. Drei konkrete Risiken priorisieren.

Schritt 2: Decisions und Design

Authority Matrix, Policy- beziehungsweise Contract-Entscheidungen, Testfälle und Evidence Locations freigeben. Offene Rechts- oder Sicherheitsfragen sichtbar halten.

Schritt 3: Implementieren und testen

Controls über den echten Pfad ausrollen. Positive, negative, Service- und Bypass-Tests durchführen; Fehler als Product Backlog behandeln.

Schritt 4: Änderung und Incident simulieren

Eine materielle Änderung sowie einen Betriebs- oder Zugriffsvorfall durch Rollen, Kommunikation und Evidenzkette führen.

Schritt 5: Review und Skalierungsentscheidung

Wirksamkeit, Aufwand, offene Exceptions und Automatisierungspotenzial bewerten. Nur nach bestandener Stichprobe auf weitere Produkte skalieren.

Messung und Exit-Kriterien

• Anteil kritischer Assets mit bestätigtem verantwortliche Person, Nutzer und Review-Datum
• Anteil materieller Änderungen mit dokumentiertem Impact und Nutzer-Bestätigung
• Anteil getesteter Kontrollregeln mit aktueller, reproduzierbarer Evidenz
• Zeit von Access Request oder Change bis zur accountable Entscheidung
• Anzahl und Alter offener Exceptions sowie Anteil ohne Remediation-Fortschritt
• Aufwand zur Rekonstruktion einer Stichprobe von Requirement bis wirksamer Plattformversion

Ein Exit ist gerechtfertigt, wenn die gewählte Oberfläche den kritischen Durchsetzung- oder Evidence-Bedarf nicht zuverlässig erfüllt, notwendige Authority außerhalb des Modells liegt oder der Betriebsaufwand den Produktwert dauerhaft übersteigt.

Checkliste

• Umfang-in, Umfang-out und gewünschtes Ergebnis sind schriftlich bestätigt.
• Pro kritischer Entscheidung existiert genau ein Accountable.
• Business Authority, technische Administration und unabhängige Prüfung sind getrennt.
• Klassifikation und zulässige Nutzung stammen aus einer benannten Authority.
• Positive, negative, Service- und Bypass-Pfade wurden mit realistischen Identitäten getestet.
• Materielle Änderungen haben Impact Assessment, Freigabe und Kommunikationsweg.
• Evidenz nennt Version, Zeitpunkt, verantwortliche Person, Umfang und Gültigkeit.
• Exceptions besitzen Risiko, kompensierendes Kontrollregel, Ablauf und Remediation verantwortliche Person.
• Review-Kadenz und Eskalation sind in bestehende Arbeit eingebaut.
• Metriken messen Kontrollregel-Wirkung statt nur dokumentierte Vollständigkeit.

Artefakt

Das Ergebnis ist eine DSR Operating Contract. Sie dokumentiert Scope, Produkt-Identifier, Authority, technische Durchsetzung-Punkte, Tests, Evidence Locations, offene Konflikte, Exceptions und Review-Datum.

Ergänzt wird sie durch einen Evidence Index mit Links zu autoritativen Records (Version, Zeitraum, Control, Owner). Die Karte ist ein Betriebsvertrag; Änderungen an Scope oder Authority erzeugen eine neue Version.

Tools und Verweise

Fachliche Oberfläche: Data Owner, Steward, Custodian, Privacy/Legal, Security und Consumer Owner. Keine Rolle ersetzt die anderen. Diese Serie ist keine Rechtsberatung.

Tools und Quellen