Vous êtes dans : Accueil > Tribunes libres >

Ce que le DPO n’est pas

Cédric Cartau , MARDI 10 DéCEMBRE 2019

Il arrive assez régulièrement que des confrères DPO me contactent pour me signaler certaines de leurs difficultés dans l’exercice de leur mission. Elles tournent régulièrement autour du même sujet : leur responsable de traitement (RT) refuse de mettre en œuvre les préconisations de sécurité dudit DPO, entendre par là les mesures destinées à réduire les risques identifiés. Le confrère en question me demande alors comment contraindre le RT à appliquer les mesures préconisées. Il me semble qu’il y a là une erreur de positionnement, qui vaut bien un billet.

Les articles 38 et 39 du RGPD sont tout à fait explicites : le DPO a un rôle de conseil et d’alerte, il ne reçoit pas d’instructions (au sens où personne n’a à lui dicter ses actions) et il est indépendant. Prenons l’exemple d’un traitement qu’un RT voudrait mettre en place : si le RT contourne le DPO (intentionnellement ou non), il contrevient clairement à l’article 38-1 qui stipule que le DPO doit être « associé à toutes les questions relatives à la protection des données à caractère personnel » pour pouvoir être en mesure, justement, de jouer son rôle de conseil et d’alerte. Dans un tel cas, la responsabilité du DPO serait totalement dégagée, et celle du RT doublement engagée si un contrôle des autorités relevait à la fois un manquement au RGPD et l’absence de consultation du DPO.

Le RGPD semble considérer qu’il n’est pas du ressort du DPO de réaliser une appréciation des risques – il doit plutôt assister le RT dans la réalisation de celle-ci –, même si dans les faits le niveau technique semble plutôt relever des compétences d’un DPO que de celles d’une MOA. On m’a rapporté un jour le cas d’un RT qui refusait obstinément un risque en particulier dans l’analyse réalisée par le DPO, et qui posait comme condition à la signature du PIA le retrait du risque en question (ce cas semble rare). Si le DPO acceptait de retirer cette ligne de son analyse des risques, il commettrait une erreur : en cas de survenance du risque correspondant justement à cette fameuse ligne et en cas de contrôle de la Cnil, il lui serait reproché de n’avoir pas mentionné ce risque dans son analyse (vous vous doutez bien que celui qui lui avait demandé de retirer cette ligne serait alors subitement atteint d’une amnésie généralisée, le laissant Gros-Jean comme devant). La réponse est simple : le DPO ne reçoit pas d’instructions, personne n’a à lui dire quelle analyse il doit faire de telle ou telle situation ; dans ce contexte, il est seul avec sa conscience. Le RT peut parfaitement refuser de signer le PIA, mais, dans ce cas, le DPO doit matérialiser le fait que, tel jour et à telle heure, le PIA a été présenté au RT qui a refusé de le signer et consigner ce dysfonctionnement dans son rapport annuel. Si, de plus, le risque en question est majeur (ce qui était le cas dans l’exemple cité), en cas de survenance du risque, le RT, (qui non seulement a voulu mettre le problème sous le tapis, mais en plus n’a rien fait pour le régler) devrait se justifier doublement auprès des autorités de contrôle, alors que le DPO serait quant à lui exempt de tout reproche. La traçabilité des échanges est très clairement l’assurance-vie du DPO.

Évidemment, cette position du DPO, confortable par certains aspects, peut être déroutante par d’autres. Un RT pourrait parfaitement valider une appréciation des risques, et néanmoins décider de ne prendre aucune des mesures recommandées par le DPO. C’est le problème du RT et de lui seul. Le DPO doit « faire son deuil » de sa capacité à imposer à un RT des décisions nécessaires à ses yeux, mais pour lesquelles il n’est justement pas décideur : c’est le RT et lui seul qui décide, ou non, de suivre les recommandations du DPO et il est souverain dans cette décision. Une fois que le DPO s’est bien assuré que son rôle de conseil et d’alerte a été joué, et que le RT a bien compris les risques encourus, ce qui suit n’est pas de son périmètre de décision. Le RT est propriétaire de ses risques, et jusqu’à preuve du contraire ce n’est pas le DPO qui dirige l’entreprise.

Des situations cocasses peuvent résulter des différences d’appréciation entre le DPO et le RT (et les exemples qui suivent sont bien entendu caricaturaux et ne servent qu’à illustrer le propos de l’article). Imaginons une MOA qui demanderait à son DPO de réaliser la compilation de tous les risques RGPD de l’établissement : le DPO serait en droit de retourner la question et de répondre à sa MOA que c’est à lui, le DPO, de demander à sa MOA un état des lieux des risques RGPD de l’établissement, thème qu’il choisit justement pour son prochain audit RGPD. Inversement, sur un dossier bien tordu dont le DPO voudrait se mêler, la MOA pourrait tout à fait signifier au DPO que ses services ne sont pas requis et refuser par ailleurs de répondre à la demande d’audit du DPO sur ce traitement (refus que le DPO devra bien entendu consigner dans son rapport annuel). Dans le même registre, si un RT demandait au DPO de réaliser l’analyse des risques d’un traitement, ce dernier pourrait refuser au motif qu’elle ne relève pas de sa mission, qui se borne éventuellement à fournir une méthode d’analyse de risque documentée à laquelle il peut former le RT. Le RT pourrait, en contrepartie, refuser d’appliquer ladite méthode en argumentant avoir déjà la sienne.

Plus sérieusement, il est important de retenir cette dualité entre celui qui a un rôle de conseil, et celui qui décide en étant propriétaire de ses actifs (et les risques en font partie). Un DPO dont 100 % des recommandations ne sont pas systématiquement suivies ne doit pas le prendre comme une attaque personnelle, mais simplement comme le fait qu’une MOA fait face à une somme de contraintes multiples (dont le RGPD fait partie mais n’est qu’une composante), que diriger, c’est faire des choix et que parfois le choix n’est pas celui d’une conformité à 100 %. Enfin, un DPO qui irait souvent au clash avec ses RT devrait se poser des questions sur sa pratique professionnelle.

Ah, j’allais oublier : RSSI c’est pareil.

#RGPD#sécurité