IDS, IPS, DLP : quelles obligations CNIL et RGPD ?

Un IDS, un IPS ou un outil DLP ne nécessite pas automatiquement une autorisation préalable de la CNIL. Le raisonnement publié ici en 2012 reposait sur l’ancien régime de formalités. Depuis l’application du RGPD, la bonne démarche consiste à qualifier le traitement réellement effectué, ses données, sa finalité et ses risques.

Ces outils peuvent protéger l’entreprise tout en observant des utilisateurs. Leur utilité de sécurité ne dispense donc ni de proportionnalité, ni d’information, ni d’un encadrement des accès aux journaux.

Pourquoi l’ancienne réponse n’est plus applicable

La CNIL précise que ses anciennes autorisations uniques ont perdu leur valeur juridique à compter du 25 mai 2018, notamment dans sa fiche sur l’AU-46 relative aux contentieux. Il serait erroné d’en déduire aujourd’hui une obligation générale de demander cette autorisation pour déployer un IDS.

Cela ne signifie pas que toute formalité a disparu. Une consultation préalable peut notamment être nécessaire lorsque les conditions de l’Art. 36(1) du RGPD sont réunies : le risque élevé identifié ne peut être suffisamment atténué par les mesures envisagées. Il faut aussi vérifier les régimes sectoriels applicables. RGPD, Art. 35–36.

Partir des données et des usages

Une alerte technique ne démontre pas à elle seule qu’une personne a commis une infraction. Vérifiez les données et qualifications réellement enregistrées. Si le traitement porte sur des données relatives aux infractions, l’Art. 10 du RGPD et le droit national doivent être examinés en plus de la base légale ordinaire.

L’Art. 46, 3° de la loi Informatique et Libertés autorise notamment certains traitements nécessaires à la préparation, à l’exercice ou au suivi d’une action en justice, en tant que victime, mise en cause ou pour leur compte. La durée et la communication aux tiers doivent rester strictement proportionnées. Cette disposition ne justifie pas un fichier général de suspects constitué sans limite.

Encadrer la surveillance des salariés

Un outil de sécurité ne doit pas devenir discrètement un instrument d’évaluation permanente de la productivité. Définissez les finalités et les données nécessaires, puis examinez la base légale, l’information des personnes et les droits applicables.

L’Art. L. 1222-4 du Code du travail prévoit l’information préalable du salarié pour un dispositif collectant des informations le concernant. L’Art. L. 2312-38 prévoit, dans son champ, l’information et la consultation du CSE avant la décision de mise en œuvre de moyens de contrôle de l’activité. La charte informatique contribue à l’information, sans remplacer les autres démarches requises.

Dossier minimal avant déploiement

Préparez une fiche de traitement et de configuration comprenant :

1. Le besoin de sécurité, les risques et les alternatives moins intrusives examinées.
2. Les données collectées, les exclusions, les règles d’alerte et les faux positifs à vérifier.
3. Les personnes habilitées, les accès d’administration et le prestataire éventuel.
4. Les durées justifiées pour l’exploitation courante et, séparément, les preuves d’un incident.
5. L’information des personnes, l’analyse du besoin d’AIPD et les validations obtenues.

Reliez cette fiche à votre AIPD lorsqu’elle est requise. Pour une solution de prévention des fuites de données, vérifiez particulièrement la collecte de contenu et les canaux personnels ou exclus. Les mesures doivent satisfaire l’Art. 32 du RGPD, y compris pour protéger les traces générées par l’outil lui-même.

Décrire la collecte avant d’activer les règles

Commencez par une représentation simple du parcours des données : poste ou serveur observé, capteur, console, équipe qui reçoit l’alerte et éventuel service externe. Pour chaque étape, indiquez si l’outil manipule un identifiant, une adresse, un nom de fichier, un extrait ou le document entier. Deux produits portant la même étiquette « DLP » peuvent conduire à des traitements très différents.

Demandez notamment ce qui remonte dans une alerte. Une règle destinée à repérer un document sensible peut transmettre ce document à plusieurs opérateurs, dans un courriel de notification ou dans un ticket. La protection recherchée peut ainsi créer une nouvelle copie sensible. Examinez si une référence, une catégorie et les éléments nécessaires à la qualification peuvent suffire, puis justifiez tout accès supplémentaire au contenu.

La base légale doit correspondre au traitement effectivement retenu. Pour un organisme privé, l’intérêt légitime de l’Art. 6(1)(f) peut être examiné avec sa nécessité et la mise en balance des droits ; il ne se déduit pas automatiquement de l’étiquette « sécurité ». Si une obligation légale est invoquée, identifiez le texte applicable et l’opération qu’il exige. L’Art. 5(1)(b), (c) et (e) impose aussi d’encadrer la finalité, le volume des données et la durée. Source : RGPD, chapitre II.

Prévoir une investigation graduée

