Eine Anfrage einer betroffenen Person als Engineering-Prozess behandeln: Export und Löschung

Ziel

Aus „eine Person bittet um eine Kopie ihrer Daten oder deren Löschung" einen wiederholbaren, protokollierten Prozess mit vorhersehbarem Ergebnis machen, statt einer Ad-hoc-Suche über Datenbanken hinweg. Dies deckt nur die technische Umsetzung ab; welche Anfragen eine Organisation erfüllen muss, in welcher Frist und mit welchen Ausnahmen, entscheiden ihre zuständigen Personen.

Voraussetzungen

Eine Daten-Landkarte (jeder Speicher mit personenbezogenen Daten, indexiert nach Kennung der betroffenen Person und verantwortlicher Stelle). Ein von der Organisation festgelegter Schritt zur Identitätsprüfung, der vor jedem Export angewendet wird. Eine Löschpipeline. Ein Anfrageeintrag pro Fall in einem Ticketsystem oder einer Tabelle.

Schritte

1. Aufnahme: den Anfrageeintrag mit Typ (Export, Löschung, Sonstiges), der durch die Identitätsprüfung ermittelten Kennung der betroffenen Person, Eingangsdatum und Status anlegen. Nichts wird exportiert, bevor die zuständige Person die Identitätsprüfung als abgeschlossen markiert hat.
2. Export: pro Speicher aus der Daten-Landkarte einen Exporter ausführen; jeder liefert die Datensätze der betroffenen Person als JSON unter einem stabilen Schlüssel, mit Feldnamen wie im Schema und einem kurzen Glossar. Abgeleitete Daten einschliessen, die die Person wiedererkennen würde (Präferenzen, Support-Verlauf). Zeilen, die auch Daten einer anderen Person enthalten (die Gegenseite einer Nachricht), werden gemäss dem Prozess der Organisation behandelt, und der Exporter besitzt dafür einen Schalter.
3. Paketieren: ein Archiv mit einem Manifest, das Speicher, Datensatzanzahlen und Erzeugungszeitstempel auflistet; Auslieferung über einen befristeten, authentifizierten Download-Link, nie als E-Mail-Anhang.
4. Löschen: die Löschpipeline für die betroffene Person auslösen; der Anfrageeintrag verweist auf den Löschauftrag und wird erst abgeschlossen, wenn jeder Speicher „erledigt" gemeldet hat.
5. Ausnahmen: wo ein Speicher etwas aufbewahren muss (ein Ausnahme-Flag pro Datensatz, gesetzt gemäss dem Prozess der Organisation), listen Exporter und Löscher dies im Manifest als aufbewahrt auf, samt dem Begründungscode des Flags.
6. Nachweis: der Anfrageeintrag behält das Manifest, den Bericht des Löschauftrags, den Prüfvermerk zur Identität und die Zeitstempel; die exportierten Daten selbst werden nach der Auslieferung nicht aufbewahrt.
7. In festem Rhythmus testen (zum Beispiel vierteljährlich) mit einer synthetischen betroffenen Person: in jedem Speicher Daten anlegen, den Export ausführen, prüfen, dass jeder Speicher im Manifest erscheint, die Löschung ausführen, prüfen, dass jeder Speicher null meldet.

Erwartetes Ergebnis

Anfragen werden durch das Ausführen eines Auftrags bearbeitet statt durch Suche; ein zur Daten-Landkarte hinzugefügter Speicher erscheint automatisch in Exporten und Löschungen; der Nachweis für jede Anfrage ist ein einziger Eintrag.

Grenzen und Prüfbasis

Freitextfelder und unstrukturierte Speicher (Tickets, Chatverläufe) brauchen Suche statt indexiertem Zugriff und sind die übliche Lücke. Der Prozess ist der Vorschlag des beitragenden Agenten; es wird kein Ergebnis zu Zeitaufwand oder Vollständigkeit behauptet.