Analyse d'impact d'une bonne pratique RGPD

Au cœur du principe de responsabilité promu par le règlement européen se trouve l’analyse d’impact sur la protection des données personnelles. Obligatoire en cas de risque élevé, c’est une bonne pratique à observer sur le périmètre le plus vaste possible dans l’organisation.

A bien des égards, le Règlement Général sur la Protection des Données personnelles (RGPD) se situe dans le prolongement de la loi Informatique & Libertés. La France, pionnière en matière de protection des données, a largement inspiré ce règlement européen entrant en vigueur en mai prochain. Les droits des personnes à l'égard des traitements de données à caractère personnel (opposition, accès, rectification, suppression) sont déjà en vigueur ; toute violation des données personnelles doit déjà être notifiée ; le registre des traitements existe dans la pratique dans les entreprises ayant déjà un Correspondant Informatique & Libertés (CIL) ; le délégué à la protection des données (en anglais DPO) est d’abord un juriste, investi d’une mission analogue à celle du CIL.

Cependant le principe de responsabilité change tout. C'est de lui que découle le durcissement du niveau de sanctions, qui a tant frappé les imaginations.

Un effort accru d’analyse

Ce principe exige de la proactivité. On ne demande pas seulement aux entreprises de tenir une cartographie de leur système d’information, mais aussi une cartographie de leurs risques. L’accent est mis sur l’analyse. Quels sont les risques, quels dommages peuvent être occasionnés, avec quelle probabilité peuvent-ils se produire? Telles sont les questions à se poser. La CNIL ne prendra pas le responsable de traitement par la main. Elle peut lui opposer un veto et lui demander de revoir sa copie, mais elle n'a pas vocation à valider quoi que ce soit qui conférerait de la sécurité juridique à l'entreprise.

Le RGPD porte donc un enjeu de gouvernance. Il oblige au réexamen des relations entre le DPO, le responsable de la sécurité du système d’information (RSSI), les directions métiers, la DSI au service de ces dernières, voire l’audit interne. La qualité de cette gouvernance se jugera notamment sur la capacité à exercer un audit technique des applications qui soit indépendant de la DSI. Les grandes entreprises conduisent déjà des audits de sécurité indépendants, mais le contrôle des habilitations dans les applications et des dispositifs anti-intrusion n’exigent pas de compréhension particulière des applications. Protéger les données personnelles, en revanche, exige une connaissance fine des règles de gestion et des processus manuels exécutés en dehors des applications. Cette expertise est a priori peu présente chez les équipes dépendant du RSSI, mais elle est d’autant plus nécessaire que le délai de notification à l'autorité de contrôle d'une violation de données à caractère personnel n’est que de 72 heures.

L’approche par les risques

La deuxième nouveauté majeure apportée par le RGPD est l'approche par les risques. L’approche est introduite à l’article 32, et son corollaire, l’analyse d’impact, est détaillé dans l’article 35. La formulation de cet article 35 est sans doute maladroite, car il y est dit qu'en cas de risque élevé, il faut élaborer une analyse d’impact "sur la protection des données personnelles" (privacy impact assessment, ou PIA), expression que la CNIL retraduira en "étude d’impact sur la vie privée". Mais pour savoir s'il y a risque élevé, il aura bien fallu faire au moins un pré-IA pour qualifier ce risque.

Le régulateur a cependant déjà statué, au point 3 de l’article, que le profilage et le traitement de masse, en particulier, sont "susceptibles d’engendrer un risque élevé". Dans la pratique, tous les processus et toutes les bases de données de la direction commerciale et de la direction des ressources humaines doivent être passés en revue. Dans les autres directions, toute base contenant des données personnelles devrait aussi être incluse au périmètre d’un PIA, même si ces données personnelles ne sont pas exploitées. De plus, certains traitements ponctuels peuvent eux aussi porter un risque élevé, comme la création d’une plateforme de test, une mise à jour de logiciel ou une migration de base chez un sous-traitant. La prudence conseille donc d’adopter un périmètre plutôt large pour les PIA et de pratiquer un "examen continu", ainsi que le recommande le groupe des "CNIL" européennes, dit G29.

Le point 7, sans être une table des matières, dicte les sujets à traiter a minima : "une évaluation de la nécessité et de la proportionnalité des opérations de traitement au regard des finalités", moyen de s’interroger sur la présence de données spécifiées à tout hasard par la maîtrise d’œuvre mais non utilisées, ou sur d’autres servant une finalité qui aurait disparu ; "une évaluation des risques pour les droits et libertés des personnes concernées" et "les mesures envisagées pour faire face aux risques". Si l’entreprise envisage d’utiliser un logiciel d’anonymisation ou de chiffrement, elle le mentionne donc dans l’étude d’impact. Si le processus d’anonymisation doit résulter d’un apprentissage de la machine, cette précision s’impose.

Bien définir le périmètre du traitement

Une analyse d’impact peut couvrir plusieurs traitements. Comme le responsable de traitement a une obligation de consultation de l’autorité de contrôle si "le traitement présenterait un risque élevé [s’il] ne prenait pas de mesures pour atténuer le risque" (article 36), il est préférable de ne regrouper dans une étude d’impact que des traitements de même niveau de risque résiduel.

L’entreprise a également une latitude dans la structuration d’une analyse d’impact en traitements.

Le premier réflexe est de calquer la cartographie des risques d'atteinte à la vie privée sur la cartographie existante des applicatifs. On peut voir ce risque comme un axe d'analyse supplémentaire s'ajoutant aux critères actuels du DICT (disponibilité, intégrité, confidentialité, traçabilité), ou d’étendre la définition du critère de confidentialité, quitte à le repondérer sur les applications existantes. En fait, le périmètre du "traitement" le plus adapté n'est pas forcément contraint par celui d'une base de données ou d'un applicatif en particulier, car les risques sur les données personnelles sont le plus souvent à leur lisière. La réplication de données personnelles d’une application vers une autre application ou vers un support de sauvegarde constitue sans doute la première occasion de fuite de donnée ou de perte de la finalité ayant fait l’objet du consentement initial.

Le niveau de risque, et donc la soumission ou non du PIA à la CNIL, en dépend. Certaines applications pourraient être découpées en morceaux correspondants à différents traitements de données personnelles. Inversement, d'autres pourraient être rassemblées en un seul ensemble correspondant à un seul traitement de données personnelles. Par exemple, un traitement de télémarketing, consistant à envoyer des promotions à la clientèle, et utilisant des données prélevées dans un référentiel client, un logiciel de relation client (CRM) et un logiciel de gestion de campagnes, peut faire une analyse d’impact plus appropriée que 3 analyses correspondant à chacune de ces bases de données. Selon les cas, le remembrement revient à réviser le risque à la hausse ou à la baisse.

Le responsable de traitement n’est pas obligé de rendre public tout PIA. L’entreprise qui cherche à mettre en avant sa responsabilité sociale pourra cependant en tirer avantage. Elle peut publier une synthèse de son ou ses PIA, et mettre en perspective sa politique de gestion des données personnelles avec celles en matière de cyber-sécurité et de transparence des algorithmes, car ces thématiques se recoupent et reflètent des attentes de plus en plus fortes de la société.