DLP en 2026 : ISO 27001 pour GDPR, NIS2 et DORA

Tout commence par une feuille de calcul.

À 08 h 17, un lundi, un responsable de la réussite client exporte 14 000 contacts d’entreprise depuis le CRM pour préparer une campagne de renouvellement. À 08 h 24, la feuille de calcul est jointe à un courriel. À 08 h 26, le courriel est envoyé vers un compte Gmail personnel parce que le salarié souhaite travailler pendant un trajet en train. À 08 h 31, le même fichier est téléversé vers un service de prise de notes IA non approuvé afin de « nettoyer les doublons ».

Rien ne ressemble encore à une violation. Pas de demande de rançongiciel, pas de beacon de logiciel malveillant, pas de compte administrateur compromis et pas de fuite publique. Pourtant, pour le RSSI, le responsable conformité et le délégué à la protection des données (DPO), la vraie question est déjà posée : l’organisation peut-elle prouver que ce mouvement était autorisé, classifié, journalisé, chiffré, justifié et réversible ?

Le même scénario se répète chaque semaine dans les services financiers. Un développeur tente de téléverser Q1_Investor_Projections_DRAFT.xlsx vers un lecteur cloud personnel parce que le VPN est lent. Un responsable commercial exporte une liste de clients vers une application collaborative grand public. Un analyste support colle des enregistrements clients dans un outil IA non approuvé. Dans chaque cas, l’intention relève peut-être de la commodité plutôt que de la malveillance, mais le risque est identique. Des données sensibles ont franchi, ou presque franchi, une frontière que l’organisation ne contrôle pas.

C’est le problème moderne de la prévention des pertes de données. Le DLP ne se limite plus à une règle de passerelle de messagerie ou à un agent installé sur les terminaux. En 2026, une prévention efficace des pertes de données est un système de contrôle gouverné et étayé par des preuves couvrant les environnements SaaS, le stockage cloud, les terminaux, les appareils mobiles, les fournisseurs, les interfaces de programmation (API), les environnements de développement, les exports de sauvegarde, les outils collaboratifs et les raccourcis humains.

GDPR Article 32 exige des mesures techniques et organisationnelles appropriées pour assurer la sécurité du traitement. NIS2 Article 21 exige des mesures de cybersécurité fondées sur les risques, incluant l’hygiène cyber, le contrôle d’accès, la gestion des actifs, la sécurité de la chaîne d’approvisionnement, la gestion des incidents, le chiffrement et les tests d’efficacité. DORA exige des entités financières qu’elles gèrent le risque lié aux TIC par la gouvernance, la détection, la réponse, le rétablissement, les tests, la supervision des tiers et l’auditabilité. ISO/IEC 27001:2022 fournit l’ossature du système de management permettant de rendre ces obligations opérationnelles, mesurables et auditables.

L’erreur de nombreuses organisations consiste à acheter un outil DLP avant de définir ce que signifie la « perte ». L’approche de Clarysec commence plus en amont : classifier les données, définir les transferts autorisés, appliquer la politique, surveiller les exceptions, préparer les preuves de réponse et relier l’ensemble au SMSI.

Comme l’indique le Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur dans la phase des contrôles en action, étape 19, contrôles technologiques I :

La prévention des fuites de données consiste à empêcher la divulgation non autorisée ou accidentelle d’informations sensibles, qu’elles sortent par courriel, téléversement cloud, support portable ou même par une impression oubliée. Le contrôle 8.12 répond à la nécessité de surveiller, restreindre et traiter toute donnée qui quitte les frontières de confiance de l’organisation, que le canal soit numérique, physique ou humain. Zenith Blueprint

Cette phrase résume le DLP en 2026 : surveiller, restreindre et répondre.

Pourquoi le DLP est désormais un enjeu de conformité au niveau du conseil d’administration

Le conseil d’administration ne demande généralement pas si une expression régulière DLP détecte les numéros d’identification nationaux. Il demande si l’organisation peut préserver la confiance des clients, continuer à fonctionner, éviter l’exposition réglementaire et prouver un niveau de sécurité raisonnable lorsqu’un événement se produit.

C’est là que GDPR, NIS2 et DORA convergent.