Une procédure peut organiser plusieurs niveaux d’examen. Au premier niveau, un opérateur vérifie le type d’événement, sa date et la ressource concernée. Si ces éléments ne suffisent pas, une personne habilitée décide de l’approfondissement nécessaire et du périmètre des pièces à consulter. Cette organisation proposée doit être adaptée aux risques et aux obligations applicables ; elle ne crée aucun droit général d’ouvrir des communications personnelles.

L’outil doit permettre de distinguer le déclenchement d’une règle de la conclusion de l’analyse. Conservez le contexte utile à cette distinction : transfert autorisé, opération technique attendue, erreur de destinataire ou événement qui reste inexpliqué. La découverte d’une anomalie sur un compte n’établit pas, à elle seule, l’identité de l’auteur ni son intention.

Déterminez également qui peut modifier une règle, lever un blocage ou consulter un document mis en quarantaine. Ces pouvoirs répondent à des besoins différents. Un responsable hiérarchique n’a pas automatiquement besoin d’accéder à toutes les alertes nominatives de son équipe. Pour un blocage affectant le travail, prévoyez un interlocuteur et une procédure de vérification permettant de corriger une erreur sans supprimer la protection pour tous les utilisateurs.

Motiver la décision sur l’AIPD

L’Art. 35(1) demande d’examiner le risque élevé pour les personnes avant le traitement. La liste adoptée par la CNIL dans la délibération n° 2018-327 du 11 octobre 2018 vise notamment les traitements ayant pour finalité de surveiller constamment l’activité des employés. Si le dispositif entre dans cette catégorie, l’AIPD est requise. Le nom du produit ou sa fonction annoncée de cybersécurité ne permet pas d’écarter cet examen. Source : délibération, annexe.

Décrivez donc la fréquence, les personnes suivies, les rapprochements effectués et les effets possibles d’une alerte ou d’un blocage. Examinez aussi les autres cas de l’Art. 35 et les listes applicables. Une conclusion doit porter sur une configuration précise : l’ajout ultérieur d’une analyse de contenu ou d’un classement des utilisateurs peut modifier l’appréciation.

Une AIPD réalisée ne vaut pas autorisation de mise en service. Elle doit conduire à examiner la nécessité, la proportionnalité et les garanties ; si l’AIPD révèle un risque élevé qui ne peut être suffisamment atténué, l’autorité doit être consultée avant le traitement conformément à l’Art. 36(1). Le document du fournisseur apporte des informations techniques, mais ne tranche pas les usages propres à l’employeur.

Exemple de fiche de configuration à discuter

Exemple entièrement fictif : l’entreprise Silex souhaite prévenir l’envoi de dossiers clients hors de ses espaces autorisés. Son projet porte sur un canal professionnel identifié ; l’équipe doit encore vérifier les autres canaux et les données qu’ils contiennent. La fiche suivante sert à préparer la discussion, sans valider le déploiement.

Supposons que la démonstration utilise un faux dossier client. Elle peut montrer la présentation de l’alerte ; elle ne démontre ni l’efficacité de toutes les règles ni la conformité de la surveillance réelle. Demandez un compte rendu limité à ce qui a effectivement été examiné, avec les questions restantes. Aucun essai de cette entreprise fictive n’est présenté ici comme réalisé.

Encadrer l’exploitation confiée à un tiers

Si un prestataire analyse les alertes pour votre compte, précisez ses instructions, ses habilitations et le sort des données dans le cadre de l’Art. 28(3) RGPD. L’accès distant, les sous-traitants ultérieurs et les éventuels transferts doivent être identifiés. Une clause de confidentialité seule ne décrit pas ces opérations. Source : RGPD, Art. 28.

Vérifiez enfin comment une modification devient effective : nouvelle règle, changement de destinataire, conservation plus longue ou activation d’une fonction optionnelle. Rapprochez la configuration réelle du dossier documenté, de l’information fournie aux personnes et des démarches sociales nécessaires. Ce suivi donne un responsable aux écarts et évite qu’une option activée après l’achat échappe à l’analyse initiale.

Ce qu’il faut retenir

• Ne reprenez pas le régime général d’autorisation présenté dans l’article de 2012.
• Qualifiez les données traitées ; une alerte n’est pas une culpabilité établie.
• Encadrez la surveillance des salariés et les investigations.
• Justifiez les durées, les accès et le besoin éventuel d’AIPD.

FAQ

Le RGPD interdit-il les IDS et les IPS ?

Non. Leur déploiement doit répondre à une finalité légitime et respecter les obligations applicables au traitement effectivement réalisé.

Toute alerte relève-t-elle des données d’infraction ?

Il faut examiner son contenu, son contexte et les qualifications enregistrées. Une simple anomalie technique ne suffit pas à démontrer une infraction commise par un utilisateur.

Un outil DLP impose-t-il toujours une AIPD ?

Pas par son seul nom. L’analyse porte sur le traitement, sa portée, ses finalités et son risque pour les personnes, ainsi que les listes applicables.

Recevez nos analyses pratiques de conformité numérique.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies.