Moi DPO (3/4) : Les premières actions

Cet article a pour objet d’adresser les premières étapes opérationnelles que devra conduire le délégué à la protection des données (DPO) avec son réseau pour mener à bien le projet de conformité de l’entreprise pour laquelle ils opèrent. Une fois le réseau en place ou ses relais désignés selon les termes choisis, le DPO doit désormais initier les démarches afin d’établir un premier plan de bataille.

Comment procéder ?

Tout d’abord, il est temps pour le DPO et son réseau de sonder les processus de l’entreprise pour identifier les points positifs et lacunes au regard des principes issus du RGPD, la loi Informatiques et Libertés et les diverses lignes directrices et recommandations adressées par la CNIL. Pour ce faire, comme cela a été souligné dans le premier article de cette série, il est essentiel pour le DPO de connaître les tenants et aboutissants de la législation relative aux données personnelles. Évidemment, de nouvelles questions qui n’avaient pas été encore envisagées posant de nouveaux défis viendront toujours se poser, mais avec un socle de connaissances, les moyens à sa disposition et son équipe, le DPO a la capacité de trouver des solutions pragmatiques.

Pour identifier les processus préexistants ou non dans l’entreprise, la première étape pour le DPO, avant même l’établissement d’un plan d’actions, est donc la réalisation de ce que l’on pourrait appeler une évaluation de maturité visant à obtenir une première estimation de l’ampleur des tâches à venir.

Concrètement l’évaluation de maturité consistera à se poser des questions simples traduisant les exigences de la législation. Dès lors, le DPO aura une idée d’où il met les pieds. Parmi ces questions réparties en plusieurs catégories, on pourrait par exemple retrouver de manière non-exhaustive les points de contrôle suivants :

1. La gouvernance :

– Existe-t-il des politiques de protection des données personnelles des clients, usagers, prospects et salariés

– Le personnel a-t-il été sensibilisé aux enjeux de la protection des données personnelles et à la sécurité informatique ?

– Existe-t-il une procédure en cas de contrôle de la CNIL ?

2. Le registre des traitements :

– Les traitements de données personnelles ont été recensés ?

– Un registre des traitements a-t-il été constitué ?

3. Les données personnelles :

– Les traitements identifiés ont une finalité déterminée, explicite et légitime

– Les traitements impliquant l’utilisation de données sensibles ont été identifiés

4. La gestion des risques :

– Les traitements nécessitant une analyse d’impact relative à la vie privée ont-ils été identifiés ?

5. La transparence :

– Les personnes concernées par les traitements sont-elles correctement informés de ceux-ci ?

6. La sous-traitance :

– Les relations avec les sous-traitants sont-elles encadrées par un contrat écrit ?

7. La sécurité :

– Une charte informatique a-t-elle été adoptée et communiquée à l’ensemble du personnel ?

Pour obtenir les réponses aux questions qu’il a prédéfinies, le DPO devra être à même de solliciter les membres de son réseau, les métiers de l’entreprise si nécessaire, pouvoir accéder à de la documentation de l’organisme, tout ceci afin de mesurer et obtenir un premier indicateur du niveau de maturité de celui-ci.

Définition d’un plan d’actions et priorisation

Apporter des réponses à ces interrogations et identifier le niveau de maturité de l’organisme permettront bien évidemment de dégager un plan structuré visant à définir et prioriser des actions de remédiation aux lacunes constatées. Celles-ci pourront par exemple consister en la réalisation d’entretiens de cartographies avec les différents métiers afin de faire l’inventaire des processus de l’entreprise, la rédaction du registre de traitements, de politiques d’information, la mise à jour de sites web, la revue de contrats avec les sous-traitants et l’intégration de clauses dédiées à la protection des données personnelles, etc.

Bien entendu, ce premier plan d’actions dégagé suite à cette évaluation de maturité continuera d’être alimenté au fur et à mesure de l’avancement du projet de conformité. Par exemple, la constitution du registre des traitements pourra avoir pour conséquence d’identifier d’autres actions nécessaires à se conformer aux principes de la protection des données personnelles.

Par un exemple, le registre permettra de mettre le doigt sur l’absence des durées de conservation des données, allant ainsi à l’encontre du principe de limitation des données. Autre exemple, la constitution des fiches de traitements avec les métiers pourra également être utile à constater le défaut d’information des personnes concernées.

Tous ces éléments viendront alimenter les actions qui devront être déployées au fur et à mesure de l’avancement de la conformité.

Le suivi dans le temps

Tout le long de la vie du projet de conformité de l’entreprise, qui vivra aussi longtemps que l’entreprise elle-même, le DPO et son équipe devront s’assurer de mettre en place un suivi à long terme. Évidemment, toutes les actions identifiées à et à identifier ne pourront pas être réalisées du jour au lendemain. C’est pourquoi, il sera absolument nécessaire de les prioriser dans le temps au regard de divers facteurs.

Cela passera par la qualification d’actions dites ‘quickwin’, dont la mise en place permettra d’avoir un fort impact sur le taux d’avancement de la conformité tout en limitant le temps nécessaire à leur implémentation. D’autres actions, plus lourdes devront être conduites prioritairement parce qu’elles répondent aux grands principes du RGPD. Il s’agira de la constitution du registre des traitements ou encore de la mise en conformité d’un site web après audit, justifié par le fait que celui-ci peut être perçu comme une « vitrine » de la conformité de l’organisme.

Toutes ces actions qui constituent le plan de conformité de l’entreprise devront donc être priorisées en fonction de leur difficulté, de la charge qu’elles représentent et de l’impact qu’elles auront sur le niveau de maturité de l’entreprise. Pour ce faire, le DPO, pour avancer efficacement devra s’appuyer sur son réseau mais aussi sur les équipes opérationnelles quand cela est nécessaire.

Dans la suite de cette série, nous aborderons plus en détails la première étape de ce plan d’action qui fait suite à l’évaluation de maturité. Dans la majorité des cas, il s’agira de la constitution du registre des traitements et de son suivi dans le temps.

Retrouvez la série des articles « Moi DPO » :

– article de Frédéric Le Corre : Moi DPO : Démarrer une mission de délégué à la protection des données personnelles

– article d’Anne-Sophie Casal : Moi DPO, au centre au réseau

– article d’Alice Picard : Moi DPO : la constitution du registre des activités de traitement

Je partage

Derniers articles

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article