Supprimé de la base de données - vivant dans les sauvegardes

Chaque entreprise a une politique de rétention. Elle vit quelque part dans un document, probablement mis à jour pour la dernière fois lorsque quelqu'un a réalisé que l'audit approchait, et elle affirme avec assurance quelque chose comme « les données personnelles sont supprimées après 90 jours », un nombre choisi pour paraître impressionnamment court plutôt que dérivé d'une analyse documentée de limitation de finalité. La direction approuve. Le service juridique valide. Le document est classé.

Les données, quant à elles, sont immortelles. Particulièrement dans les sauvegardes, dont personne n'a parlé lors de la réunion sur la politique, et qui conservent silencieusement tout depuis trois ans.

C'est là le fossé dont personne ne parle : la différence entre avoir une politique de rétention et l'appliquer réellement. Rédiger la politique prend un après-midi. L'appliquer à travers un système de production réel (bases de données, sauvegardes, journaux, processeurs tiers, exports archivés, entrepôts de données, copies fantômes) prend considérablement plus de temps et fait surface des décisions architecturales que vous n'avez probablement pas prises en pensant à la suppression.

Pourquoi la plupart des applications de rétention échouent avant même de commencer

Le problème fondamental est que les données s'accumulent dans plus d'endroits que ce que les rédacteurs de la politique ne le savaient. Ils pensaient à la base de données principale. Ils ne pensaient pas au pipeline de journalisation capturant les corps de requêtes contenant des données utilisateur, conservés indéfiniment parce que personne n'a défini de politique de rotation des journaux qui s'exécute réellement. Ou à l'entrepôt d'analytique où les données brutes d'événements ont été déversées il y a dix-huit mois pour un projet qui n'a jamais été lancé, contenant toujours des identifiants utilisateur complets parce que la pseudonymisation était « au programme ». Ou à la sauvegarde quotidienne de la base de données conservée pendant quatre-vingt-dix jours, ce qui signifie que les données que vous avez supprimées de votre base de données en direct le premier jour sont intactes dans une sauvegarde jusqu'au quatre-vingt-onzième jour, potentiellement plus longtemps si quelqu'un a manuellement archivé une copie avant une version majeure « juste au cas où ».

Votre obligation de rétention s'étend également à chaque intégration tierce que vous avez cartographiée dans l'article précédent. Si vous supprimez un utilisateur de votre système mais que votre CRM a toujours son enregistrement, que votre outil de surveillance d'erreurs a toujours ses traces de pile, et que votre API de modèle d'IA a toujours son historique de conversation dans un ensemble de données de fine-tuning, vous n'avez en réalité rien supprimé. Vous avez juste supprimé la copie que vous contrôlez.

Et puis il y a le CSV que quelqu'un a exporté pour une analyse ponctuelle et enregistré sur son ordinateur portable. Vous ne pouvez pas automatiser cela, mais vous pouvez en faire une question disciplinaire plutôt qu'une réflexion technique après coup.

Suppression, anonymisation, pseudonymisation : pourquoi la distinction est importante

Avant d'écrire une seule ligne de code de suppression, décidez quelle approche vous adoptez réellement, car elles sont véritablement différentes et le RGPD les traite différemment.

La suppression signifie que les données ont disparu. Si quelqu'un soumet une demande d'accès aux données après la suppression, la réponse correcte est « nous ne détenons aucune donnée vous concernant ». Clair, simple, et le plus difficile à mettre en œuvre proprement à grande échelle.

L'anonymisation signifie que les données existent toujours mais ne peuvent plus être liées à un individu. Pas par vous, pas par personne, même avec des ensembles de données supplémentaires ou un effort raisonnable. Si vous réussissez cela, le RGPD ne s'applique plus aux données anonymisées. Vous pouvez les conserver indéfiniment. Utilisez-les pour l'analytique, les ensembles de données QA, l'entraînement de modèles, les tests de charge, tout ce dont vous avez besoin. Ce n'est pas une faille. C'est la solution prévue. Le RGPD encourage activement l'anonymisation précisément pour que les organisations puissent conserver des données à des fins secondaires légitimes sans que l'horloge de rétention ne tourne. Le règlement veut que vous fassiez cela. Il veut juste que vous le fassiez correctement.

