Mauvaise gestion du cycle de vie des données

L’audit de gouvernance des données d’une entreprise du secteur de l’énergie a révélé qu’un ancien fournisseur d’analyse de données, dont le contrat avait pris fin trois ans plus tôt, détenait toujours les données opérationnelles de l’entreprise dans son environnement. L’entreprise avait envoyé à la fin du contrat un courriel de sortie demandant la suppression des données. L’équipe de gestion de compte du fournisseur l’avait reçu et transmis à son équipe data. L’équipe data n’avait aucun processus formel de suppression pour les clients sortants. Le courriel avait été reçu, lu, pris en compte, puis classé sans qu’aucune suppression ne soit exécutée, car aucun système ni processus ne transformait un courriel de demande de suppression en une suppression effective. Les données sont restées trois ans dans les systèmes du fournisseur, protégées par les contrôles de sécurité qu’il appliquait à l’ensemble de ses données, accessibles à son personnel et incluses dans chaque cycle de sauvegarde exécuté depuis la fin de la relation. L’équipe de gouvernance ne l’a découvert qu’en rapprochant sa liste de fournisseurs d’une demande d’inventaire des données déclenchée par un nouvel audit réglementaire. Trois ans de conservation non autorisée. Personne n’avait commis de faute intentionnelle. Le processus n’avait tout simplement aucun mécanisme de clôture.

La mauvaise gestion du cycle de vie des données : de quoi s’agit-il vraiment ?

La gestion du cycle de vie des données est la gouvernance des données depuis leur création ou leur collecte jusqu’à leur utilisation, leur conservation, leur archivage et, à terme, leur suppression ou leur destruction. Un cycle de vie des données bien géré garantit que les données ne sont collectées que pour des finalités définies, conservées seulement aussi longtemps que ces finalités l’exigent et supprimées lorsque la finalité est atteinte ou que la durée de conservation expire, avec une documentation attestant que chaque étape a été menée à terme. Le cycle de vie s’applique à toutes les copies des données dans tous les systèmes où elles existent, et pas seulement à l’enregistrement principal.

Le schéma de mauvaise gestion découle d’une asymétrie structurelle entre la gouvernance de la création des données et celle de leur suppression. La création des données est généralement bien encadrée, car la création d’un nouveau dossier client, la conclusion d’un nouveau contrat ou l’intégration d’un nouveau fournisseur déclenchent des activités visibles et documentées qui exigent une autorisation, une documentation et une confirmation. Dans la plupart des organisations, la suppression des données ne bénéficie pas d’une gouvernance équivalente : elle est soit déclenchée par une demande manuelle sans mécanisme d’exécution automatisé, soit automatisée par des politiques de conservation qui ne couvrent pas forcément tous les emplacements des données, soit tout simplement jamais déclenchée, parce que personne n’est chargé de veiller à ce qu’elle ait lieu.

C’est à la fin de la relation que la mauvaise gestion du cycle de vie produit le plus souvent une exposition résiduelle importante des données. Lorsqu’une relation avec un fournisseur prend fin, les obligations de gouvernance des données ne prennent pas fin : les données accumulées pendant la relation doivent être restituées ou supprimées, la suppression doit couvrir toutes les copies dans tous les systèmes, et elle doit être vérifiée plutôt que simplement demandée. La plupart des processus de sortie traitent la moitié « demande » de cette obligation : envoyer l’avis de suppression et recevoir l’accusé de réception. Très peu traitent la moitié « vérification » : confirmer, preuves à l’appui, que la suppression a réellement été exécutée dans tous les systèmes, y compris les sauvegardes, les environnements de développement, les répliques analytiques et les données détenues par les sous-traitants ultérieurs.

La mauvaise gestion du cycle de vie des données se concentre autour de cinq lacunes de gouvernance précises :

Demande de suppression sans mécanisme d’exécution : avis de suppression envoyés et pris en compte sans processus formel qui transforme la demande en suppressions effectives dans tous les emplacements des données
Processus de sortie sans vérification : sortie des fournisseurs qui confirme l’envoi de la demande, mais ne vérifie pas que la suppression a été menée à terme dans tous les systèmes
Lacunes des politiques de conservation pour les données inactives : politiques de conservation qui encadrent les données actives, mais sans mécanisme pour déclencher la suppression lorsque les données deviennent inactives à la fin de la relation ou une fois la finalité atteinte
Gouvernance du cycle de vie s’arrêtant aux systèmes principaux : processus de suppression couvrant les bases de données principales, mais pas les sauvegardes, les répliques analytiques, les environnements de développement ni les données détenues par les sous-traitants ultérieurs
Aucun responsable du cycle de vie : gestion du cycle de vie des données traitée comme une responsabilité partagée, de sorte que personne n’est précisément chargé d’exécuter et de vérifier la suppression

