RGPD (3/4) : seconde plongée au cœur du RGPD

L’une des grandes nouveautés du RGPD est l’extension des obligations et principes aux sous-traitants (articles 4 et 28 du RGPD).

Bien entendu, cela s’applique à chaque sous-traitant ayant un accès partiel ou complet aux données personnelles, pour chaque traitement.

• Parfois le sous-traitant peut être co-responsable du traitement, si toutes les opérations d’un traitement lui sont déléguées (depuis la collecte, en passant par le stockage, jusqu’à l’exploitation des données et la gestion des demandes d’exercice des droits des personnes) ;
• Dans le cas, a priori plus courant, où l’entreprise est responsable du traitement, et ne sous-traite qu’une partie du traitement (par exemple le stockage, l’exploitation des données, ou la maintenance), si ses sous-traitants ont accès à des données personnelles, ils ont des obligations et devoirs similaires au responsable (le commanditaire reste toutefois le seul responsable).

Exemple typique : une entreprise se charge de la collecte et de la définition de la finalité d’un traitement, puis délègue l’exploitation des données à un sous-traitant (à des fins d’analyse par exemple) : le sous-traitant ne peut naturellement pas être tenu pour responsable si le commanditaire n’a pas demandé le consentement, mais il est responsable pour les autres obligations (principes, droits, etc.) du RGPD.

→ Pour ces raisons, il ne faut pas transmettre de données personnelles à un sous-traitant, s’il n’a pas réellement besoin de ces données pour la réalisation de son contrat de sous-traitance. Ce qui implique :

• Soit de supprimer les données personnelles de l’ensemble des données envoyées (si celles-ci ne sont pas indispensables au traitement par le sous-traitant), ce qui est la meilleure solution en règle générale ;
• Soit d’anonymiser toutes les données personnelles (si celles-ci ne sont pas indispensables au traitement par le sous-traitant). Le RGPD parle plutôt de pseudonymisation (article 4 du RGPD), qui est un cas particulier d’anonymisation, cette dernière étant plus générale (voir notre précédent article sur l’anonymisation). L’idée étant de remplacer les données personnelles par des données pseudonymisées ne permettant pas au sous-traitant d’identifier les personnes (du moins pas sans des informations confidentielles et conservées uniquement par le responsable).

En matière de sécurité, il est évident que la suppression ou la pseudonymisation (ou plus généralement l’anonymisation) des données personnelles doit être réalisée en amont, par l’entreprise responsable, avant le transfert au sous-traitant. En effet : si ce dernier reçoit les données personnelles, puis se charge de les supprimer ou de les pseudonymiser, il est déjà trop tard : les données sont sorties du système d’information de l’entreprise (puisque le sous-traitant en a reçu une copie) !

→ Nous avons vu que le RGPD étendait les obligations, les devoirs et la responsabilisation aux sous-traitants, mais le RGPD l’étend également à l’ensemble des collaborateurs de chaque entreprise.

En effet, au sein d’une entreprise (responsable ou sous-traitant de traitements contenant des données personnelles), de nombreux collaborateurs ont, ou peuvent avoir, accès à ces données (selon la finalité de chaque traitement) : direction, exploitants, administrateurs système, développeurs, experts métiers, analystes, personnels administratifs, ressources humaines, etc.

Ils doivent tous être régulièrement sensibilisés et formés aux problématiques, aux bonnes pratiques et au respect des données personnelles, à la sécurité (notamment des données personnelles), et également au RGPD de manière plus générale. Et il ne faut pas oublier les mouvements de personnel : arrivées de nouveaux collaborateurs, de stagiaires, changements de poste, etc.

→ Ceci est l’occasion de rappeler que la sécurité et la protection des données (personnelles et autres) est l’affaire de tous !

La sensibilisation et les formations sont l’une des missions du DPD, ce qui nous amène naturellement à la section suivante.

La première question est évidement de savoir si vous avez obligation ou non de nommer un DPD (Délégué à la Protection des Données personnelles). La réponse n’est pas toujours simple, elle dépend du métier de votre entreprise, de la fréquence et du volume de données personnelles traitées, de la portée de vos traitements (articles 37 à 39 du RGPD).

Bien que le RGPD ne fournisse pas de seuil précis à partir duquel le DPD devient une obligation, on peut raisonnablement avancer que si l’un de vos traitements est régulier (plusieurs fois par jour), ou que son volume est important (de l’ordre de plusieurs milliers de données personnelles ou plus), ou qu’il est systématique (toutes les données d’un groupe de personnes, ce groupe évoluant avec le temps), vous devriez sans doute désigner un DPD.

