Suppression qui doit atteindre partout.
Le droit à l'effacement, Art. 17, accorde aux personnes le droit de faire supprimer leurs données personnelles dans des circonstances définies. Alors que la limitation de la conservation concerne la durée de conservation des données, l'effacement porte sur la capacité à les supprimer effectivement sur demande, et cela dépend de votre chemin de suppression : il fonctionne uniquement s'il atteint chaque endroit où les données d'une personne sont stockées.
The shapes the same control failure takes.
L'effacement échoue lorsqu'une copie des données personnelles subsiste à un endroit que le chemin de suppression n'atteint pas. Les formes récurrentes :
Un nouveau stockage n'est pas intégré à la suppression
Une modification ajoute un endroit où les données personnelles sont stockées (un cache, un index de recherche, une deuxième base de données, une exportation) et le chemin de suppression de compte n'est pas mis à jour pour le vider, donc une copie persiste.
Une suppression devient une suppression logicielle
Une suppression réelle est remplacée par un drapeau (une colonne deleted_at) de sorte que les données personnelles sont toujours présentes, ce qui ne satisfait pas l'effacement.
La suppression est partielle
L'enregistrement principal est supprimé, mais les données personnelles associées dans d'autres tables, journaux ou files d'attente de messages sont laissées de côté.
Un sous-traitant n'est jamais informé de la suppression
Les données ont été envoyées à un sous-traitant tiers, et la suppression n'est pas propagée vers lui, donc une copie en aval persiste.
L'effacement n'est pas réellement accessible
Il n'existe aucun chemin fonctionnel pour supprimer les données d'une personne donnée, seulement un processus manuel ou ad hoc qui ne s'adapte pas et est facile à mal exécuter.
Une nouvelle copie sans chemin pour la supprimer.
Une fonctionnalité de recherche de personnes ajoute un index de recherche des profils utilisateurs, écrit à chaque mise à jour. Cela fonctionne. Mais le chemin de suppression de compte n'est pas mis à jour pour vider l'index, donc après une demande d'effacement, la personne est supprimée de la base de données mais reste dans l'index.
async function onUserUpdated(user: User) { await db.users.save(user)+ await searchIndex.upsert({ id: user.id, name: user.name, email: user.email })}Cela ajoute une nouvelle copie du profil de l'utilisateur (nom, email) dans un index de recherche, mais le chemin de suppression de compte ne le vide pas, donc une demande d'effacement ne l'atteindra pas. L'Art. 17 (droit à l'effacement) exige que la suppression atteigne chaque stockage des données de la personne. Mettez à jour le chemin de suppression de compte pour supprimer également l'utilisateur de l'index, et vérifiez s'il existe d'autres nouvelles copies.
L'effacement est testé contre chaque copie.
Une revue de protection des données vérifie qu'une demande d'effacement supprime effectivement les données personnelles d'une personne partout où elles sont stockées, et pas seulement dans la base de données principale : caches, index de recherche, sauvegardes (soumise à leur propre gestion acceptée), analytique et sous-traitants tiers. Le problème est généralement un stockage ajouté dans le code sans mise à jour du chemin de suppression, ce qui est exactement le type de changement qu'une revue du diff peut détecter avant son déploiement.
Une revue, pas votre DPO.
heygrc signale les modifications qui concernent le droit à l'effacement et cite l'article afin que la correction ait lieu dans la pull request. Il ne traite pas les demandes des personnes concernées ni ne rend de décision juridique. Il détecte le moment où une nouvelle copie de données personnelles est ajoutée sans chemin pour la supprimer, directement dans le diff.