GDPR s’applique largement au traitement automatisé de données à caractère personnel, y compris aux responsables du traitement et aux sous-traitants établis dans l’UE, ainsi qu’aux organisations non établies dans l’UE qui offrent des biens ou services à des personnes dans l’UE ou surveillent leur comportement. Il définit largement les données à caractère personnel et couvre des opérations telles que la collecte, le stockage, l’utilisation, la divulgation, l’effacement et la destruction. La divulgation non autorisée de données à caractère personnel, ou l’accès non autorisé à celles-ci, peut constituer une violation de données à caractère personnel. GDPR Article 5 rend également la responsabilité explicite : les organisations ne doivent pas seulement respecter des principes tels que la minimisation des données, la limitation de la conservation, l’intégrité et la confidentialité ; elles doivent être en mesure de démontrer la conformité.

NIS2 étend la pression au-delà de la vie privée. Elle s’applique à de nombreuses entités essentielles et importantes, notamment dans des secteurs tels que la banque, les infrastructures de marchés financiers, les fournisseurs de services d’informatique en nuage, les fournisseurs de centres de données, les prestataires de services managés, les prestataires de services de sécurité managés, les places de marché en ligne, les moteurs de recherche et les plateformes de réseaux sociaux. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, comprenant l’analyse des risques, les politiques de sécurité des systèmes d’information, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, les tests d’efficacité, l’hygiène cyber, la formation, la cryptographie, le contrôle d’accès, la gestion des actifs et l’authentification.

DORA s’applique depuis le 17 janvier 2025 et constitue le cadre dédié à la résilience liée aux TIC dans le secteur financier. Pour les entités financières entrant dans son champ d’application, il est traité comme l’acte juridique sectoriel de l’Union applicable aux chevauchements avec NIS2. DORA intègre le DLP à la gestion des risques liés aux TIC, à la catégorisation des incidents, aux pertes de données affectant la disponibilité, l’authenticité, l’intégrité ou la confidentialité, aux tests de résilience opérationnelle numérique, à la gestion des prestataires tiers TIC et aux contrôles contractuels.

La question DLP en 2026 n’est pas « Possédons-nous un outil ? ». Elle est :

1. Savons-nous quelles informations sont sensibles ?
2. Savons-nous où elles sont stockées, traitées et transférées ?
3. Les routes de transfert autorisées et interdites sont-elles définies ?
4. Les utilisateurs sont-ils formés et techniquement contraints ?
5. Les routes cloud et SaaS sont-elles gouvernées ?
6. Les journaux sont-ils suffisants pour l’investigation ?
7. Les alertes sont-elles triées et les incidents classifiés rapidement ?
8. Les fournisseurs et services TIC externalisés sont-ils contractuellement engagés ?
9. Pouvons-nous prouver que les contrôles fonctionnent ?

ISO/IEC 27001:2022 est bien adaptée pour répondre à ces questions, car elle exige le contexte, les exigences des parties intéressées, l’appréciation des risques, le traitement des risques, des objectifs mesurables, le contrôle opérationnel, les informations documentées, le contrôle des fournisseurs, l’audit interne, la revue de direction et l’amélioration continue. Ce n’est pas une norme DLP, mais elle transforme le DLP d’une configuration technologique isolée en processus maîtrisé de système de management.

La chaîne de contrôles ISO 27001 derrière un DLP efficace

Un programme DLP crédible ne repose pas sur un seul contrôle. Il repose sur une chaîne.

Le guide Zenith Controls : guide de conformité croisée de Clarysec cartographie le contrôle ISO/IEC 27002:2022 8.12, Prévention des fuites de données, comme un contrôle préventif et détectif axé sur la confidentialité, aligné avec les concepts cybersécurité Protect et Detect, avec la protection de l’information comme capacité opérationnelle et la protection/défense comme domaine de sécurité. Zenith Controls

C’est important, car les auditeurs attendent à la fois du blocage et de la visibilité. Une règle DLP préventive sans revue des alertes est incomplète. Une approche limitée à la journalisation, sans mise en application pour les transferts à haut risque, est également faible.

Le même guide cartographie le contrôle ISO/IEC 27002:2022 5.12, Classification de l’information, comme préventif, soutenant la confidentialité, l’intégrité et la disponibilité, et aligné avec Identify. Il cartographie le contrôle 5.14, Transfert de l’information, comme préventif, soutenant la confidentialité, l’intégrité et la disponibilité, et aligné avec Protect, Asset Management et Information Protection.

Concrètement, la chaîne de contrôles DLP ressemble à ceci :