→ Dans la suite, nous supposerons que vous avez besoin d’un DPD. Le DPD est un profil très particulier, comme vous allez le constater :

• Il doit être indépendant de la direction (= ne reçoit par d’ordre de la direction, mais il doit lui rendre compte) et l’entreprise doit garantir son indépendance et l’absence de conflits d’intérêts. Par exemple le DPD ne peut pas prendre part à des traitements de données personnelles dans l’entreprise. De plus, il ne peut être sanctionné ou pénalisé dans le cadre de sa mission de DPD ;
• Il doit avoir un contrat de mission spécifique, avec des ressources allouées suffisantes, mais pas nécessairement dédiées (budget, collaborateurs, temps de formation, etc.) ;
• Toutefois, ses fonctions de DPD ne sont pas nécessairement exclusives : il peut avoir d’autres fonctions au sein de l’entreprise, et il n’est pas non plus forcément dédié à votre entreprise : il peut être externalisé et/ou partagé entre plusieurs entreprises (cela sans entraîner de conflits d’intérêts) ;
• Il doit avoir des compétences en droit (évident), en sécurité (protection des données personnelles), en management (délégation de certaines tâches, supervision), en organisation (procédures à mettre en place)… Ce qui en fait un « oiseau rare » tant ces compétences sont difficilement réunies en une seule personne. Heureusement rien n’interdit que la fonction de DPD soit remplie par plusieurs personnes, chacune spécialisée dans un domaine particulier ;
• Le DPD doit être déclaré à l’autorité de contrôle, et communiqué à toute personne qui en fait la demande, ainsi qu’à vos clients et/ou vos sous-traitants. A priori, il n’est pas nécessaire de désigner nominativement une unique personne (puisque la fonction peut être assurée par plusieurs personnes), il faut au moins fournir un moyen de contact simple et efficace : typiquement une adresse de courriel (liste de diffusion) peut convenir ;
• Le DPD doit être consulté avant la mise en place de tout traitement, ceci afin de pouvoir effectuer une analyse des risques sur les données personnelles (nommée PIA pour Privacy Impact Assessment, article 35 du RGPD), de donner son avis et ses recommandations, etc. Le RGPD n’indique pas explicitement qu’il dispose d’un droit de veto, mais en cas de contrôle, si l’entreprise n’a pas respecté l’avis ou les recommandations du DPD, cela pourrait être considéré comme un facteur aggravant ;
• Il a également une mission de conseil, et d’écoute pour toutes questions (internes ou externes) relatives aux données personnelles, aux droits des personnes… Il est notamment celui qui coopère avec l’autorité de contrôle ;
• Enfin le DPD est soumis au secret professionnel.

Voici quelques remarques complémentaires concernant les DPD :

• Pour ceux qui connaissent déjà la fonction de CIL (Correspondant Informatique et Libertés) liée à la loi CNIL, le CIL n’est pas équivalent au DPD pour le RGPD : les compétences requises, les fonctions et les missions ne sont pas les mêmes. Toutefois, un CIL étant déjà sensibilisé aux problématiques relatives aux données personnelles, il peut être un bon candidat à ce poste, à condition d’acquérir les compétences (formations) qui lui manquent.
• Il faut rester pragmatique : en 2018, le profil de DPD est rare (car nouveau), complexe (par l’étendue des compétences qu’il doit posséder) et pour l’instant sans doute un peu surévalué (financièrement). Il est donc difficile de trouver un « vrai » DPD (notamment dans les plus petites entreprises). Mais cela peut être une opportunité de carrière pour un collaborateur motivé (DPD interne), ou l’occasion de fédérer un DPD avec plusieurs entreprises (DPD externe).

→ Restez vigilant : il y a déjà des tromperies autour du DPD (et plus généralement du RGPD). Vu la forte demande, des personnes peu scrupuleuses pratiquent de l’hameçonnage, ou proposent des services externalisés de DPD sans en avoir réellement les compétences (pour elles, le risque est faible étant donné le niveau d’indépendance du DPD d’après le RGPD). Il y a bien évidemment de réels services professionnels et compétents, mais on constate déjà des offres de « DPD complet », qui ne proposent en fait qu’une partie des compétences requises (juridique, ou management, ou sécurité…).

Une autre nouveauté du RGPD est la constitution et la bonne tenue de registres des activités des traitements (article 30 du RGPD). Ces registres permettent de conserver les traces de toutes les opérations (manuelles ou automatiques) portant potentiellement sur des données personnelles, pour l’ensemble des fichiers gérés par votre entreprise. Concernant la forme des registres, le RGPD n’impose rien (bases de données, fichiers ou « fait main ») à part qu’il faut qu’ils soient lisibles (et bien sûr sécurisés).

