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).

Les différents textes :

La directive 95/46 CE (celle encore en vigueur) est trouvable là : http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:fr:HTML

Le texte voté lundi 23/10/13 ici : http://t.co/UN1D7mIzZh

L’analyse des dix premiers articles du texte : https://wiedenhoff.wordpress.com/2013/10/23/pre-version-du-reglement-protection-de-la-vie-privee-partie-1

L’analyse des droits des personnes : https://wiedenhoff.wordpress.com/2013/10/23/pre-version-du-reglement-protection-de-la-vie-privee-partie-2

Généralités

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.

Procédure de déclaration

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

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s