Le Zenith Blueprint, étape 22, explique la dépendance entre l’inventaire des actifs, la classification et le DLP :

Passez en revue votre inventaire des actifs actuel (5.9) pour vous assurer qu’il inclut les actifs physiques et logiques, les propriétaires et les classifications. Reliez cet inventaire à votre schéma de classification (5.12), afin que les actifs sensibles soient étiquetés et protégés de manière appropriée. Lorsque cela est nécessaire, définissez la conservation, la sauvegarde ou l’isolement en fonction de la classification.

C’est pourquoi Clarysec commence rarement une mission DLP par le réglage des règles. Nous commençons par rapprocher les actifs, les propriétaires, les types de données, les étiquettes de classification, les routes de transfert et les enregistrements probants. Si l’organisation ne peut pas dire quels jeux de données sont confidentiels, réglementés, détenus par des clients, liés aux paiements ou critiques pour l’activité, un outil DLP ne peut que deviner.

Les trois piliers d’un programme DLP moderne

Un programme DLP moderne repose sur trois piliers qui se renforcent mutuellement : connaître les données, gouverner les flux et défendre la frontière. Ces piliers rendent ISO/IEC 27001:2022 opérationnelle pour la conformité GDPR, NIS2 et DORA.

Pilier 1 : connaître vos données grâce à la classification et à l’étiquetage

Vous ne pouvez pas protéger ce que vous ne comprenez pas. Les contrôles ISO/IEC 27002:2022 5.12 et 5.13 exigent que les organisations classifient l’information et l’étiquettent selon sa sensibilité et ses exigences de traitement. Ce n’est pas un exercice documentaire. C’est la base de l’application automatisée.

Pour les PME, la Politique de classification et d’étiquetage des données indique :

Confidentiel : exige le chiffrement en transit et au repos, un accès restreint, une approbation explicite pour le partage et une destruction sécurisée lors de l’élimination. Politique de classification et d’étiquetage des données - PME

Cette citation, issue de la section « Exigences de mise en œuvre de la politique », clause 6.3.3, donne au programme DLP quatre conditions applicables : chiffrement, accès restreint, approbation du partage et élimination sécurisée.

Dans les environnements d’entreprise, la Politique de classification et d’étiquetage des données est encore plus directe. Depuis la section « Exigences de mise en œuvre de la politique », clause 6.2.6.2 :

Blocage de la transmission (par exemple, courriel externe) pour les données sensibles incorrectement étiquetées Politique de classification et d’étiquetage des données

Et depuis la section « Application et conformité », clause 8.3.2 :

Validation automatisée de la classification au moyen de la prévention des pertes de données (DLP) et d’outils de découverte

Ces clauses transforment la classification en contrôle. Un fichier marqué Confidentiel peut déclencher le chiffrement, bloquer une transmission externe, exiger une approbation ou générer une alerte de sécurité. Le DLP devient alors la couche d’application d’une politique que les utilisateurs, les systèmes et les auditeurs peuvent comprendre.

Pilier 2 : gouverner les flux avec le transfert sécurisé de l’information

Une fois les données classifiées, l’organisation doit gouverner leur circulation. Le contrôle ISO/IEC 27002:2022 5.14, Transfert de l’information, est souvent négligé, alors qu’il est à l’origine de nombreux échecs DLP.

Le Zenith Blueprint présente le contrôle 5.14 comme la nécessité de gouverner les flux d’information afin que le transfert soit sécurisé, intentionnel et cohérent avec la classification et la finalité métier. Cela s’applique aux courriels, au partage sécurisé de fichiers, aux interfaces de programmation (API), aux intégrations SaaS, aux supports amovibles, aux rapports imprimés et aux portails fournisseurs.

Le télétravail rend ce point particulièrement important. La Politique de télétravail, section « Exigences de mise en œuvre de la politique », clause 6.3.1.3, exige des salariés qu’ils :

Utilisent uniquement des solutions de partage de fichiers approuvées (par exemple, M365, Google Workspace avec des contrôles de prévention des pertes de données (DLP)) Politique de télétravail

Pour les appareils mobiles et le BYOD, la Politique relative aux appareils mobiles et au BYOD, section « Exigences de mise en œuvre de la politique », clause 6.6.4, prévoit une application concrète sur les terminaux :

Les politiques de prévention des pertes de données (DLP) doivent bloquer les téléversements non autorisés, les captures d’écran, l’accès au presse-papiers ou le partage de données depuis des applications gérées vers des espaces personnels. Politique relative aux appareils mobiles et au BYOD