→ Ces registres permettent de répondre aux questions « QQOQCCP » (Quoi, Qui, Où, Quand, Comment, Combien, Pourquoi) et ils constituent un élément factuel et formel pour les contrôles de l’autorité, mais aussi pour les questions de vos clients ou de votre entreprise elle-même.

Les types d’accès peuvent être de différentes origines, notamment :

• Accès par les utilisateurs (humains) métiers : utilisation normale dans le cadre de la finalité du traitement ;
• Accès par les exploitants (humains) : déploiement, mise à jour, etc. ;
• Accès par la maintenance (humains) : maintenance système et logicielle ;
• Accès par les traitements automatiques métiers (dans le cadre de la finalité) ;
• Accès par les processus automatiques techniques (sauvegarde, réplication, purge, etc.) ;
• Accès pour l’exercice des droits des personnes (RGPD).

On voit donc que tout tracer n’est pas trivial puisqu’il y a des accès manuels et automatiques, et de nombreuses origines. Il faut donc avoir une réflexion globale concernant un système d’alimentation générique des registres.

Le RGPD restant relativement général, des questions subsistent concernant la granularité des registres : uniquement les opérations de création, modification et suppression, ou également tous les accès unitaires en consultation ? Et une opération de masse (impactant de nombreuses données) doit-elle être tracée comme une seule opération, ou détaillée ?

Ceci étant dit, voici un aperçu de ce qu’un registre peut contenir (certaines informations sont listées dans le RGPD, dans les exemples de la CNIL, d’autres nous semblent évidentes) :

• Pour chaque traitement : responsable, DPD, finalité, date de création, durée de vie des données, catégorie de personnes et typologie des données personnelles concernées, volumes, procédures applicables, mesures de sécurité applicables, collaborateurs habilités…
• Pour chaque opération sur le traitement : date, origine et finalité de l’opération, description, auteur, procédures et/ou mesures de sécurité appliquées…

Notez que les registres contiennent eux-mêmes des données personnelles ! Ils doivent donc être protégés, comme n’importe quel fichier (au sens RGPD).

Le RGPD insiste particulièrement sur la sécurité et le respect des données personnelles (articles 25 et 32 du RGPD), en spécifiant que ces aspects doivent être pris en compte dès la conception des procédures, des applications, ou du choix des solutions logicielles externes (respectivement security by design et privacy by design en anglais), et que ces aspects soient actifs par défaut (respectivement security by default et privacy by default). Le RGPD ne détaille pas les règles de sécurité et respect des données personnelles, mais indique très justement que ce ne sont pas des problématiques exclusivement techniques, mais tout autant organisationnelles.

→ Pour être clair, cela signifie qu’il faut prendre en compte la sécurité et le respect des données personnelles lors des évaluations de nouveaux logiciels externes (et prendre en compte ces critères dans le processus de choix), lors de la conception technique et fonctionnelle d’applications ou des services (avant de commencer les développements), et lors de la définition de toutes les procédures et processus organisationnel ou technique.

En conséquence, il est clair qu’il faut sensibiliser et impliquer tous les collaborateurs qui participent à ces choix, du management aux équipes techniques, en passant par les équipes métiers et fonctionnelles, ce qui renforce le chapitre « responsabilisation » détaillé plus haut.

Bien entendu, pour les logiciels, applications et processus déjà en place, cela implique de réaliser une réévaluation de chacun, qui pourrait conduire à le changer ou l’adapter, selon les cas, ce qui est évidemment plus complexe.

Nous avons parcouru ensemble les principales contraintes et règles du RGPD, commune à la majorité des entreprises. Il reste néanmoins quelques aspects importants que nous ne détaillerons pas ici, car applicables selon les spécificités de votre entreprise et de vos traitements. En voici la liste, avec les indications des principaux articles concernés :

• Transfert vers pays tiers (articles 44 à 50 du RGPD)
• Traitements particuliers (articles 85 à 91 du RGPD)
• Catégories particulières de données (articles 9 et 10 du RGPD)
• Protection des enfants (articles 6 et 8 du RGPD)
• Codes de conduite (articles 40 et 41 du RGPD)
• Certifications (articles 42 et 43 du RGPD)
• Litiges et recours (articles 77 à 87 du RGPD)

→ Dans le prochain article, nous aborderons la mise en œuvre du RGPD et les bonnes pratiques. L’article se terminera par une liste de références documentaires.