Le hic, c'est qu'une anonymisation correcte est plus difficile qu'il n'y paraît. Supprimer un nom et un e-mail d'un enregistrement n'est pas de l'anonymisation si les champs restants (bande d'âge, code postal, titre de poste, date de création du compte) sont suffisamment spécifiques qu'une personne déterminée pourrait identifier l'individu de toute façon. C'est ce qu'on appelle le risque de ré-identification, et le sous-estimer est la façon dont les projets d'anonymisation deviennent silencieusement des projets de pseudonymisation qui ne trompent personne, encore moins un régulateur.

La pseudonymisation (remplacer les identifiants directs par des jetons tout en conservant une table de correspondance quelque part) est utile opérationnellement et le RGPD vous accorde du crédit pour l'avoir fait, mais elle ne satisfait pas à elle seule une obligation de suppression. L'individu est toujours identifiable via la table de correspondance. La suppression de la table de correspondance aide mais n'est pas garantie d'être suffisante non plus, car les enregistrements pseudonymisés peuvent toujours être ré-identifiables par d'autres attributs dans l'ensemble de données. Si vous prévoyez de vous fier à la pseudonymisation pour satisfaire aux obligations de rétention, obtenez un avis approprié avant de lancer le travail plutôt qu'après.

La séparation pratique pour la plupart des développeurs : supprimez les données personnelles dont vous n'avez plus besoin pour la finalité initiale, anonymisez les données que vous avez une raison légitime réelle de conserver à des fins secondaires comme le QA, les tests et l'amélioration des modèles. Faites l'anonymisation correctement : supprimez les identifiants directs, évaluez le risque de ré-identification par rapport aux champs restants, documentez votre évaluation. Si vous ne pouvez pas le faire en toute confiance, supprimez à la place. Mal faire l'anonymisation et dire que c'est fait est pire que de ne pas essayer.

Comment implémenter réellement la suppression

Commencez par cartographier chaque endroit où les données d'un utilisateur résident. Pas les endroits où vous pensez qu'elles résident. Les endroits où elles résident réellement. Menez l'exercice de la même manière que vous avez mené l'audit d'intégration dans l'article précédent : commencez par ce qui est observable (tables de base de données, destinations de journaux, intégrations tierces), pas par ce que dit le diagramme d'architecture.

Pour chaque emplacement, répondez à trois questions. Pouvez-vous supprimer ou anonymiser à la demande ? Pouvez-vous automatiser cette suppression selon un calendrier ? Pouvez-vous vérifier que la suppression a eu lieu ?

La troisième question est celle que la plupart des équipes sautent. Un travail de suppression qui échoue silencieusement et rapporte le succès est pire qu'aucun travail de suppression du tout, car vous avez maintenant un enregistrement de conformité affirmant que les données ont été supprimées alors qu'elles ne l'ont pas été. Intégrez la vérification dès le début. Enregistrez la suppression, enregistrez le nombre d'enregistrements affectés, alertez en cas de suppressions de zéro enregistrement pour des utilisateurs qui auraient dû avoir des données.

Pour votre base de données principale, la suppression est généralement simple : un travail planifié basé sur `created_at` ou `last_active`, avec une période de suppression logique si votre équipe de support a besoin d'une fenêtre de récupération. La période de suppression logique est aussi une période de rétention. Définissez-la explicitement et appliquez-la.

Pour les journaux, définissez des politiques de rétention au niveau du pipeline, pas comme une tâche de nettoyage manuelle. Si votre infrastructure de journalisation le prend en charge, filtrez les PII des entrées de journal à l'ingestion plutôt que d'essayer de les supprimer plus tard. Supprimer des enregistrements spécifiques d'un flux de journaux rétroactivement est pénible. Ne pas les écrire en premier lieu est beaucoup plus facile.