C’est essentiel, car les données ne sortent pas uniquement par courriel. Elles sortent par captures d’écran, synchronisation du presse-papiers, profils de navigateur non gérés, lecteurs personnels, feuilles de partage mobiles, modules d’extension collaboratifs et outils IA.

La gouvernance cloud est tout aussi importante. Dans la Politique d’utilisation du cloud pour PME, section « Exigences de gouvernance », clause 5.5 :

Le shadow IT, défini comme l’utilisation d’outils cloud non approuvés, doit être traité comme un manquement à la politique et revu par le DG et le prestataire informatique afin de déterminer le risque et la remédiation requise. Politique d’utilisation du cloud - PME

Pour les organisations d’entreprise, la Politique d’utilisation du cloud, section « Exigences de gouvernance », clause 5.5, relève le niveau de surveillance :

L’équipe de sécurité de l’information doit évaluer régulièrement le trafic réseau, l’activité DNS et les journaux afin de détecter l’utilisation non autorisée du cloud (shadow IT). Les manquements détectés doivent faire l’objet d’une investigation rapide. Politique d’utilisation du cloud

Le shadow IT n’est pas seulement une nuisance informatique. Au titre de GDPR, il peut devenir une divulgation illicite ou un traitement non maîtrisé. Au titre de NIS2, il constitue une faiblesse d’hygiène cyber et de chaîne d’approvisionnement. Au titre de DORA, il peut devenir un risque lié aux prestataires tiers TIC et un sujet de catégorisation des incidents.

Pilier 3 : défendre la frontière avec la technologie, la politique et la sensibilisation DLP

Le contrôle ISO/IEC 27002:2022 8.12, Prévention des fuites de données, est le contrôle que la plupart des personnes associent au DLP. Mais dans un programme mature, il constitue la dernière ligne de défense, pas la première.

Le Zenith Blueprint explique que le DLP nécessite une approche à trois couches : technologie, politique et sensibilisation. La technologie inclut le DLP sur terminal, la sécurité de la messagerie électronique, l’inspection de contenu, la sécurité des accès cloud, les contrôles SaaS, les contrôles de navigateur, le filtrage des sorties réseau et le routage des alertes. La politique définit ce que les outils appliquent. La sensibilisation permet aux salariés de comprendre pourquoi la messagerie personnelle, le stockage cloud grand public et les outils IA non approuvés ne sont pas des méthodes de traitement acceptables pour les informations réglementées ou confidentielles.

La composante réponse est aussi importante que la prévention. Le Zenith Blueprint, étape 19, indique :

Mais le DLP n’est pas seulement de la prévention ; c’est aussi de la réponse. Si une fuite potentielle est détectée :

✓ Les alertes doivent être triées rapidement, ✓ La journalisation doit permettre l’analyse forensique, ✓ Le plan de réponse aux incidents doit être déclenché sans délai.

Un programme DLP qui bloque des événements, mais ne les trie pas, ne les investigue pas et n’en tire pas d’enseignements, n’est pas prêt pour l’audit. Il n’est que partiellement déployé.

De la fuite d’une feuille de calcul à une réponse prête pour l’audit

Revenons à la feuille de calcul du lundi matin.

Dans un programme faible, l’organisation découvre le téléversement trois semaines plus tard, lors d’une revue de la vie privée. Personne ne sait qui a approuvé l’export, si les données étaient des données à caractère personnel, si des données de catégories particulières étaient impliquées, si l’outil IA a conservé le fichier ou si les clients doivent être notifiés.

Dans un programme conçu par Clarysec, la séquence est différente.

Premièrement, l’export CRM est marqué Confidentiel parce qu’il contient des données à caractère personnel et des informations commerciales client. Deuxièmement, l’événement d’export est journalisé. Troisièmement, la passerelle de messagerie détecte une pièce jointe confidentielle envoyée vers un domaine de messagerie personnel et la bloque, sauf si une dérogation approuvée existe. Quatrièmement, la tentative de téléversement vers un service cloud non approuvé déclenche une alerte d’utilisation du cloud. Cinquièmement, l’alerte est triée selon la procédure de réponse aux incidents. Sixièmement, l’équipe de sécurité détermine s’il y a eu divulgation effective, si les données étaient chiffrées, si le prestataire les a traitées ou conservées, si les critères de violation GDPR sont remplis et si les seuils d’incident NIS2 ou DORA s’appliquent.

