RGPD article 32 : tester l’efficacité de vos mesures de sécurité

Le 13 janvier 2026, la CNIL a infligé 42 millions d’euros d’amendes à Free Mobile (27 millions) et à Free (15 millions). Au titre de l’article 32 du RGPD, elle relève entre autres une authentification au VPN jugée insuffisante et des dispositifs de détection des comportements anormaux jugés inefficaces. Nous retenons surtout ce second point : des contrôles existaient, ils ne produisaient pas l’effet attendu. Pour un DPO, toute la question du point 1 d) est là.

L’article 32 du RGPD impose au responsable du traitement et au sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. Son point 1, d), va plus loin : il demande une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité de ces mesures. Il vous faudra donc démontrer que vos contrôles fonctionnent.

Dans beaucoup de registres de conformité, ce point d) reste le parent pauvre. Vous y trouvez le chiffrement, la gestion des accès, la sauvegarde. Vous y trouverez beaucoup moins la manière de vérifier que ces mesures tiennent encore 6 mois plus tard. Or la CNIL a annoncé qu’en 2026, la moitié de ses contrôles et de ses actions répressives porteraient sur la sécurité des données.

RGPD article 32 : ce que dit exactement le texte

Le paragraphe 1 de l’article 32 cite, « entre autres, selon les besoins », quatre familles de mesures :

• a) la pseudonymisation et le chiffrement des données à caractère personnel ;
• b) des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes et des services de traitement ;
• c) des moyens permettant de rétablir la disponibilité et l’accès aux données en temps utile en cas d’incident physique ou technique ;
• d) une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement.

Le paragraphe 2 précise que l’évaluation du niveau de sécurité tient compte des risques présentés par le traitement, notamment la destruction, la perte, l’altération, la divulgation non autorisée de données ou l’accès non autorisé. La divulgation non autorisée, c’est la fuite de données. Si votre procédure de test l’ignore, il manque une pièce à votre démonstration.

Pourquoi un audit de configuration ne suffit pas

Une règle peut être active et ne rien bloquer. Un agent peut être installé sur vos postes Windows mais désynchronisé. Une inspection TLS peut exclure, pour de bonnes raisons de compatibilité, le domaine même qu’un attaquant utiliserait. Rien de cela n’apparaît sur une console d’administration. Cela n’apparaît qu’en tentant de faire sortir une donnée : c’est notre métier. Nous détaillons ce mécanisme dans l’article sur les faux négatifs DLP et les règles qui échouent en silence.

La position la plus défendable, à notre sens, est donc simple : pour le risque de divulgation non autorisée, tester l’efficacité signifie tenter, de manière contrôlée, de reproduire une fuite, et constater ce qui est bloqué, détecté ou passe inaperçu.

Construire une procédure de test conforme à l’esprit du point d)

1. Partir des traitements, avant les outils. Le registre des traitements (article 30) liste déjà les catégories de données et leur sensibilité. Servez-vous-en pour choisir ce que vous testez en priorité : données de santé, données RH, données bancaires, fichiers clients.
2. Définir les canaux de sortie à couvrir. Une procédure crédible couvre au minimum :
   • la messagerie sortante (Outlook, Gmail) et les pièces jointes ;
   • le web, y compris les flux chiffrés ;
   • les supports amovibles et le poste de travail ;
   • le cloud personnel (Dropbox, WeTransfer), les outils collaboratifs et les applications SaaS ;
   • les canaux réseau moins surveillés, comme la résolution DNS.
3. Utiliser des données synthétiques. Tester avec de vraies données personnelles pour vérifier la protection des données personnelles serait un contresens, et un traitement de plus à justifier. Les leurres (faux numéros de sécurité sociale au format valide, faux IBAN, documents marqués) déclenchent les mêmes règles sans utiliser de donnée métier réelle. L’article sur les données synthétiques pour tester en production explique comment les construire.
4. Fixer une fréquence et des déclencheurs. « Régulièrement » se traduit par une cadence de base adaptée au périmètre, complétée par des tests déclenchés par les changements : migration vers Microsoft 365, nouvelle version de l’agent, refonte du proxy, arrivée de Slack ou de Teams. C’est souvent après ces changements que les contrôles se dégradent. Avec Enforcis, chaque campagne produit un résultat daté. Les prochaines versions permettront de programmer des rejeux périodiques ou déclenchés par un changement, selon la criticité du périmètre et la fraîcheur attendue de la preuve.
5. Analyser et décider. Le texte enchaîne trois verbes : tester, analyser, évaluer. Chaque campagne doit donc produire une décision : ce qui est corrigé, dans quel ordre et par qui. Chez Enforcis, chaque scénario testé produit un résultat daté, lu en 3 états (Bloqué, Détecté sans blocage, Non détecté) ; les prochaines versions apporteront des recommandations contextualisées et priorisées, validées par retest. Une personne de votre équipe tranche. Sans décision derrière, vous aurez juste un rapport de plus dans un dossier.

Ce qu’un DPO peut montrer

Le DPO n’a pas vocation à mener les tests. En revanche, lors d’un contrôle de la CNIL ou d’un audit interne, c’est souvent vous qui présentez le dossier.

Ce dernier point pèse lourd, et nous y tenons. Une série de mesures dans le temps montre que l’organisation pilote sa sécurité, au sens du principe de responsabilité (article 5, paragraphe 2, et article 24). Un résultat isolé, même bon, prouve peu.

Scénario concret : l’ETI qui pensait être couverte

Imaginez une ETI de services de 800 salariés, avec un DPO mutualisé et pas de RSSI dédié. Sa DLP de messagerie bloque les envois contenant des numéros de sécurité sociale. Le registre le mentionne, le DPO le croit. En mars, une première campagne de l’équipe interne, avec des données synthétiques, le confirme pour l’e-mail envoyé depuis Outlook. Mais le même fichier, déposé depuis le navigateur sur un Dropbox personnel (technique T1567.002 de MITRE ATT&CK), passe sans alerte. Le DPO dispose alors d’un constat précis, une action prioritaire et, en avril, un re-test qui montre que ce scénario est désormais bloqué.

Checklist pour votre prochain comité conformité

• La procédure de test du point d) existe-t-elle par écrit, avec un responsable nommé ?
• Couvre-t-elle explicitement le risque de divulgation non autorisée ?
• Les tests utilisent-ils exclusivement des données synthétiques ?
• Les canaux couverts correspondent-ils aux usages réels (cloud, SaaS, navigateur, assistants d’IA comme Copilot) ?
• Chaque campagne débouche-t-elle sur des actions hiérarchisées et datées ?
• Disposez-vous d’un historique permettant de montrer une tendance ?
• Un changement d’infrastructure déclenche-t-il un retest ?

Le raisonnement vaut d’ailleurs pour d’autres textes : pour les entités concernées, NIS2 pousse aussi vers la preuve du fonctionnement des mesures.

FAQ