Sur cette bonne blague d’introduction, on va causer cette fois de PIA. Article un peu long et pas forcément fun je vous l’accorde, mais nécessaire (on est quand même fin avril).

Les DPIA (Data Protection Impact Assessment), auparavant appelés PIA (Privacy Impact Assessment) ou ÉIVP par chez nous (Étude d’Impact sur la Vie Privée) sont une des nouveautés introduites par le RGPD. Décrivons un peu la bestiole, pour se préparer au jour fatidique où on vous demandera de réaliser ce genre d’étude.

 

Les PIA (on va garder cet acronyme, c’est le plus court, tout le monde sait qu’un bon informaticien est un informaticien fainéant, et même la CNIL dit « PIA » donc voilà, discutez pas) sont donc une partie intégrante du principe de Privacy by design posé par le RGPD.

Petit rappel au passage : on dit « LE RGPD ». Pas « la RGPD ». C’est un Règlement, avec un « R » majuscule et tout ce que ça comporte comme valeur légale. Pas juste une règlementation qui désignerait on ne sait pas quel genre de texte. Un Règlement, le truc de droit européen qui fait que nonobstant le fait que ledit règlement vous ennuie, il s’applique par sa simple existence. Et je veux encore moins entendre de « la GDPR ». Si j’entends ça, je vous assomme avec mon gros classeur rouge « Dispositions particulières de la Loi Informatique & Libertés » (et croyez-moi, vous ne voulez pas subir ça).

D’un point de vue entreprise (souvent et hélas le seul retenu), cette démarche permet de réduire drastiquement les risques associés, d’intégrer ces problématiques en amont et de réduire les coûts. Et, in fine, d’éviter certaines atteintes à son image, en cas de pépin.

 

Introduction

« Grosse maille » (je m’adapte : tout le monde dit ça sur Nantes alors que je n’ai jamais entendu ça à Troyes qui est pourtant, elle, la Cité de la maille), un PIA sert à identifier et réduire les risques associés à la vie privée sur un projet. L’aspect « nouveauté » réside dans le fait que pour la première fois, on se place du point de vue de l’utilisateur final. De la personne concernée par la perte potentielle de vie privée. C’est quand même nettement plus sain, dans la démarche, que de raisonner simplement sur le mode « faut pas que je perde de brouzoufs ».

Le PIA est bien souvent à utiliser en amont de la réalisation d’un projet, le but étant de faciliter la prise en compte des points soulevés par l’étude. Pour autant, il ne faut pas penser que parce que le projet existe déjà, il ne mérite pas une telle analyse : typiquement, si une entreprise envisage de changer de solution technique pour répondre à un besoin existant, cela peut être le bon moment pour conduire une telle étude. A condition, évidemment, que l’entreprise soit prête à intégrer les résultats. Mener un PIA pour ne rien en faire, ben… autant ne pas le faire tout court. Se donner bonne conscience, à un moment, ça ne suffit plus.

Donc, le PIA prend en compte ces deux visions souvent opposées : l’intérêt des personnes (en particulier sur la protection de leur vie privée), et l’intérêt de l’entreprise (risques de perte de confidentialité réduits pour les utilisateurs, donc moins de risque de perte financière ou d’image pour elle). Gagnant-gagnant. Et évidemment, un projet qui traite davantage de données personnelles, voire de données sensibles (santé par exemple), sera probablement associé à un risque de perte de confidentialité plus élevé.

Mener une étude d’impact sur la vie privée n’est pas nécessairement une tâche longue et complexe : il faut « simplement » adopter une rigueur méthodologique proportionnelle aux risques découverts au fur et à mesure de son avancée.

 

 

Un PIA, oui, mais pour quels projets ?

La méthodologie PIA « officielle » parle de… projets. Au sens large. Du coup, les cas de figures sont nombreux :

• nouveau projet info qui va permettre de stocker ou d’accéder à des données personnelles ;
• un entrepôt de données ou plusieurs (ça commence à 2, « plusieurs », hein) entités/entreprises/organisations vont partager, croiser… plusieurs jeux de données personnelles ;
• une nouvelle base de données qui va réunir des jeux de données auparavant séparés ;
• utilisation de données existantes, mais pour une nouvelle finalité, ou pour la même que celle initialement définie, mais de façon plus intrusive ;
• nouveau système de surveillance (vidéo-protection, vidéosurveillance, LAPI… et j’en passe) ou évolution d’un système de surveillance existant (typiquement, ajouter la LAPI ou la détection de mouvement de foule à un système de caméras existant)
• …

 

L’idée, c’est d’appliquer la démarche PIA à des projets spécifiques et identifiés, et idéalement à un stade d’avancement du projet qui permet de prendre en compte ce que vous aurez identifié. Le but, c’est d’agir, pas de se dire « j’ai identifié un risque mais bon je peux pas toucher au système ».

C’est à votre entreprise de décider de qui sera le plus à même de mener telle ou telle étude PIA, et ce n’est pas forcément le DPO, quand bien même il dispose d’une position souvent idéale pour se charger de ces études (ou du moins y tenir un rôle important). Mais bon, toutes les entreprises n’ont (n’auront) pas de Délégué à la Protection des Données. Et selon la structure, un seul DPO n’aura matériellement pas le temps de mener 4, 10, 35… PIA en parallèle.

 

 

Je suis en charge des PIA, komankechfè ?

 

Le plus grand bénéfice que vous puissiez retirer de la mise en place au sein de votre entreprise de la démarche PIA, c’est… de créer votre propre process, et pas d’utiliser l’outil tout préparé de la CNIL, pratique pour les TPE/PME (notamment parce qu’il contient une base partiellement pré-remplie couvrant quelques cas de figure), pas du tout pensé pour les grandes entreprises comme j’ai pu le constater au cours de mes pérégrinations protection-des-données-personellesques, notamment chez SNCF. Plus exactement il peut servir de support, à condition de créer un modèle personnalisé.

Les guides sont suffisants, et les utiliser pour élaborer une méthodologie maîtrisée, adaptée, et surtout que l’on comprend totalement, c’est bien mieux. L’idéal aurait été de s’y prendre plus tôt, et j’imagine que si vous lisez cet article début mai 2018 (publication initiale) c’est que vous n’êtes pas forcément prêts.

Donc, déroulons ensemble les points-clé cités plus haut.

 

Identifier si un PIA est nécessaire

Il s’agit de répondre à des questions génériques, pour déterminer si votre projet présente un risque potentiel quant à la vie privée des personnes concernées. Si un risque est identifié comme important, alors hop, on continue. Pour ça, jetez un œil à l’outil PIA de la CNIL dont on parlait, il est bien fichu.

 

Décrire les flux d’informations

Maintenant, l’idée est de comprendre comment est collectée l’information, qui l’utilise, la transfère, la stocke…

C’est souvent là qu’on se rend compte de transferts possibles mais non-prévus, d’utilisations détournées des données… que du bon, en somme.

Les utilisations futures des données collectées doivent être envisagées (pis ça évitera de devoir repartir de zéro à la prochaine évolution).

Si vous avez déjà des rapports d’audit interne, une cartographie des traitements, un DAT/DAL pour votre traitement… C’est là que ça va se révéler utile !

 

Identifier les risques

Le risque est surtout à apprécier du point de vue de l’individu. L’intrusion dans la vie privée est absolument à prendre en compte. Évidemment, cela ne veut pas dire qu’il faut oublier l’aspect entreprise : atteinte à l’image, sanction pécuniaire, pénales… sont bien dans le scope du PIA.

Les risques identifiés doivent être clairement listés.

Attention avec les identifiants uniques parfois collectés même si l’utilisateur ne fournit pas « activement » de données. Typiquement, les adresses IP, les adresses matérielles des cartes réseau (y compris de vos téléphones), les numéros IMEI… sont identifiantes, et on ne joue pas avec comme on a le nez fait.

 

Identifier et choisir des solutions

Identifier un risque c’est bien, mais le traiter c’est tout de même mieux. On cherche évidemment à réduire les risques identifiés précédemment. Le pied, ce serait un risque qui disparaît, bien sûr, mais on peut aussi parfois se contenter d’un risque accepté, parce qu’on ne peut pas le réduire davantage, ou parce qu’on choisit de ne pas le réduire (ça arrive, souvent pour des raisons de coûts).

Pour chaque solution, évaluez le rapport coûts/bénéfices, comparez-le à l’effet produit sur le risque et aux éventuels effets de bord sur le reste du projet étudié.

Il faut apporter des solutions à chaque risque identifié, jusqu’à ce que vous soyez « satisfait » du risque global résiduel en ce qui touche à la vie privée des personnes.

 

Quelques solutions que j’ai pu voir retenues dans plusieurs entreprises :

• ne pas collecter (ou stocker) certains types de données (notamment les identifiants supposés uniques comme les IMEI des téléphones portables) ;
• revoir les délais de conservation des données à la baisse, prévoir un mécanisme de purge efficace ;
• implémenter des mesures de sécurité adaptées ;
• s’assurer que le personnel est sensibilisé aux enjeux de sécurité / vie privée ;
• développer un processus d’anonymisation robuste (j’insiste sur le *robuste*, c’est réellement compliqué. J’ai beaucoup bossé dessus –mes apprenants de la formation DU DPO de l’UTT en sont témoins, désolé pour eux– et ça pourrait faire l’objet d’un article dédié, mais j’ai cru comprendre quand je parlais de cryptographie que vous n’étiez pas forcément des matheux) ;
• produire des guides, une documentation, pour les utilisateurs : on pourrait y aborder l’envoi de documents à des tiers (données, mots de passe… oui, je vois souvent des données personnelles dans un zip sur WeTransfer, oui je vois souvent des mots de passe être envoyé par mail en clair…) ;
• concevoir les systèmes de façon à ce que les individus puissent exercer leurs droits (accès, rectification…) simplement et par eux-mêmes : ça vous évitera de nombreuses demandes à traiter !
• informer correctement les individus (détail, simplicité) ;
• s’assurer que les sous-traitants présentent des garanties suffisantes quant à la sécurité des données qu’ils pourraient traiter, héberger…

 

 

Résultats de l’étude PIA

Une fois l’étude menée à terme, listez ce qui a été identifié, ce qui a été fait, et ce qu’il « reste ». Chaque mesure a dû être validée par tel ou tel référent/responsable/marketeux digital : formalisez tout ça, hop, une petite signature en face valant « conformité » et on passe à la suite.

Idéalement, produisez un petit rapport à propos de cette étude, et si vous jugez cela opportun (pour une application destinée au grand public par exemple), publiez ce dernier. Les utilisateurs aiment bien la transparence, quand il s’agit réellement de décrire les engrenages dans lesquels passent leurs données (donc, pas comme chez Facebook qui empapaoute de plus en plus les gens sous couvert de « on fait des efforts t’as vu »).

 

Prendre en compte les résultats

C’est un peu une redite, mais bon : s’assurer que les points soulevés par le PIA sont traités, c’est important. Et ne pas oublier le PIA dans un tiroir, idem : il doit suivre le projet sur tout son cycle de vie, et être actualisé si nécessaire.

 

Un process consultatif

La consultation, c’est un concept clé dans le PIA. C’est ce qui permet aux parties prenantes de soulever des problématiques touchant à la vie privée, aux données personnelles, en fonction de leurs propres points de vue et domaines d’expertise.

Se réunir autour d’une table (ou d’une visio, soyons fous), ça se fait autant de fois que souhaité, à toutes les étapes du PIA.

La consultation est à la fois interne (histoire de s’assurer que toutes les perspectives et enjeux sont pris en compte, et qu’on n’oublie rien) et externe (auprès des personnes concernées par le traitement).

 

 

Quelques ressources

On ne va pas réinventer la roue. Vous avez maintenant je l’espère une vue un peu plus claire de ce qu’implique un PIA, en terme de « to-do list » et de charge de travail (ça, ce n’est pas moi qui peut l’estimer, mais vous, qui connaissez vos traitements).

Pour autant, s’il y a quelques ressources à réutiliser, ce sont bien les guides de la CNIL, et en particulier le guide numéro 3, « bases de connaissance » (qui sont reprises dans le petit logiciel). Vous y trouverez une liste assez fournie de mesures à vérifier, classées par thèmes (typologies de données à caractère personnel, anonymisation, chiffrement…), et de solutions génériques.

J’insiste *vraiment* sur l’aspect générique. Le lien n’est pas forcément fait entre ce qui est décrit et d’éventuelles instructions « strictes » de configuration. Par exemple, dans le cadre du chiffrement des disques durs, la CNIL cite VeraCrypt, mais ne décrit ni le fonctionnement, ni le paramétrage recommandé. Idem, pour ce qui est de forcer HTTPS sur le parcours de vente ou de collecte/utilisation de données personnelles, la recommandation est « utiliser un certificat RGS » et « utiliser TLS, et non SSL ». Ce n’est pas suffisant, et il vous faudra fouiner dans la littérature pour trouver une configuration qui va bien. Le cas échéant, je peux aussi fournir des ressources.

C’est dommage, notamment parce que les lignes directrices à respecter sont globalement connues : les contrôleurs de la CNIL savent très bien le niveau réellement attendu, qui est loin d’être aussi binaire que « SSL c’est pas bien et TLS c’est OK ».

Et j’insiste également sur le fait que ces bases, aussi fournies soient-elles, ne doivent en aucun cas être vues comme complètes ! Si un item est manquant par rapport à votre étude, ce n’est pas qu’il n’est pas à prendre en compte, c’est qu’il est à ajouter. Et je dis ça parce que je l’ai constaté…

 

Le guide numéro 2, les modèles, peut aussi être une source d’inspiration bien utile, puisque vous y trouverez des exemples (là aussi, très génériques) de tableaux, de questions à poser, de points à vérifier/décrire pour vos PIA.

 

Vous voilà donc à peu près équipés pour mener votre première étude PIA. Je vous souhaite bon courage dans la dernière ligne droite avant le 25 mai, « force et honneur », et on reparle de tout ça très vite !

 

Mots clés

• RGPD