Löschung, die überall ankommen muss.
Das Recht auf Löschung, Art. 17, gibt Personen das Recht, ihre persönlichen Daten unter definierten Umständen löschen zu lassen. Während die Speicherbegrenzung regelt, wie lange Daten aufbewahrt werden, geht es bei der Löschung darum, ob Daten auf Anfrage tatsächlich entfernt werden können. Dies ist eine Eigenschaft des Löschpfads: Er funktioniert nur, wenn er jeden Ort erreicht, an dem die Daten einer Person gespeichert sind.
The shapes the same control failure takes.
Die Löschung scheitert, wenn eine Kopie persönlicher Daten an einem Ort liegt, den der Löschpfad nicht erreicht. Die wiederkehrenden Muster:
Ein neuer Speicher ist nicht in die Löschung eingebunden
Eine Änderung fügt einen Ort hinzu, an dem persönliche Daten gespeichert werden (ein Cache, ein Suchindex, eine zweite Datenbank, ein Export), und der Löschpfad für mein Konto wird nicht aktualisiert, um ihn zu bereinigen, sodass eine Kopie erhalten bleibt.
Eine Löschung wird zu einer Soft-Delete
Eine echte Löschung wird durch ein Flag ersetzt (z. B. eine Spalte deleted_at), sodass die persönlichen Daten weiterhin vorhanden sind, was die Löschung nicht erfüllt.
Löschung ist unvollständig
Der Hauptdatensatz wird gelöscht, aber verwandte persönliche Daten in anderen Tabellen, Protokollen oder Nachrichtenwarteschlangen bleiben erhalten.
Ein Auftragsverarbeiter wird nicht zur Löschung aufgefordert
Daten wurden an einen externen Auftragsverarbeiter gesendet, und die Löschung wird nicht an diesen weitergegeben, sodass eine nachgelagerte Kopie bestehen bleibt.
Löschung ist nicht tatsächlich erreichbar
Es gibt keinen funktionierenden Pfad, um die Daten einer bestimmten Person zu löschen, sondern nur einen manuellen oder ad-hoc-Prozess, der nicht skalierbar ist und leicht zu Fehlern führt.
Eine neue Kopie ohne Pfad zu ihrer Löschung.
Eine Personen-Suchfunktion fügt einen Suchindex mit Benutzerprofilen hinzu, der bei jedem Update geschrieben wird. Sie funktioniert. Aber der Löschpfad für Konten wird nicht aktualisiert, um den Index zu bereinigen, sodass nach einer Löschanfrage die Person aus der Datenbank entfernt wird, aber im Index verbleibt.
async function onUserUpdated(user: User) { await db.users.save(user)+ await searchIndex.upsert({ id: user.id, name: user.name, email: user.email })}Dies fügt eine neue Kopie des Benutzerprofils (Name, E-Mail) zu einem Suchindex hinzu, aber der Löschpfad für Konten bereinigt diesen nicht, sodass eine Löschanfrage ihn nicht erreicht. Art. 17 (Recht auf Löschung) erwartet, dass die Löschung jeden Speicherort der Daten einer Person erreicht. Aktualisieren Sie den Löschpfad für Konten, um den Benutzer auch aus dem Index zu entfernen, und prüfen Sie auf weitere neue Kopien.
Löschung wird gegen jede Kopie getestet.
Eine Datenschutzprüfung überprüft, ob eine Löschanfrage die persönlichen Daten einer Person tatsächlich überall dort entfernt, wo sie gespeichert sind, nicht nur aus der primären Datenbank: Caches, Suchindizes, Backups (unter Berücksichtigung ihrer eigenen akzeptierten Handhabung), Analysetools und externe Auftragsverarbeiter. Die Lücke ist in der Regel ein Speicherort, der im Code hinzugefügt wurde, ohne den Löschpfad zu aktualisieren - genau die Art von Änderung, die eine Prüfung des Diffs vor dem Deployment erkennen kann.
Eine Prüfung, nicht Ihr Datenschutzbeauftragter.
heygrc markiert Änderungen, die das Recht auf Löschung betreffen, und verweist auf den Artikel, damit die Korrektur im Pull Request erfolgt. Es bearbeitet keine Betroffenenanfragen und trifft keine rechtliche Bewertung. Es erkennt den Moment, in dem eine neue Kopie persönlicher Daten ohne Löschpfad hinzugefügt wird - direkt im Diff.