Source: https://wiedenhoff.wordpress.com/2013/10/
Timestamp: 2017-08-19 09:10:52+00:00
Document Index: 193397468

Matched Legal Cases: ['art. 22', 'art. 23', 'art. 24', 'art. 25', 'art. 26', 'art. 28', 'art. 29', 'art. 30', 'art. 31', 'art. 32', 'art. 33', 'art. 33', 'art. 34', 'art. 35', 'art. 36', 'art. 37', 'art. 2', 'art.3', 'art. 4', 'art. 6', 'art. 7', 'art. 8']

octobre | 2013 | Matthieu WIEDENHOFF
Pré-version du Règlement Protection de la vie privée – partie 4
Pré-version du Règlement Protection de la vie privée – partie 3
Continuons notre lecture, et passons aux obligations du responsable de traitement et de son sous-traitant (dans le domaine de la protection de la vie privée, le sous-traitant est celui qui agit sur ordre d’un responsable de traitement, c’est un tout petit peu différent de la notion en marché public).
L’analyse des droits des personnes : https://wiedenhoff.wordpress.com/2013/10/23/pre-version-du-reglement-protection-de-la-vie-privee-partie-2
Sur le plan des définitions (art. 22), le responsable du traitement reste identique à la Directive. Par contre, apparaît la notion de cout. En fonction de l’état de l’art et des couts, le responsable doit prendre toutes le mesures raisonnables pour se mettre en conformité. Je vous ai déjà dit que je trouvais qu’il y avait beaucoup de choses laissées à l’appréciation des entreprises, non ?
Les notions de protection de la vie privée par défaut et par la conception font leur entrée( art. 23). Vous m’excuserez, mais je vais rester sur les anglicismes pour ces termes, et parler de privacy by design et privacy by default. Ces notions sont connues et reconnues (et explicites), je ne vais donc pas m’étendre dessus. Par contre, bonne idée de les inclure.
Ensuite, mon article préféré, les responsables de traitement joints (art. 24). Cet article oblige les partenaires à bien établir leurs responsabilités respectives dans les traitements en présence, sous peine d’être responsables conjointement des erreurs de l’un. Je me demande comment les entreprises fonctionnant avec du cloud vont intégrer cet élément (vraie question, ce coup-ci). En effet, un contrat de type Amazon AWS, dans lequel il est écrit qu’Amazon n’est responsable de rien concernant sa plate-forme de cloud, me paraît difficilement justifiable (surtout si c’est Amazon qui a une défaillance de sécurité). Il y aura de la jurisprudence à faire dans ce domaine.
L’obligation d’avoir un représentant sur le territoire de l’UE est maintenue pour les entreprises extérieures (sauf une ou deux exceptions minimes) (art. 25), et le sous-traitant est traité de la même façon que dans la Directive (les conditions ajoutées étant de pur bon sens) (art. 26 et 27).
Puis, au détour d’un article sans surprise ni saveur, paf, le Registre des traitements devient obligatoire (art. 28). Apparu avec le décret de 2005 en France, pour les entreprises ayant désigné un CIL, il s’agit d’un registre regroupant toute la documentation nécessaire pour prouver que les traitements de l’entreprise sont conformes au Règlement. C’est juste dommage qu’il ne soit pas mentionné que ce Registre soit public.
L’article suivant (art. 29) nous explique que les responsables de traitement ont dorénavant l’obligation de coopérer avec les autorités de contrôle (la CNIL en France). Il n’est donc plus possible de s’opposer à un contrôle sur place ? (autre vraie question).
Ensuite, vient l’obligation de garder les données de façon sécurisée (art. 30), obligation toutefois modulée en fonction de l’état de l’art et des couts d’implémentation.
Entre les efforts disproportionnés et les couts d’implémentation, il y a quand même possibilité de ne pas appliquer les ¾ du Règlement… Passons…
Le texte détaille un peu les attentes, et explique qu’il faut plus de protection si on traite des données sensibles. Rien de neuf sous le soleil, c’est une description du minimum vital à faire en entreprise (mais qui souvent n’est pas fait).
Les notifications de violation (art. 31 et 32) font leur apparition, auparavant réservées au secteur des telco. Les lobbyistes et Parlementaires ont beaucoup débattus sur le délai dans lequel il fallait faire public cette violation, la formulation finale étant « sans retard indu » (ou l’art de ménager la chèvre et le chou). Il faut donc expliquer à l’autorité de contrôle ce qui s’est passé, et les mesures prises pour atténuer les conséquences. Les personnes dont les données se seront faites piratées sont aussi prévenues afin qu’elles puissent agir (opposition à sa carte bleu, etc.), à moins que les données soient chiffrées (donc si le site web affiche un logo en vertu de l’article 14 comme quoi les données sont stockées chiffrées, il ne vous préviendra pas s’il est piraté. Même si le chiffrement qu’il utilise est largement insuffisant).
L’analyse d’impact fait aussi son apparition (art. 32a), et a pour but de déterminer les impacts sur la vie privée des personnes concernées du traitement. Elle est obligatoire notamment en présence de données sensibles, de géolocalisation, sur des enfants, des employés, concerne plus de 5000 personnes en un an (les critères sont alternatifs), etc.
Bref, dans la plupart des cas, cette analyse sera obligatoire.
Il faudra la revoir au bout d’un an, ou dès que le traitement connait un gros changement.
Cette étude devra contenir pas mal d’éléments (art. 33), description technique, étude de risque, mesures de protection et autres garde-fous, etc.
Par contre, être obligé de me la repalucher tous les deux ans (art. 33a), NIET. Je n’ai rien contre la reprendre quand le traitement évolue (significativement ou non), voir même après un an ou deux pour être sûr que l’analyse (prédictive) était d’équerre avec ce qui se pratique en réalité ; mais la revoir tous les deux ans, NON.
D’abord parce que si le contexte ou le traitement n’ont pas bougé, l’analyse est toujours valide et il n’est pas nécessaire de la revoir (ou juste une fois pour être sûr que l’on ne s’était pas trompé). D’autre part, en matière de charge administrative inutile, elle se pose là. Un rapide calcul sur la base de mes dossiers au boulot me fait dire que si ce point est adopté, je vais passer 25% de mon temps à envoyer des mails à la DSI et aux directions métiers pour leur demander si un truc a bougé depuis la dernière fois. Et ce temps perdu, ce n’est pas du temps où je peux faire du privacy by design/default.
Vient ensuite un des plus gros changements du texte, la disparition des demandes d’autorisation (art. 34). La Directive prévoyait un régime basé sur les déclarations à l’autorité de contrôle, puis un éventuel contrôle sur place par celle-ci. Dans certains domaines, il fallait attendre (et attendre, et attendre encore) l’autorisation expresse de celle-ci avant de lancer le traitement. Le décret de 2005 que j’ai déjà mentionné avait introduit une procédure super-simplifiée auprès du CIL, où rien n’était à envoyer à l’autorité de contrôle.
Là, le Règlement supprime les demandes d’autorisation, il suffira donc d’envoyer un dossier à la CNIL pour démarrer le traitement. Éventuellement, celle-ci pourra faire des propositions ou interdire le traitement après coup. Mais la machine sera lancée.
Si un CIL a été désigné, ce sera a lui de vérifier que tout est ok. S’il découvre un gros soucis, il pourra saisir la CNIL.
Ne nous faisons pas d’illusion, la CNIL ne verra plus beaucoup de dossiers lui arriver. Le CIL étant un employé du responsable de traitement, il est mal placé pour bloquer un process. Il faut juste espérer que la CNIL redirige ses moyens vers les activités de contrôle…
Le CIL (ou Data Protection Officier)
Le CIL (art. 35) est le Héros des temps modernes, le Chevaliers des veuves et orphelins numériques. C’est lui qui est chargé de calmer les ardeurs des informaticiens découvrant les possibilités du Big Data et du Data Mining (quand c’est combiné, c’est encore pire). Il doit faire passer les aspirations des directions métiers sous les fourches caudines de la protection de la vie privée, car c’est à lui de prendre en compte les aspirations des personnes concernées en matière de vie privée. En d’autres termes, c’est un membre du célèbre « Department of NO »
Toujours est-il qu’il va devenir quasi-obligatoire, les conditions obligeant à en désigner un étant très larges (plus de 5000 prospects/an ? Il faut en désigner un…). Saluons la rationalisation des possibilités de désignation, qui reconnaît la possibilité de les organiser en réseau au sein d’un groupe d’entreprises, ou de le désigner en fonction de l’organisation si particulière des administrations et autres services publics.
La désignation est limitée dans le temps et reconductible, ce qui est censé lui assurer un minimum d’impartialité. Il n’est révocable pendant son office que s’il ne répond plus aux exigences du métier (décrites dans le considérant 75a).
Il est rattaché directement au responsable de traitement (PDG, etc.) (art. 36), et ses missions ne bougent pas vraiment par rapport au décret de 2005, il se voit juste rajouté la mission de veiller à ce que les études d’impact soient menées (art. 37). Regrettons quand même que le statut de ses collaborateurs ne soit pas abordé (car oui, dans certaines structures la charge est si lourde qu’il faut plusieurs ETP pour l’absorber).
Partie 2 – Les droits des personnes
Partie 4 – Sanction, autorités de contrôles, transferts internationaux
Tagué eudatap
Pré-version du Règlement Protection de la vie privée – partie 1
Suite à l’adoption lundi 23/10/13 de la version du Parlement Européen concernant la protection de la vie privée, je vais faire une série d’articles analysant point par point ce texte.
Aujourd’hui, les provisions générales du texte (articles 1 à 10).
Mais tout d’abord, un point de procédure :
Le texte voté lundi soir (et analysé ici) n’est pas la règlementation qui entrera en vigueur. Il s’agit simplement du texte voté par le Parlement Européen. Les gouvernements des 28 (oui, 28, la Croatie est devenue membre de l’UE depuis le début de l’année) doivent avaliser ce texte, ou faire leur propre proposition.
Ils feront certainement leur propre proposition, le texte sur lequel ils travaillent diffère pas mal de celui adopté par le Parlement. Cependant, cette proposition ne sera pas adoptée de suite (vous savez bien que l’administration est lente, alors imaginez quand 28 administrations de nationalités différentes travaillent ensemble…).
S’entamera ensuite une procédure de trilogue (Parlement Européen – Gouvernements des 28 – Commission Européenne) pour arriver à un texte acceptable par tous.
NB : vous noterez la très grande démocratie du processus… Déjà que le texte voté lundi 23/10/13 soir est le fruit de négociations feutrées, sans discussions officielles ; le texte issu du trilogue sera élaboré de façon encore plus obscure et feutrée (les lobbyistes américains doivent être aux anges).
En un mot comme en cent, bien malin sera celui qui arrivera à prédire le contour final du texte. Au pire on peut partir en conjectures, et au mieux analyser ce qu’on a sous la main.
Au plan matériel (art. 2), ça ne bouge pas vraiment, le texte s’applique pour les traitements (papier ou informatique) à but professionnel. Les activités domestiques sont épargnées.
Sont concernées par ce texte (art.3) tous les professionnels exerçant dans l’UE, ou traitant des données de personnes situées dans l’UE (et paf Facebook).
Les définitions (art. 4) ont pas mal bougé.
La définition de donnée à caractère personnel ne change pas, c’est tout ce qui se rapporte à une personne identifiable. Une personne est identifiable si à partir des informations dont vous disposez vous pouvez l’identifier. Ça semble tomber sous le sens, mais c’est assez complexe en pratique. Si je parle d’un toxicomane mineur habitant à Triffoullis-les-Oies (20 habitants), est-il identifiable ? Pour la plupart des gens non, mais pour la pharmacie qui lui fournit son Subutex, oui. Le considérant 23 indique aussi qu’il faut prendre en considération les moyens à disposition et les efforts déployés pour déterminer si la personne est identifiable. Donc si ça fatigue trop Google de croiser ses bases pouir vous retrouver, vous êtes considéré comme non-identifiable et ne bénéficiez pas de la protection de ce texte. Mais rien ne garantit qu’il ne décidera pas un jour de faire l’effort de vous retrouver quand même…
On voit aussi apparaitre la notion de données pseudonymes. Est pseudonyme une donnée à caractère personnel qu’on ne peut raccrocher à son titulaire sans information complémentaire (sic!). On a donc une donnée à caractère personnel dont on doit s’assurer que l’attribut identifiant est séparé de la donnée elle-même. Du coup, imaginons une base de données qui enregistre plein de choses sur plein de personnes. Si mon outil de restitution ne prévoit pas de remontée des noms-prénoms (et autres éléments identifiants), je suis considéré comme maniant des données pseudonymes ? Quelles sont les autres protections à mettre autour ? (pour l’exemple que j’ai donnée, a minima, l’impossibilité de mettre en place d’autres requêtes que celles existantes et qui ne font pas remonter les éléments identifiants). Bref, ces pseudonymes posent de vraies questions, auxquelles les CNIL européennes vont devoir répondre (je me poile déjà en imaginant la CNIL tentant d’aller faire un contrôle de Google AdSense..).
Viennent ensuite les données chiffrées (« encrypted data »). Ce sont des données à caractère personnel que les moyens technologiques rendent illisibles pour toutes personnes non autorisées à les lire. Cependant, tout chiffrage se casse, c’est une simple question de temps. Donc cette catégorie est obsolète dès son origine ?
Vient ensuite une bonne nouvelle. Le consentement. Plus question maintenant de le présumer (en utilisant nos services vous acceptez que l’on revende vos données à qui en veut), le consentement doit résulter d’une action explicite (case à cocher, à condition qu’elle ne soit pas pré-cochée, etc.), et porte sur une finalité spécifique.
Les fuites de données font leur entrée dans les définitions, de même que les données génétiques et biométriques. Pas grand chose à dire à leur sujet, c’est explicite.
Principes dirigeant le traitement
L’article 5 précise les principes qui dirigent les traitements de données. On retrouve les mêmes que dans la Directive 95/46/CE, simplement présentés différemment. Si on veut ergoter, on peut signaler que les données n’ont plus besoin d’être nécessaires au traitement, mais doivent plutôt être le minimum nécessaire pour accomplir la finalité. Différence sémantique, sans grosse conséquence pour la pratique pour le moment (on verra d’ici quelques années si la CNIL sanctionne une société pour avoir enregistré un numéro de fax afin d’envoyer de la pub).
Pour mémoire, les données doivent être collectées et traitées de façon loyale, licite et transparente, dans une finalité déterminée, limitées au strict nécessaire, à jour et pertinentes, conservées pour la durée minimale nécessaire sous une forme qui permet à la personne concernée d’exercer ses droits, sans subir d’altération, sous la direction du responsable de traitement (ouf, vous pouvez reprendre votre souffle).
Les bases légales pour procéder à un traitement ne bougent pas (art. 6), sauf sur deux points. L’intérêt historique, statistique ou scientifique peut justifier un traitement (on y reviendra plus loin), et l’intérêt légitime d’un tiers aussi.
Cette notion d’intérêt légitime était déjà fumeuse dans la Directive, là on rajoute la possibilité de traiter des données en vertu de l’intérêt légitime d’un tiers. Gros problèmes en vue. Ok, quelques gardes-fous sont mis en place (et encore…), mais leur effectivité laisse place au doute. Et quand bien même, j’attends le jour où la CNIL fera une descente sur Palo Alto, Californie, pour contrôler les entreprises de la Sillicon Valley (oui, c’est une pique gratuite).
Vient ensuite une des grosses innovations du texte, tout un article sur la notion de consentement (art. 7). Fini le consentement « version violeur » (elle n’a pas dit « non », m’sieur le juge), maintenant le responsable de traitement doit prouver que la personne a consentie au traitement de ses données pour une finalité spécifique. Être d’accord pour que ses données soient traitées dans le cadre d’un webmail ne signifie pas accord pour que ces mêmes données soient revendues à un tiers. Et si on tente de noyer le poisson (comme Facebook et ses CGU de 14 pages), le contrat est entièrement nul (vous vous en moquez, mais pour un juriste ça signifie des annulations en cascade derrière).
Un article apparait aussi sur les enfants (art. 8) (au passage on notera que les définitions parlent d’un enfant de moins de 18 ans, et dans l’article 8 on parle de moins de 13 ans). Un enfant ne peut consentir à un traitement de données sns l’accord de ses parents, à charge du responsable de traitement de vérifier que c’est bien le parent qui donne l’accord. Il est ironique de noter que créer un profil en ligne (Facebook, Google, forum quelconque, etc. ) est dorénavant considéré comme aussi grave que vendre une maison du point de vue de l’enfant (accord parental exigé).
Les données sensibles (celles que l’on n’a pas le droit de traiter, sauf exception) voient un ajout, la notion de « gender identity ». Amha, ça correspond plutôt à « se sentir homme (ou femme) » plutôt que « sexe (h/f) », mais tant que ce point ne sera pas expliciter noi sur blanc, on court au-devant de GROS soucis. S’il est interdit de traiter le sexe d’une personne, il devient aussi interdit de traiter son prénom (en général révélateur du sexe). Il sera aussi interdit de procéder aux bilans sociaux d’entreprise (lutte contre les discriminations au travail), de même que prendre un congé maternité (car réservé aux femmes). Une panoplie infinie d’ennuis en perspective 🙂 .
Autrement, on y retrouve aussi les notions d’intérêt historique, scientifique ou statistique comme base légale pour traiter ce type de données, mais comme dit plus tôt, j’y reviendrais plus loin. Les archives sont aussi une base légale au traitement de ce type de données.
Pour le reste, ça ne bouge que dans la formulation.
Enfin, pudiquement intitulé « traitements ne permettant pas l’identification », l’article 10 instaure le premier cheval de Troie de ce texte.
Si le traitement ne concerne que des données anonymes ou pseudonymes, la personne concernée n’a plus aucun droit.
Droit d’opposition, d’accès, ou être informé si la base se fait piraté et que vos données sont dans la nature, du moment que c’était des données pseudonymes, vous n’avez aucun droit à être informé (rappel : les données pseudonymes sont des données dont l’élément identifiant est gardé séparément. En cas de piratage, rien n’empêche le pirate de piquer les données et les éléments identifiants).
Tagué données à caractère personnel, protection de la vie privée