[GDPR] les nouvelles obligations (Règlement « data protection » 2016/679)

[version enrichie le 5 mai 2017] Le Règlement 2016/679 « GDPR » (ou « General Data Protection Regulation » de son titre officiel en langue anglaise) va imposer 5 obligations vraiment nouvelles à la charge de tout responsable de traitement ET de tout sous-traitant.

Comment ? Non désolé, aucun acronyme officiel en français. C’est simplement le « Règlement 2016/679« . Puisse le plateau de Saclay me pardonner un jour…

1) Le registre des activités de traitement

L’obligation de déclaration des traitements à l’autorité nationale de contrôle est (enfin !) remplacée par une obligation de tenue d’un registre qui responsabilise vraiment les opérateurs de traitements. Obligation qui pèsera à l’identique sur tous les prestataires de la chaine du traitement des données : responsable de traitement, sous-traitant, sous-sous-traitants…

Le contenu du registre ? Une liste des traitements opérés, avec une liste des finalités, une description des catégories de personnes concernées et des données traitées, et enfin une liste des destinataires… Est-ce si difficile à organiser ? La GDPR prévoit que ce registre peut être tenu sous forme électronique (pas de registre coté et paraphé…). Bien entendu, le contenu du registre n’est pas le même selon qu’il soit tenu par le responsable du traitement ou par un sous-traitant. Nous verrons le registre « spécial sous-traitant » dans la présentation dédiée aux sous-traitants (en cours de validation par l’éditeur de la BD).

Le plus surprenant est la rédaction de l’article de la GRDP concernant la taille des entreprises auxquelles cette obligation sera imposée : 

(principe) TOUS les responsables de traitement / sous-traitants;

(exception) SAUF si le responsable / sous traitant est une entreprise de moins de 250 salariés;

(dérogation à l’exception) SAUF :

– traitement susceptible de comporter un risque pour les droits et des libertés des personnes concernées (ce sont les traitements soumis à Privacy Impact Assessment ou « étude d’impact »);

– traitement de données sensibles ou d’infractions pénales;

– (surtout) si le traitement « n’est pas occasionnel« …

2) L’obligation de sécurisation des données

Ce sont les fameuses « mesures techniques et organisationnelles appropriées » (quelle poésie !) que les responsables du traitement, ainsi que tous les prestataires de traitement, doivent mettre en oeuvre. Heureusement, la GDPR prévoit que cette obligation tient compte, notamment, « de l’état des connaissances » et « des coûts de mise en œuvre ».

Donc, d’un coté, il appartient à l’entreprise qui traite des données [personnelles] de prévoir une sécurité de ses traitements conforme à l’état de l’art. Rien de choquant à cela, dans un univers numérique où les technologies évoluent plus vite que le Droit…

D’un autre coté, il faut tenir compte des « coûts de mise en œuvre » de ces mesures de sécurités. A l’entreprise de se livrer à un bilan « coût / sécurité » lorsqu’elle organisera la sécurité de ses traitements. L’idée au final est d’offrir aux personnes dont les données sont traitées un « niveau de sécurité adapté au risque« .

Le risque visé ? c’est celui des failles / fuites de sécurité, les « violations de données« …

Il est intéressant de noter qu’au titre des 4 mesures concrètes de sécurité à envisager par les opérateurs de traitement, figurent en tête de liste de la GDPR « la pseudonymisation et le chiffrement« . Ce chiffrement que le Ministère de l’intérieur français conspue si fréquemment pour permettre de protéger les communications entre terroristes… L’UE est manifestement plus au point sur l’intérêt de l’usage du chiffrement que nos ministres. Ce mouvement tendant à la généralisation de l’usage du chiffrement est encouragé par la CNIL, l’ANSSI, et par tous les professionnels qui veulent donner de la confiance dans l’économie numérique et s’intéressent à la protection des libertés individuelles. C’est aujourd’hui une nécessité. Sauf à se réjouir de l’occurence prochaine d’un « 11 septembre numérique » attendue par un de mes clients avec une résignation qui fait peur.

3) les failles / fuites de données

La GDPR encadre les « violations de données » et la manière dont les entreprises doivent y faire face. Aussi incroyable que cela paraisse à bien des décideurs du monde de l’informatique, il existait très peu d’obligation légale en Europe sur ce point avant la GDPR.

Bien sûr, il y  avait quelques lignes dans la Directive 95/46 qui obligeait (mollement) les sous-traitant Informatique et Libertés à décrire contractuellement les mesures de sécurité de leur SI.

En France depuis 2011, l’article 34 bis de la loi « Informatique et Libertés » avait prévue un premier dispositif de notification obligatoire des failles / fuites de sécurité à la CNIL.

3.1) L’obligation de notification à la CNIL

La GDPR généralise l’obligation de notification à la CNIL de toute faille fuite de sécurité découverte par l’un quelconque des prestataires  de la chaine de traitement de données [personnelles]. Même pour le prestataire SaaS, ou son hébergeur. TOUT le monde. 

Si la faille / fuite se produit chez le sous-traitant, celui-ci en informera son donneur d’ordre qui, à son tour, informera la CNIL. Rédigé comme ça, on pourrait penser que la charge de la preuve du respect de cette obligation pèsera seulement sur le responsable du traitement… Contractuellement, il est certain qu’en cas de sous-traitance, tout le contenu détaillé de la notification d’une faille / fuite de données sera à la charge du sous-traitant si elle est découverte dans son SI.

La « violation de données » recouvre en fait deux notions techniquement différentes : les failles de sécurité » et les « fuites de données ».

La « faille de sécurité » ? C’est le « trou » dans le système d’information d’un prestataire. La « fuite de données« , c’est l’utilisation de cette faille par des malveillants pour copier / modifier / effacer les données. Dans le récent scandale Yahoo! révélé en octobre 2016, c’est l’exploitation d’une faille de sécurité (dont l’origine serait un défaut de mise à jour d’un logiciel…) qui a permis une gigantesque fuite de données avec près d’un milliard de comptes copiés. 

Revenons à notre GDPR : outre le détail du contenu des notifications à la CNIL, chaque responsable / sous-traitant devra « documenter » les failles / fuites rencontrées, ainsi que les mesures prises pour y remédier. Nous en verrons le détail dans les slides. 

Notifier à la CNIL, c’et bien. Et si on informait aussi la personne dont les données ont été exposées à copie illicite / modification / effacement / etc. ?

3.2) L’obligation de communication à la personne concernée

Avec l’obligation de rendre des comptes à la personnes dont les données sont traitées, la boucle vertueuse imposée par la GDPR est bouclée :

  • le professionnel liste les traitements de données auxquels il procède;
  • le professionnel protéger les données qu’il traite;
  • le professionnel informe la CNIL en cas de faille / fuite de données;
  • et le professionnel informe en direct ou publiquement les personnes concernées par une faille / fuite de leurs données.

Les plus ardents défenseurs des libertés numériques ne manqueront pas de critiquer ce dispositif obligatoire de communication limité aux seules « violations de données » « susceptible d’engendrer un risque élevé pour les droits et libertés d’une personne physique« .

C’est à dire seulement pour les traitements ayant fait l’objet d’une étude d’impact (les « traitements à grande échelle« ).

Au titre des exceptions à cette obligation de communication figure les données chiffrées dans le cadre des « mesures techniques et organisationnelles« . Là, félicitons le législateur de l’UE pour le bon sens de son texte. Si les données ont été chiffrées, leur « vol » posera peu de problème, car elle demeureront secrètes pour celui qui ne détient pas les clés de déchiffrement ou ne dispose pas de la puissance de calcul suffisante pour procéder à leur décryptage.

Plus surprenant, la seconde dérogation à l’obligation de communiquer à la personne concernée envisage l’hypothèse « des mesures ultérieures qui garantissent que le risque élevé pour les droits et libertés des personnes concernées n’est plus susceptible de se matérialiser« .

C’est pour éviter tout dérapage dans l’usage abusif de cette dérogation que la CNIL disposera de la possibilité d’imposer la communication au responsable du traitement.

4) BONUS : le « droit/obligation » à transparence

Pour finir de vous faire dresser les cheveux sur la tête, nous ferons un petit rappel du « droit à transparence » imposé par l’article 12 GDPR.

En fait, ce n’est pas tant un « droit » offert aux personnes dont les données sont collectées / traitées, qu’une véritable « obligation » générale qui s’impose aux opérateurs de traitement.

Ce droit/obligation concerne l’ensemble des informations à fournir à la personne concernée lors de toute opération de collecte directe ou indirecte des données, mais également pour les autres droits offerts aux personnes concernées, les fameux « droits GDPR » des article 15 à 22 : accès, rectification, oubli, etc. Ainsi que les droits d’opposition en cas de « prospection », de « profilage » ou de « décision individuellement entièrement automatisée ».

Vu la manière dont ce « droit/obligation » est sanctionné, on peut affirmer qu’il s’agit également d’une véritable obligation nouvelle pour les responsables de traitement !

La normalisation de la mise en oeuvre des obligations de la GDPR

Toutes ces obligations de la GDPR à la charge des entreprises sont très précises et détaillées. C’est la grande difficulté de ce Règlement, d’application directe dans les 28 états membres de l’UE dès le 25 mai 2018.

Alors, dès aujourd’hui, une option est offerte aux entreprises qui traitent des données [personnelles] :

  • soit l’entreprise y fait face, seule : ça va prendre du temps, ça va couter des sous, etc.
  • soit l’entreprise intégre l’intérêt de normes communes de référence de type « code de conduite » ou d’un mécanisme – certes un peu plus lourd – de « certification GDPR » avec audit. 

C’est une volonté politique de l’UE de privilégier ces dispositifs d’auto-régulation pour une industrie dont les techniques évoluent à une vitesse devenue vertigineuse.

Juridiquement, cela se traduit par la possibilité pour tout prestataire de données de prouver sa bonne foi dans le respect des obligations de la GDPR. Si le Code de conduite choisi comme référence est respecté. Ou si la certification est régulièrement contrôlée.

Il ne vous reste plus qu’à visionner les images dans le slider en tête de ce post.

Synthèse de la GDPR et audit ?

Si vous cherchez une synthèse de la GDPR et un début de méthode d’audit, c’est ici qu’il faut cliquer (pour fêter « 1 an » avant l’entrée en vigueur de la GDPR).