Pourquoi c’est important

La mauvaise gestion du cycle de vie des données est importante pour la TPRM parce que la conservation non autorisée de données, c’est-à-dire leur conservation au-delà de la durée autorisée par la finalité du traitement, crée un risque résiduel pur sans aucune valeur commerciale en contrepartie. Chaque jour où les données subsistent au-delà de leur durée de conservation autorisée est un jour pendant lequel elles peuvent faire l’objet d’une violation, être consultées par des parties non autorisées, être incluses dans un audit réglementaire ou faire l’objet d’une demande d’exercice des droits d’une personne concernée que le fournisseur ne peut pas satisfaire, faute de savoir que les données existent encore. Le risque s’accumule en continu. La valeur apportée par les données est tombée à zéro à l’expiration de la durée de conservation.

La dimension réglementaire est directe et de plus en plus sanctionnée. Le principe de limitation de la conservation du GDPR, la restriction de conservation du CCPA et les exigences de conservation de la HIPAA créent toutes l’obligation de supprimer les données lorsqu’elles ne sont plus nécessaires à la finalité pour laquelle elles ont été collectées. La conservation non autorisée de données personnelles au-delà de la durée autorisée constitue une violation de ces principes, qu’un incident de sécurité se soit produit ou non. L’existence des données dans le système du fournisseur après la durée autorisée, à l’insu du client et sans gouvernance de la part du fournisseur, constitue en soi le manquement à la conformité.

Pour les praticiens de la TPRM, l’évaluation de la mauvaise gestion du cycle de vie exige d’aller au-delà de la question de savoir si le fournisseur dispose d’une politique de conservation pour demander si cette politique comporte un mécanisme de clôture : comment la suppression est déclenchée, comment elle est exécutée dans tous les emplacements des données et comment elle est vérifiée. Une politique de conservation qui existe sur le papier sans mécanisme d’exécution automatisé est une politique sans contrôle. La suppression demandée il y a trois ans et jamais exécutée démontre exactement ce que produit une politique sans mécanisme de clôture.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à considérer la demande de suppression et son accusé de réception comme la fin de l’obligation de gouvernance du cycle de vie des données. La demande confirme que le client a rempli son obligation de demander la suppression. L’accusé de réception confirme que le fournisseur a reçu la demande. Aucun des deux ne confirme que la suppression a été exécutée. L’étape de vérification, c’est-à-dire la preuve que la suppression a réellement eu lieu dans tous les systèmes, est l’étape de gouvernance que la plupart des processus de sortie n’incluent pas et que la plupart des programmes de TPRM n’exigent pas.

Le deuxième échec consiste à ne pas établir la gouvernance du cycle de vie avant le début de la relation. Les durées de conservation, les mécanismes de suppression et les exigences de vérification devraient être précisés dans l’accord de traitement des données plutôt que négociés à la sortie, lorsque la relation a déjà pris fin et que le pouvoir de négociation a diminué. Un DPA qui précise que les données doivent être supprimées dans les trente jours suivant la fin du contrat, que la suppression doit couvrir tous les systèmes, y compris les sauvegardes, et que la preuve de la suppression doit être fournie au client crée une obligation exécutoire relative au cycle de vie. Un DPA muet sur le cycle de vie crée une relation dans laquelle les pratiques de conservation du fournisseur sont entièrement discrétionnaires.

Considérer la demande de suppression et son accusé de réception comme l’achèvement du cycle de vie : la demande a été envoyée, la suppression doit être vérifiée
Aucun mécanisme de vérification de la suppression : processus de sortie qui confirment la communication, mais pas l’exécution
Exigences relatives au cycle de vie absentes du DPA : durées de conservation, périmètre de suppression et obligations de vérification non précisés contractuellement
Périmètre de suppression limité aux systèmes principaux : demandes de suppression couvrant les bases de données principales sans déclencher la suppression dans les sauvegardes, les répliques analytiques et chez les sous-traitants ultérieurs
Aucun responsable du cycle de vie : responsabilité de la suppression partagée plutôt qu’attribuée, ce qui aboutit à une absence d’exécution

À quoi ressemblent les bonnes pratiques

Les programmes matures de gouvernance du cycle de vie des données traitent la suppression comme un flux de travail doté d’un déclencheur défini, d’un périmètre d’exécution défini, d’un délai défini et d’une exigence de vérification définie, et non comme une demande qui peut ou non donner lieu à une action selon que le destinataire dispose ou non d’un processus pour y donner suite.