La Politique de journalisation et de surveillance pour les PME, section « Exigences de gouvernance », clause 5.4.3, indique précisément à l’équipe ce qui doit être visible :

Journaux des accès : accès aux fichiers (en particulier pour les données sensibles ou à caractère personnel), modifications des autorisations, utilisation des ressources partagées Politique de journalisation et de surveillance - PME

Cette clause est courte, mais déterminante. Si l’accès aux fichiers, les modifications d’autorisations et l’utilisation des ressources partagées ne sont pas journalisés, l’investigation DLP devient conjecturale.

Au titre de NIS2 Article 23, les incidents significatifs exigent une notification par étapes : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification d’incident dans les 72 heures et un rapport final au plus tard un mois après la notification de l’incident. Au titre de DORA, Articles 17 à 19 exigent des entités financières qu’elles détectent, gèrent, classifient, enregistrent, escaladent et déclarent les incidents majeurs liés aux TIC. La classification inclut la perte de données affectant la disponibilité, l’authenticité, l’intégrité ou la confidentialité, ainsi que les clients affectés, la durée, l’étendue géographique, la criticité et l’impact économique. Au titre de GDPR, une divulgation non autorisée de données à caractère personnel peut exiger une évaluation de violation et, lorsque les seuils sont atteints, une notification.

Une alerte DLP n’est donc pas seulement un événement de sécurité. Elle peut devenir une évaluation de violation de la vie privée, un workflow d’incident NIS2, une classification d’incident lié aux TIC au titre de DORA, un déclencheur de notification client et un dossier de preuves d’audit.

Contrôles DLP pour GDPR Article 32

GDPR Article 32 est souvent traduit en liste de mesures : chiffrement, confidentialité, intégrité, disponibilité, résilience, tests et restauration. Pour le DLP, l’enjeu est la protection sur l’ensemble du cycle de vie.

Les données à caractère personnel circulent au fil de la collecte, du stockage, de l’utilisation, du transfert, de la divulgation, de la conservation et de la suppression. GDPR Article 5 exige la minimisation des données, la limitation des finalités, la limitation de la conservation, l’intégrité, la confidentialité et la responsabilité. GDPR Article 6 exige une base légale et la compatibilité des finalités. GDPR Article 9 impose des mesures de protection plus strictes pour les catégories particulières de données à caractère personnel.

Le DLP soutient ces obligations lorsqu’il est relié à la classification des données, aux registres du traitement licite et aux chemins de transfert approuvés.

La Politique de masquage des données et de pseudonymisation pour PME de Clarysec, section « Objet », clause 1.2, soutient cette approche de cycle de vie :

Ces techniques sont obligatoires lorsque les données de production ne sont pas nécessaires, notamment dans les scénarios de développement, d’analyse et de services tiers, afin de réduire le risque d’exposition, d’usage abusif ou de violation. Politique de masquage des données et de pseudonymisation - PME

Il s’agit d’un contrôle pratique au titre de GDPR Article 32. Si les développeurs, les analystes ou les fournisseurs n’ont pas besoin de données à caractère personnel réelles, le DLP ne doit pas être la seule barrière. Le masquage et la pseudonymisation réduisent le rayon d’impact avant même que les données ne se déplacent.

Une matrice DLP robuste, alignée sur la protection de la vie privée, doit faire correspondre les types de données à caractère personnel aux étiquettes de classification, à la base légale, aux systèmes approuvés, aux méthodes d’export approuvées, aux exigences de chiffrement, aux règles DLP, aux règles de conservation et aux déclencheurs d’incident. Cette matrice devient le pont entre la gouvernance de la protection des données et les opérations de sécurité.

Hygiène cyber NIS2 et DLP au-delà de l’équipe protection des données

NIS2 modifie la conversation DLP, car elle présente les fuites comme un sujet d’hygiène cyber et de résilience, et pas uniquement de vie privée.

Article 20 exige des organes de direction des entités essentielles et importantes qu’ils approuvent les mesures de gestion des risques de cybersécurité, qu’ils en supervisent la mise en œuvre et qu’ils reçoivent une formation en cybersécurité. Article 21 exige des mesures appropriées et proportionnées couvrant les politiques, la gestion des incidents, la continuité, la chaîne d’approvisionnement, le développement sécurisé, les tests d’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès et la gestion des actifs. Article 25 encourage l’utilisation de normes européennes et internationales et de spécifications techniques pertinentes.

