Dans le dernier blog de cette série, j’ai discuté des mérites de la rédaction de données sensibles ou de l’identification des champs plutôt que d’essayer de supprimer intégralement les enregistrements dans un système ERP, en particulier SAP.
Maintenant, j’aimerais expliquer comment nous avons exploité cette approche avec l’un de nos clients, MAPA GmbH. C’est une histoire intéressante car elle incarne différentes facettes des réglementations RGPD ; confidentialité par conception ( « privacy by design » ), minimisation des données et rôle d’un processeur par rapport à un contrôleur.
Réaction par rapport à de nouveaux droits (et des droits existants mais mal connus)
J’ai commencé à travailler avec MAPA avant l’entrée en vigueur du RGPD. Avec une sélection d’autres clients, nous avons écouté attentivement leurs exigences RGPD afin d’adapter nos solutions pour répondre à leurs besoins et à ce dont nous pensions que les autres auraient également besoin. Le défi étant, bien évidemment, que le RGPD n’est pas du tout contraignant. Il donne des principes directeurs, plutôt que des éléments fermes et exploitables pour une équipe IT. Nous avons donc immédiatement vu les différentes interprétations des besoins d’un système SAP pour nos différents client, et le plus important, nous avons vu ces interprétations évoluer avec le temps. Même si c’était un peu troublant au début, je pense que cela a également aidé toutes les parties impliquées à réaliser que ce n’était vraiment pas un exercice ponctuel.
Le RGPD est un engagement continu envers la confidentialité des données et les bonnes pratiques. Le premier domaine d’intérêt avec tous nos clients consistait à savoir comment gérer les demandes d’accès (SAR ou DSAR si des données sont ajoutées en tant que préfixe), puis que faire si cette SAR conduisait à l’oubli d’une demande. Nous avons développé une technologie pour les deux, la deuxième exploitant la rédaction, bien entendu. Il était intéressant de voir que dans la construction des politiques de rédaction, l’idée de périodes de conservation commençait déjà à faire surface. Beaucoup de nos clients voulaient analyser les demandes d’anciens employés et utiliser le nombre d'années écoulées depuis leur départ de la société pour déterminer les éléments à supprimer ou rédiger. Dans de nombreux cas, l’identité n’était pas supprimée, il s’agissait de parties spécifiques des données pour lesquelles ils ne pensaient plus avoir de raisons légales de conserver.
Règles de conservation proactives
À l’entrée en vigueur du RGPD, la plupart des organisations utilisant notre logiciel RGPD travaillaient toujours de manière réactionnaire. Si quelqu’un demandait à ce que certaines ou toutes ses données soient supprimées, un effacement était effectué. Mais les éléments constitutifs des règles de conservation étaient là. L’entreprise avait participé à des discussions sur les données à supprimer et à quel moment. Et, lentement mais sûrement, la pression est venue des équipes juridiques ou d’audit qui demandaient une réponse plus proactive. En 2017, j’ai rédigé un blog concernant les règles de conservation et la différence de signification pour une équipe IT par rapport à une équipe juridique ou d’audit. Et je pense que cet alignement de mentalité ou de prise de conscience du statut actuel des données qui ont passé le délai de conservation a poussé les organisations, comme MAPA, à commencer à créer des règles de conservation pour leurs processus périodiques.
Nous avons débuté avec un délai de 18 mois pour les données de commande client qui résident dans SAP en tant d’adresses et certaines entrées de test pouvant s’avérer sensibles ou non. Nous avons effectué un nettoyage massif des données d’historique, en traitant environ 400 000 commandes historiques en un weekend. Dans le temps qu’il a fallu pour planifier, tester et exécuter le nettoyage de l’historique, les instructions concernant la conservation en cours sont passées de 18 à 12 mois. Nous avons conçu un processus à exécuter mensuellement et avons enquêté sur la part de ce processus à automatiser. Je crois fermement aux vertus du perfectionnement manuel avant de passer à l’automatisation et cela ne faisait pas fait exception. Mais nous commencions aussi à réfléchir aux cas exceptionnels. Combien de commandes nous attendions-nous à prélever chaque mois ? Devions-nous alerter ou arrêter si le nombre de commandes trouvées était dépassé sur un mois donné, ou si les commandes du mois précédent n’avaient pas encore été traitées ? Pendant que nous étions aux prises avec ces réflexions, la situation a changé de façon significative.
Obligations de processeur comparées à un contrôleur
Une partie des données « de commande ponctuelle » proviennent d’un Marketplace partenaire spécifique et non du propre site Web de MAPA ou d’autres sites de revente. Lors du renouvellement de l’accord avec ce fournisseur du Marketplace, un questionnaire sur la confidentialité des données doit être rempli. Les options concernant la période de conservation des données s’étendaient d’une toute petite période à l’option la plus élevée « supérieure à 180 jours ». Cela signifiait que la nouvelle stratégie de conservation en place était dans la même option de liste déroulante qu’avant ! Le rôle de MAPA, sur son propre site Web et les autres sites de revente partenaires, était celui de « contrôleur des données ». L’entreprise était propriétaire de la relation avec le client et définissait ses politiques de confidentialité des données. Cependant, aux yeux du Marketplace, MAPA agissait simplement en tant que processeur des données soumis au RGPD.
Deux cas importants de violations des données et d’amendes (British Airways et les hôtels Marriott) ont été causés pas des erreurs réalisées par un processeur de données et non l’organisation principale. Mais les amendes et l’atteinte à la réputation ont été attribuées au seul contrôleur. Ce qui explique pourquoi un partenaire qui agit en tant que contrôleur des données voudrait insister pour réduire la période de conservation. MAPA a été contrainte de limiter la durée de conservation des données sur le Marketplace à 30 jours. Cela signifiait donc un changement significatif pour notre projet. Avec une période de conservation de 30 jours, nous nous sommes vite rendu compte que le processus devait être exécuté quotidiennement. Sinon, la période de conservation serait descendue à 23 jours pour un traitement hebdomadaire et même à zéro jour pour un traitement mensuel ! C’est à ce moment que MAPA a eu la bonne idée d’examiner le processus commercial et a réalisé qu’une partie du processus pouvait être réorganisée pour s’assurer que les données ne restaient jamais sur le système SAP. Le besoin très temporaire d’identifier le client par son nom et son adresse pour l’expédition pouvait exister en dehors de SAP, ce qui signifie que notre processus de conservation pouvait revenir à un processus mensuel plus gérable. Les données traitées au nom du Marketplace seraient réduites au stricte minimum requis pour répondre aux obligations du contrat.
Je pense que le parcours de MAPA à travers ce processus commercial aide vraiment à montrer que le RGPD est en fait incroyablement bien pensé et que ses principes ont conduit à une amélioration de la protection des données pour tous leurs clients.
Leave a Comment: