Aux termes du nouveau règlement général de protection des données, qui sera tenu responsable, en cas de problème, au sein d’une entreprise? Le data controller, le data processor, le data protection officer ? Que recouvre ces intitulés de fonction?

Quelles responsabilités pour: l’auditeur, le DPO (délégué à la protection des données), le chef d’entreprise, le sous-traitant d’une solution IT, l’hébergeur Internet / cloud / SaaS … ?

Responsabilité de l’auditeur ?

Quelle est la responsabilité du consultant ou de la société qui procède à un audit préalable, au “privacy impact assessment” (PIA)?

Laurie-Anne Bourdain, consultante spécialisée en cyber-sécurité chez EY (Ernst & Young)

“Tout dépend du périmètre de l’exercice d’évaluation et de la manière dont le contrat a été libellé, de ce qui y est consigné. [Ndlr: voir aussi à cet égard l’article consacré aux contrats]

Souvent un “assessment” s’effectue sur base des informations et des documents qu’a fournis la société. En cas de problème, c’est donc à cette dernière qu’il incombe de prouver qu’il ne manque rien et que les informations fournies étaient correctes.

Le conseil à donner aux entreprises est dès lors d’être les plus complètes possible. Mais on se situe ici dans un contexte d’évaluation de risque. Or, on sait combien il y est difficile de prédire par exemple une violation de données…”

Echo similaire du côté de Philippe Laurent, avocat auprès du capinet MVVP. “Les responsabilités de l’auteur d’une analyse PIA dépendront de ce qui est mentionné dans le contrat [rédigé avec le responsable du traitement]. L’obligation légale d’un PIA incombe toujours au responsable du traitement. C’est lui qui sera soumis à des sanctions.

Mais le fait, pour une entreprise, de faire appel à un spécialiste PIA équivaut à un contrat de sous-traitance. Il faut dès lors préciser quelles sont les obligations de moyens ou de résultat qui sont prévues… Par ailleurs, dans le cadre du contrat, le prestataire tentera probablement de limiter ses responsabilités !”

Frédéric Gelissen, consultant indépendant (ProcSima), estime pour sa part que la société qui procédera à l’évaluation préalable (état des lieux, cartographie des données, évaluation des risques et impacts) ne pourra être tenue pour responsable de problèmes futurs éventuels. Impossible de prévoir, à son avis, tous les scénarios possibles. Bien évidemment, cela ne dédouane nullement cette société ou ce consultant indépendant de faire son travail avec sérieux. “Mais il doit inviter l’entreprise à être la plus ouverte et transparente possible dans l’exposé de la situation. Malheureusement, on n’évitera jamais certaines rétentions d’information ou des oublis… Un scan n’est jamais vraiment complet.”

Ces lacunes peuvent néanmoins être quelque peu minimisées si l’on applique, selon lui, quelques principes de bonne gouvernance. Tels que le fait d’impliquer plusieurs personnes, aux profils et compétences complémentaires, dans l’exercice d’évaluation et en faisant appel, pour chaque nouvelle analyse (situation, impact) – “idéalement une fois par an” -, à d’autres intervenants. Histoire d’avoir des regards différents.

Responsable de traitement et sous-traitants

Première chose, comment définit-on un “data processor” par rapport à un “data controller”? La terminologie anglaise est ici moins précise que son homologue française.

Le “controller” est le responsable du traitement. Le “processor” est le sous-traitant.

Le “controller” est toujours la personne ou la société qui “contrôle” les données, qui en est le propriétaire et le responsable final des traitements.

“Ce peut être une personne, une société voire un groupe de sociétés (par exemple si les traitements sont faits en commun ou si les bases de données sont mises en commun”. On parle alors de “co-controllers”.

Le “processor” est la personne, la société ou l’organisme qui procède réellement au traitement des données, sur ordre ou indications du “controller” (propriétaire).

Dans certains cas, “controller” et “processor” seront une seule et même entité.

Entre ces deux acteurs, “la relation doit être claire”, souligne Laurie-Anne Bourdain. “Il faut définir qui est le controller et qui est le processor, le type de demandes que le propriétaire adresse au “processor”.

Ce dernier est responsable des données qu’il traite. Il doit garantir que les données sont sécurisées, qu’elles sont stockées et gérées dans des lieux sûrs.

En cas de violation, compromission ou fuite de données dont on peut démontrer qu’elle est due à un problème de sécurité dans le chef du processor (sous-traitant) – par exemple s’il a déclaré recourir à des pare-feu ou à des mécanismes de chiffrement et si ce n’est pas le cas, si les mesures prises sont insuffisantes, si la solution a été mal configurée -, la société pourra se retourner contre lui. Par contre, si le processor / sous-traitant a tout mis en oeuvre selon ce qui avait été convenu ou si cela correspond au state of the art, la responsabilité sera partagée.”

Chaîne et cascade

“On se trouve dans un scénario de responsabilités en cascade”, souligne Frédéric Gelissen. La société ne signe de contrat qu’avec un seul interlocuteur. C’est à ce dernier de s’assurer que tous les partenaires et sous-traitants agissent en conformité avec les règles GDPR. En cas de problème ou de manquement, il devra pouvoir se retourner contre les sous-traitants.”

Cela vaut non seulement pour les prestataires de services informatiques qui interviennent au niveau du quotidien opérationnel des sociétés clientes mais aussi pour les différents intervenants qui participeront à l’exercice d’évaluation PIA. “Si l’on décide d’un plan d’amélioration, le prestataire principal devra coordonner les autres et s’assurer que tous font correctement les choses. La cascade de responsabilités devra être claire. Avec aussi une identification claire des contraintes à respecter par chacun afin que personne dans la chaîne ne puisse un jour dire “je ne savais pas”.

Obligation de bonne gouvernance

Philippe Laurent (cabinet MVVP): “Le responsable de traitement doit pouvoir démontrer qu’il a pris en compte toutes les obligations qui lui incombaient et toutes les mesures nécessaires pour se mettre en règle.”

Ces mesures doivent être documentées. Les contrats, notamment, en feront état.

“Tout responsable de traitement doit donc prouver qu’il a procédé aux analyses nécessaires, déployé les outils adéquats, documenté les étapes qu’il a franchies, les processus qui ont été déployés. Dire “j’ai acheté tel logiciel” ne suffit plus. Il faut expliquer pourquoi on a choisi ce logiciel, si on a mis en oeuvre un suivi des déploiements de mises à jour, désigné les personnes responsables de ce suivi.”

Comment “prouver” avoir pris les mesures nécessaires? Par exemple en pouvant présenter des codes de (bonne) conduite et gouvernance, des certifications, des labels…

Nouveauté majeure: les obligations directement et spécifiquement imposées aux “sous-traitants”. Or, la majorité des services IT sont prestés par des sous-traitants, qu’ils soient des prestataires classiques ou des hébergeurs SaaS/cloud…

Les responsabilités imputées au sous-traitant sont étendues par rapport aux dispositions des directives et lois précédentes. “Par le passé”, indique Philippe Laurent, “ses obligations se limitaient à celles que lui imposait le responsable de traitement. Désormais, il endosse, en direct, des obligations qui lui sont propres. Il lui incombe par exemple de tenir un registre des traitements, de coopérer avec l’autorité de contrôle…

Il doit être plus attentif avec ce que ses clients font de leurs données.”

Se dédouaner préventivement?

Si une société procède à une demande d’avis et de vérification préalable auprès de l’autorité de contrôle (Commission Vie privée, pour la Belgique) et si, par la suite, un problème se pose en matière de données, “la société pourra invoquer le fait qu’elle avait reçu et appliqué l’avis de la Commission. L’avis de l’autorité de contrôle est un bon document pour pouvoir montrer patte blanche”, déclare Philippe Laurent.