Le DLP contribue directement à ces domaines :

La Politique de sécurité réseau pour PME, section « Objectifs », clause 3.4, rend explicite l’objectif d’exfiltration :

Empêcher la propagation de logiciels malveillants et l’exfiltration de données par les canaux réseau Politique de sécurité réseau - PME

Pour NIS2, ce type d’objectif offre aux auditeurs un chemin de test direct : montrer le filtrage sortant, la surveillance DNS, les journaux de proxy, les alertes terminal, les tentatives de téléversement bloquées et les tickets d’investigation.

Le Zenith Blueprint, étape 23, ajoute une action spécifique au cloud, désormais essentielle pour les fournisseurs numériques et TIC couverts par NIS2 :

Listez tous les services cloud actuellement utilisés (5.23), y compris le shadow IT lorsqu’il est connu. Identifiez qui les a approuvés et si une diligence raisonnable a été réalisée. Développez une liste de contrôle d’évaluation légère couvrant la localisation des données, le modèle d’accès, la journalisation et le chiffrement. Pour les futurs services, veillez à ce que la liste de contrôle soit intégrée au processus d’approvisionnement ou d’intégration informatique.

De nombreuses organisations échouent ici. Elles disposent d’un périmètre du SMSI et d’un registre des fournisseurs, mais pas d’une liste réelle des outils SaaS vers lesquels les salariés déplacent des données réglementées ou clients. Le DLP sans découverte cloud est aveugle.

Risque lié aux TIC selon DORA : DLP pour les entités financières et les prestataires

Pour les entités financières, le DLP doit s’intégrer au cadre de gestion des risques liés aux TIC de DORA.

DORA Article 5 exige un cadre interne de gouvernance et de contrôle pour la gestion des risques liés aux TIC. L’organe de direction demeure responsable du risque lié aux TIC, des politiques préservant la disponibilité, l’authenticité, l’intégrité et la confidentialité des données, des rôles TIC clairement définis, de la stratégie de résilience opérationnelle numérique, de la tolérance au risque lié aux TIC, des plans de continuité et de réponse/rétablissement, des plans d’audit, des ressources, de la politique relative aux tiers et des canaux de reporting.

Article 6 exige un cadre documenté de gestion des risques liés aux TIC couvrant les stratégies, politiques, procédures, protocoles TIC et outils destinés à protéger les informations et les actifs TIC. Article 9 traite de la protection et de la prévention. Articles 11 à 14 ajoutent la continuité, la réponse, le rétablissement, la sauvegarde, la restauration, les contrôles d’intégrité des données, les retours d’expérience, la formation de sensibilisation et les communications de crise.

Le DLP s’inscrit dans ce cadre comme une capacité de protection, de détection, de réponse et de test.

DORA rend également le risque tiers incontournable. Articles 28 à 30 exigent la gestion des risques liés aux prestataires tiers TIC, des registres des contrats de services TIC, une diligence raisonnable précontractuelle, des exigences contractuelles, des droits d’audit et d’inspection, des droits de résiliation, des stratégies de sortie, des descriptions de services, les lieux de traitement et de stockage des données, l’accès aux données, la récupération et la restitution, l’assistance en cas d’incident, la coopération avec les autorités, les mesures de sécurité et les conditions de sous-traitance.

Pour une fintech ou une banque, le DLP ne peut pas s’arrêter à la frontière de Microsoft 365 ou Google Workspace. Il doit couvrir les prestataires de paiement, les prestataires de vérification d’identité, les plateformes CRM, les entrepôts de données, l’infrastructure cloud, les centres de support externalisés, les prestataires de services managés et les intégrations SaaS critiques.

C’est particulièrement important lorsque DORA agit comme acte juridique sectoriel de l’Union pour les obligations NIS2 qui se chevauchent. Les contrôles doivent néanmoins exister. La voie de reporting et de supervision peut différer.

Un sprint de 90 minutes pour une règle DLP

Clarysec utilise un sprint pratique avec les clients qui ont besoin de progresser rapidement sans prétendre qu’un programme DLP complet peut être construit en une seule réunion. L’objectif est de mettre en œuvre un contrôle DLP à forte valeur, de la politique jusqu’aux preuves.

Étape 1 : choisir un type de données et une route de transfert