Application automatisée de la conservation : politiques de conservation dotées de déclencheurs de suppression automatisés qui s’exécutent sans dépendre de processus de demande manuels
Périmètre de suppression exhaustif : suppression à la sortie couvrant les systèmes principaux, les sauvegardes, les environnements de DR, les répliques analytiques, les environnements de développement et les sous-traitants ultérieurs
Preuve de vérification de la suppression : preuve documentée de l’achèvement de la suppression fournie au client, couvrant tous les emplacements des systèmes
Obligations relatives au cycle de vie dans le DPA : durées de conservation, périmètre de suppression, délai et exigences de vérification précisés contractuellement avant le début de la relation
Responsabilité claire du cycle de vie : rôle désigné chargé d’exécuter la suppression et de fournir la preuve de vérification à la fin du contrat

Outils

La gestion du cycle de vie des données exige à la fois des contrôles techniques pour appliquer la conservation et une infrastructure de processus pour vérifier l’achèvement de la suppression.

Gestion du cycle de vie des données : Microsoft Purview, Veritas, OpenText

Les plateformes de gestion du cycle de vie des données offrent une application automatisée des politiques de conservation et des flux de suppression : elles déclenchent la suppression à l’expiration des durées de conservation et génèrent des traces d’audit des suppressions. Les fonctionnalités de gestion du cycle de vie des données de Microsoft Purview appliquent les politiques de conservation dans les environnements Microsoft 365. Pour les praticiens de la TPRM, demander si le fournisseur utilise une plateforme de DLM automatisée avec flux de suppression et journalisation d’audit permet de savoir si la gouvernance du cycle de vie est systématique ou manuelle.

Gestion du cycle de vie des contrats : Ironclad, Icertis

Les plateformes de CLM dotées de fonctionnalités de flux de sortie déclenchent automatiquement les processus de demande de suppression à la fin des contrats, garantissant que la suppression est demandée au bon moment et suivant la réception des réponses et des preuves de vérification. Pour les programmes de TPRM qui gèrent de vastes portefeuilles de fournisseurs, l’automatisation par la CLM évite que des demandes de suppression soient oubliées lorsque des contrats prennent fin sans processus de suivi manuel.

Inventaire et lignage des données : Collibra, Alation, BigID

Les plateformes de gouvernance des données tiennent un registre des emplacements des données dans les différents systèmes, fournissant l’inventaire qui permet à la gouvernance du cycle de vie de couvrir tous les emplacements des données plutôt que les seuls systèmes principaux. Pour les praticiens de la TPRM, demander si le fournisseur tient un inventaire des données à jour permettant une suppression complète dans tous les emplacements permet de poser une question précise sur sa capacité de gouvernance.

Enjeux de gouvernance

Le défi de gouvernance de la gestion du cycle de vie des données tient au problème de clôture. Les programmes de gouvernance des données disposent de pratiques bien établies pour le début du cycle de vie (réception des données, classification, provisionnement des contrôles d’accès), car ces activités sont déclenchées par des événements visibles qui exigent une action. La fin du cycle de vie, c’est-à-dire la suppression qui doit intervenir lorsque la finalité est atteinte ou que la durée de conservation expire, est déclenchée par des conditions de temps et d’événements qui ne suscitent pas forcément la même attention automatique en matière de gouvernance. La suppression exige un responsable, un mécanisme d’exécution et une étape de vérification pour la confirmer. Ces trois éléments font souvent défaut.

Pour les programmes de TPRM, la réponse de gouvernance pragmatique consiste à traiter la clôture du cycle de vie comme une exigence contractuelle plutôt que comme une obligation de courtoisie. Le délai, le périmètre et les exigences de vérification de la suppression précisés dans le DPA transforment la suppression, d’une demande que le fournisseur peut ou non satisfaire, en une obligation qu’il doit remplir et dont il doit démontrer le respect. La clause du DPA est le mécanisme de gouvernance. La preuve de vérification est l’assurance.

Préciser les obligations relatives au cycle de vie dans le DPA avant le début de la relation : durées de conservation, périmètre de suppression couvrant tous les systèmes, délai et exigences de preuve de vérification
Ajouter la vérification de la suppression à la liste de contrôle de sortie : preuve de l’exécution de la suppression dans tous les systèmes, et pas seulement confirmation de la réception de la demande
Suivre les suppressions en attente grâce à la gestion du cycle de vie des contrats : flux automatisé allant de la fin du contrat à la réception de la preuve de suppression
Rapprocher périodiquement la liste des fournisseurs actuels de l’inventaire des données : repérer les données d’anciens fournisseurs qui subsistent dans les environnements de données actifs
Exiger des fournisseurs un responsable désigné du cycle de vie : qui est chargé d’exécuter la suppression et de fournir la preuve de vérification

Si vous êtes une petite équipe

Réalisez un audit que la plupart des programmes de TPRM n’ont jamais mené : rapprochez votre liste de relations avec des fournisseurs terminées de votre inventaire des données afin d’identifier les anciens fournisseurs qui pourraient encore détenir vos données. Pour chaque relation terminée depuis plus de trois mois pour laquelle vous ne pouvez pas produire de certificat de vérification de la suppression (non pas une demande de suppression, mais une vérification de la suppression), ouvrez une demande de suivi. Les données que l’entreprise du secteur de l’énergie a trouvées trois ans après la fin du contrat n’ont pas été découvertes grâce à une gouvernance proactive. Elles l’ont été grâce à un audit qui a comparé ce qui aurait dû être supprimé à ce dont on savait qu’il existait encore.

Rapprocher les relations avec les fournisseurs terminées de l’inventaire des données : repérer les conservations non autorisées
Distinguer dans vos registres les demandes de suppression de la vérification de la suppression : les premières relèvent de la communication, la seconde de l’assurance
Ajouter les exigences de périmètre et de vérification de la suppression lors du prochain renouvellement de votre DPA
Attribuer la responsabilité du cycle de vie à un rôle désigné dans les procédures de sortie des fournisseurs

Ce qu’il faut exiger

Demandez directement :

« Lorsque notre contrat prendra fin et que nous demanderons la suppression de nos données, quel est votre processus formel pour exécuter cette suppression dans tous les systèmes (bases de données principales, sauvegardes, environnements de développement et sous-traitants ultérieurs) et quelles preuves fournissez-vous pour en vérifier l’achèvement ? »

« Qui, précisément, est chargé d’exécuter la suppression des données et de fournir la preuve de vérification à la fin du contrat ? S’agit-il d’un rôle désigné doté d’un processus défini, ou d’une responsabilité partagée qui dépend de la réception du bon courriel par les bonnes personnes ? »

« Pouvez-vous confirmer que vous ne détenez aucune donnée issue de relations clients terminées depuis plus longtemps que la durée de conservation que vous avez fixée, et à quand remonte votre dernière vérification d’inventaire en ce sens ? »

Preuves attendues

Documentation du processus de suppression : flux formel allant de la demande à l’exécution puis à la vérification
Responsable désigné du cycle de vie : rôle précis chargé de l’exécution et de la fourniture des preuves
Preuve de vérification de la suppression lors d’une sortie de client récente, démontrant que le processus fonctionne
Confirmation de l’inventaire des conservations non autorisées : date de la dernière vérification et résultat

Un fournisseur qui répond à la question sur le processus de suppression par « nous traitons les demandes de suppression dès leur réception » a décrit une intention de donner suite aux demandes. Demandez précisément quel est le flux formel qui transforme une demande reçue en suppression effective dans tous les systèmes et qui génère des preuves de vérification. L’intention d’agir est le point de départ. Le flux qui garantit que l’action a lieu est le contrôle.

Comment le prouver

La limitation de la conservation prévue par le GDPR, les droits de suppression prévus par le CCPA et les exigences d’élimination de la HIPAA créent toutes des obligations qui s’étendent à la vérification de la suppression, et pas seulement à sa demande. Démontrer la diligence raisonnable exige de prouver que la suppression a été exécutée et vérifiée, et pas simplement demandée.

Documentation des obligations relatives au cycle de vie dans le DPA : durées de conservation, périmètre de suppression et exigences de vérification précisés
Preuves de vérification de la suppression pour les relations avec des fournisseurs terminées : certificats ou équivalents couvrant tous les systèmes
Registres des listes de contrôle de sortie incluant l’achèvement de l’étape de vérification
Registres d’audit de l’inventaire des conservations non autorisées

À retenir

Les programmes de gouvernance des données sont construits autour de la création. La classification a lieu lors de l’intégration. Les contrôles d’accès sont provisionnés au début de la relation. Les revues de sécurité ont lieu pendant la relation. La suppression est l’étape de gouvernance qui clôt le cycle de vie, et c’est celle que la plupart des programmes n’ont aucun mécanisme fiable pour mener à terme. La demande de suppression est envoyée. L’accusé de réception est reçu. Les données subsistent pendant trois ans, parce que l’accusé de réception n’était pas une suppression et que personne n’était chargé de vérifier la différence. La mauvaise gestion du cycle de vie ne résulte ni d’une négligence ni d’une intention. Elle résulte d’un processus qui encadre le début et le milieu et traite la fin comme facultative. La fin n’est pas facultative. C’est là que le risque créé par la relation est soit résolu, soit reporté indéfiniment.