Pour les sauvegardes, acceptez qu'il y aura un décalage. Si vos sauvegardes sont conservées pendant trente jours, les données supprimées de votre système en direct persisteront dans les sauvegardes jusqu'à trente jours. Documentez cela. C'est généralement acceptable en vertu du RGPD à condition que votre politique de rétention en tienne compte et que vous n'utilisiez pas les sauvegardes comme moyen de contourner les obligations de suppression. Ce qui n'est pas acceptable, c'est de conserver les sauvegardes indéfiniment parce que personne n'a jamais examiné le paramètre de rétention du travail de sauvegarde.

Pour les processeurs tiers, les demandes de suppression doivent circuler en aval. Cela signifie soit des appels API automatisés pour déclencher la suppression auprès de chaque processeur, soit un processus manuel documenté avec un enregistrement d'achèvement. La plupart des grands fournisseurs prennent en charge les API de suppression. Utilisez-les. Pour les fournisseurs qui ne le font pas, c'est une conversation à avoir avant de leur faire confiance pour quoi que ce soit impliquant des données personnelles.

Le problème des sauvegardes en termes clairs

Les sauvegardes méritent leur propre paragraphe car c'est là que la plupart des programmes de rétention échouent silencieusement.

Une sauvegarde est un instantané ponctuel. Lorsque vous supprimez des données de votre système en direct, cette suppression ne se propage pas aux sauvegardes existantes. Les données supprimées existent toujours dans chaque sauvegarde effectuée avant la suppression. C'est normal et attendu. La question est de savoir combien de temps ces sauvegardes sont conservées.

La réponse dans la plupart des entreprises est « plus longtemps que ce que quiconque ne le pensait ». Les paramètres de rétention des sauvegardes sont configurés une fois et oubliés. Le stockage est bon marché. Personne n'audite la politique de rétention des sauvegardes par rapport à la politique de rétention des données. Le résultat est un cimetière d'instantanés ponctuels contenant les données personnelles d'utilisateurs qui ont supprimé leurs comptes il y a des années.

Revoyez vos paramètres de rétention des sauvegardes maintenant. Alignez-les sur votre politique de rétention des données. Si votre politique stipule que les données sont supprimées après quatre-vingt-dix jours, vos sauvegardes ne devraient pas être conservées pendant un an. Et si vous recevez une demande de suppression pour un individu spécifique, notez dans vos registres que la suppression sera complète une fois la fenêtre de sauvegarde pertinente expirée. C'est la réponse honnête, et elle est défendable.

À quoi ressemble une bonne solution

Un programme de rétention qui fonctionne réellement a quatre propriétés :

Il est automatisé. Les processus de suppression manuels échouent car les gens oublient, tombent malades, quittent l'entreprise et héritent du retard de suppression de ceux qui les ont précédés. Si ce n'est pas automatisé, ce n'est pas un programme de rétention. C'est une bonne intention.

Il est vérifié. Chaque travail de suppression produit un enregistrement de ce qui a été supprimé, quand, et combien d'enregistrements ont été affectés. Les anomalies déclenchent des alertes. L'enregistrement de vérification est conservé. Oui, il y a une certaine ironie à conserver des enregistrements sur vos enregistrements de suppression, mais c'est à cela que ressemble une preuve d'audit.

Il couvre l'ensemble du patrimoine de données. Base de données principale, journaux, sauvegardes, processeurs tiers, entrepôts de données, fichiers exportés lorsque possible. Une application de la rétention qui ne touche qu'à la base de données principale n'est pas une application de la rétention. C'est ranger une étagère pendant que le reste de la maison s'accumule.

Il est testé. Exécutez un travail de suppression sur un ensemble de données de test avant de l'exécuter sur la production. Vérifiez le résultat. Faites-le chaque fois que le travail change. « Le travail de suppression s'exécute » et « le travail de suppression fonctionne correctement » sont des affirmations différentes et vous voulez des preuves pour les deux.