Choisissez « données à caractère personnel clients exportées depuis le CRM et envoyées à l’extérieur par courriel ». Ne commencez pas par tous les référentiels, pays et types de données.

Étape 2 : confirmer la classification et l’étiquette

Utilisez la politique de classification pour confirmer que cet export est Confidentiel. Dans une PME, la clause 6.3.3 exige le chiffrement, l’accès restreint, l’approbation explicite du partage et la destruction sécurisée. Dans une entreprise, la Politique de classification et d’étiquetage des données prévoit le blocage de la transmission pour les données sensibles incorrectement étiquetées et la validation automatisée au moyen du DLP et d’outils de découverte.

Étape 3 : définir le modèle de transfert autorisé

Autorisé : export CRM envoyé vers un domaine client approuvé au moyen d’un courriel chiffré ou d’une plateforme de partage sécurisé de fichiers approuvée, avec justification métier.

Non autorisé : messagerie personnelle, liens publics de partage de fichiers, outils IA non approuvés et lecteurs cloud non gérés.

Cela s’aligne sur le Zenith Blueprint, étape 22, qui indique :

Si les informations « Confidentiel » ne sont pas autorisées à quitter l’entreprise sans chiffrement, les systèmes de messagerie doivent appliquer les politiques de chiffrement ou bloquer la transmission externe.

Étape 4 : configurer la règle DLP minimale

Configurez la messagerie ou la plateforme collaborative pour détecter l’étiquette confidentielle, le motif de données à caractère personnel ou la convention de nommage des fichiers d’export. Commencez par la surveillance si des faux positifs sont attendus, puis passez au blocage pour les domaines personnels et les destinataires non approuvés.

Étape 5 : activer la journalisation et le routage des alertes

Assurez-vous que les journaux capturent l’accès aux fichiers, les modifications d’autorisations et l’utilisation des ressources partagées, comme l’exige la Politique de journalisation et de surveillance - PME. Routez les alertes vers la file de tickets avec la gravité, le type de données, l’expéditeur, le destinataire, le nom du fichier, l’action prise et le réviseur.

Étape 6 : tester trois scénarios

Testez un transfert chiffré approuvé vers un client, un transfert bloqué vers une messagerie personnelle et une tentative de téléversement en mode alerte seule vers un domaine cloud non approuvé.

Étape 7 : conserver les preuves

Conservez la référence de la clause de politique, la capture d’écran de la règle DLP, les résultats de test, le ticket d’alerte, la décision du réviseur et l’approbation de la direction. Ajoutez le contrôle au plan de traitement des risques et à la Déclaration d’applicabilité.

En termes ISO/IEC 27001:2022, cet exercice relie la Clause 6.1.2 appréciation des risques, la Clause 6.1.3 traitement des risques, la Clause 8 planification et contrôle opérationnels, l’Annexe A transfert de l’information, prévention des fuites de données, journalisation, surveillance, contrôles fournisseurs et cloud, et la Clause 9 évaluation des performances.

Cartographie de conformité croisée : un programme DLP, plusieurs obligations

La force de l’approche Clarysec est d’éviter de construire des piles de contrôles séparées pour GDPR, NIS2, DORA, NIST et COBIT. Un programme DLP bien conçu peut satisfaire plusieurs attentes si les preuves sont correctement structurées.

NIST CSF 2.0 est utile comme couche de communication. Sa fonction GOVERN soutient le suivi des exigences légales, réglementaires et contractuelles, l’appétence au risque, l’application de la politique, les rôles et la supervision. Sa méthode Profiles aide les organisations à cadrer le niveau actuel et cible, à documenter les écarts et à mettre en œuvre un plan d’action. Ses fonctions RESPOND et RECOVER soutiennent le confinement des incidents DLP, l’analyse de la cause racine, la conservation des preuves et la restauration.

COBIT 2019 ajoute une perspective de gouvernance. Un auditeur orienté COBIT demandera si les objectifs DLP sont alignés sur les objectifs de l’entreprise, si la propriété est claire, si des indicateurs de performance existent, si l’appétence au risque est définie et si la direction reçoit un reporting utile.

Comment les auditeurs testeront votre programme DLP

Les audits DLP portent rarement sur une seule capture d’écran. Des profils d’audit différents entraînent des attentes différentes en matière de preuves.

Un dossier d’audit DLP solide comprend la déclaration de périmètre et de risque, le schéma de classification, les méthodes de transfert approuvées, les règles DLP, les approbations de dérogations, la conception de journalisation, la procédure de triage des alertes, l’arbre de décision de notification des incidents, l’inventaire fournisseurs et cloud, les résultats de tests et les enregistrements de remédiation.

Échecs DLP fréquents en 2026

Les échecs DLP les plus fréquents sont opérationnels, pas exotiques.

Premièrement, la classification est facultative ou incohérente. Les étiquettes existent dans la politique, mais les utilisateurs ne les appliquent pas, les systèmes ne les imposent pas et les référentiels contiennent des années de fichiers sensibles non étiquetés.

Deuxièmement, le DLP reste indéfiniment déployé en mode alerte seule. Le mode alerte seule est utile pendant le réglage, mais un transfert à haut risque de données clients confidentielles vers une messagerie personnelle devrait finir par être bloqué, sauf s’il existe une dérogation approuvée.

Troisièmement, le shadow IT est traité comme une nuisance informatique plutôt que comme un risque de protection des données. La Politique d’utilisation du cloud et la Politique d’utilisation du cloud pour PME sont conçues pour rendre les outils cloud non approuvés visibles, revus et remédiables.

Quatrièmement, les journaux ne suffisent pas à l’investigation. Si l’équipe de sécurité ne peut pas reconstituer qui a accédé, partagé, téléchargé, téléversé ou modifié des autorisations, l’organisation ne peut pas évaluer avec confiance ses obligations de notification au titre de GDPR, NIS2 ou DORA.

Cinquièmement, les fournisseurs sont hors du modèle DLP. DORA Articles 28 à 30 rendent ce point particulièrement dangereux pour les entités financières, mais le problème touche tous les secteurs. Les contrats doivent définir les lieux de données, l’accès, la récupération, la restitution, l’assistance en cas d’incident, les mesures de sécurité, la sous-traitance et les droits d’audit.

Sixièmement, la réponse aux incidents n’inclut pas les scénarios DLP. Un courriel mal adressé, un téléversement SaaS non autorisé ou un export CRM en masse doit disposer d’un playbook, de critères de gravité et d’un chemin de décision de notification.

Enfin, les organisations oublient les canaux physiques et humains. Le Zenith Blueprint rappelle que le DLP inclut les comportements de bureau propre, le déchiquetage sécurisé, les files d’impression verrouillées, les journaux d’audit des imprimantes et la sensibilisation des salariés. Un programme DLP qui ignore le papier, les captures d’écran et les conversations est incomplet.

Construire un programme DLP auquel les auditeurs peuvent faire confiance

Si votre programme DLP est actuellement une configuration d’outil, 2026 est l’année pour le transformer en système de contrôle gouverné et étayé par des preuves.

Commencez par trois actions pratiques :

1. Sélectionnez vos trois principaux types de données sensibles, par exemple les données à caractère personnel clients, les informations de carte de paiement et le code source.
2. Cartographiez leurs mouvements, y compris courriel, SaaS, stockage cloud, terminaux, interfaces de programmation (API), fournisseurs et environnements de développement.
3. Construisez une règle DLP applicable par type de données, reliée à la politique, à la journalisation, à la réponse aux incidents et à la conservation des preuves.

Clarysec peut vous aider à accélérer cette démarche avec le Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur Zenith Blueprint, les Zenith Controls : guide de conformité croisée Zenith Controls, ainsi que des politiques prêtes à adapter telles que la Politique de classification et d’étiquetage des données Politique de classification et d’étiquetage des données, la Politique de télétravail Politique de télétravail, la Politique d’utilisation du cloud Politique d’utilisation du cloud, la Politique de journalisation et de surveillance pour PME Politique de journalisation et de surveillance - PME, et la Politique relative aux appareils mobiles et au BYOD Politique relative aux appareils mobiles et au BYOD.

L’objectif n’est pas d’empêcher chaque fichier de circuler. L’objectif est de faire du mouvement sécurisé le comportement par défaut, de rendre les mouvements risqués visibles, de bloquer les mouvements interdits et de rendre chaque exception imputable.

Téléchargez les kits Clarysec, passez en revue votre dossier de preuves DLP et planifiez une évaluation de préparation afin de vérifier si vos contrôles actuels peuvent résister à l’examen de GDPR Article 32, aux attentes d’hygiène cyber de NIS2 et à la revue du risque lié aux TIC selon DORA.