ISO 27001 contrôle 8.12 : prouver la prévention des fuites de données

Votre audit ISO 27001 tombe en avril, dans 6 mois. Ce jour-là, l’auditeur ouvrira votre déclaration d’applicabilité, s’arrêtera sur la mesure 8.12 et vous posera une question simple : « Comment savez-vous qu’elle fonctionne ? » Si votre réponse tient en trois captures d’écran de console, ces 6 mois permettent d’y remédier.

Le contrôle 8.12 de l’annexe A de l’ISO/IEC 27001:2022, intitulé « prévention des fuites de données », demande d’appliquer des mesures de prévention des fuites aux systèmes, réseaux et appareils qui traitent, stockent ou transmettent des informations sensibles. L’auditeur ne s’arrête pas à « avez-vous une DLP ? ». Il veut savoir si vous pouvez démontrer qu’elle fonctionne, et la meilleure preuve reste une trace de test datée, reproductible et suivie d’actions correctives.

Ce que dit le contrôle 8.12 de l’ISO 27001

Le contrôle 8.12 fait partie des mesures introduites lors de la refonte de 2022, qui a réorganisé l’annexe A en quatre thèmes (organisationnel, humain, physique, technologique). Il se situe dans le thème technologique. Son esprit, tel que nous le lisons, est simple : identifier les informations à protéger, surveiller les canaux par lesquels elles peuvent sortir, et agir pour empêcher ou détecter leur divulgation non autorisée.

La norme et son guide d’application (ISO/IEC 27002:2022) vous invitent à regarder plusieurs dimensions :

• l’identification et la classification des informations sensibles, ce qui renvoie directement au contrôle 5.12 sur la classification ;
• la surveillance des canaux de sortie : messagerie, transferts de fichiers, supports amovibles, services cloud, navigateur ;
• les actions de prévention : blocage, mise en quarantaine, alerte ;
• l’équilibre avec la vie privée des collaborateurs et le droit applicable, en France le RGPD et le droit du travail.

Un auditeur ne vous reprochera pas l’absence d’un outil précis. Il vous reprochera en revanche une mesure déclarée dans la déclaration d’applicabilité sans élément tangible qui montre son efficacité.

Pourquoi la configuration ne suffit pas comme preuve

En pratique, beaucoup d’organismes arrivent en audit avec des captures d’écran de règles DLP, une politique de classification et un export de la console. C’est la base. Mais rien là-dedans ne montre qu’un fichier a été arrêté.

Une règle peut être active et ne rien bloquer. Un connecteur peut avoir perdu sa couverture après une mise à jour. Un canal peut ne jamais avoir été couvert. Ces faux négatifs DLP ne font pas de bruit : aucune alerte ne signale ce qui n’a pas été détecté. La clause 9.1 de la norme, qui porte sur la surveillance, la mesure, l’analyse et l’évaluation, demande de déterminer comment vous évaluez l’efficacité du système de management. Pour la mesure 8.12, cela passe selon nous par des essais.

Les preuves qu’un auditeur s’attend à trouver

Dans le tableau ci-dessous, nous séparons ce qui déclare de ce qui démontre. Vous aurez besoin des deux, mais seuls les seconds répondent à la question de l’efficacité.

Construire des traces de tests recevables

Une trace de test utile en audit répond à cinq questions : quoi, par où, quand, avec quel résultat, et qu’avez-vous fait ensuite. Voici comment nous la construisons.

1. Cartographier les canaux de sortie. Listez les chemins par lesquels une donnée peut quitter l’organisme : messagerie sortante, web en HTTPS, DNS, stockage cloud personnel comme Dropbox ou WeTransfer, Teams ou Slack, périphériques USB, applications SaaS, prompts vers Copilot ou un autre assistant d’IA. Cette liste devient votre matrice de couverture. Pour chaque canal, notez le contrôle censé agir (DLP endpoint, proxy, CASB, passerelle de messagerie).
2. Utiliser des données synthétiques. Tester avec de vraies données sensibles crée précisément le risque à éviter. Des données synthétiques qui imitent les motifs réels (numéros au bon format, documents marqués avec vos étiquettes de classification, par exemple « Confidentiel » dans Microsoft Purview^™) vous laissent tester en production sans utiliser de donnée métier réelle. Votre DPO appréciera.
3. Rejouer les mêmes scénarios dans le temps. Un test ponctuel prouve l’état d’un jour. Rejouer régulièrement les mêmes scénarios montre une posture dans la durée, et attrape les régressions après une mise à jour, une migration ou un changement de règle. 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. Pour situer ces approches, voyez la comparaison entre validation continue, pentest et red team.
4. Consigner le résultat par scénario. Pour chaque scénario : date, canal, type de donnée synthétique, contrôle attendu, résultat observé (bloqué, détecté sans blocage, non détecté), et délai de détection éventuel côté SOC. Les résultats Enforcis suivent cette logique : 3 états, datés et traçables. Les prochaines versions apporteront un reporting à plusieurs niveaux (direction, RSSI, opérations), avec des correspondances MITRE ATT&CK et, lorsque la correspondance est établie, MITRE D3FEND, ainsi que des intégrations SIEM.
5. Relier chaque écart à une action. Un écart non traité affaiblit le dossier. Un écart classé, confié à quelqu’un puis retesté le renforce : il montre que le système de management tourne. C’est ce qu’attend la clause 10 sur l’amélioration.

Scénario concret : l’audit de surveillance

Imaginez un industriel certifié depuis 2024 qui prépare son audit de surveillance. L’auditeur échantillonne le contrôle 8.12. Le RSSI présente la politique, l’export des règles Purview et 3 mois de scénarios rejoués sur 6 canaux.

Les résultats montrent que la messagerie bloque correctement les pièces jointes étiquetées « confidentiel ». En revanche, le dépôt vers un stockage cloud personnel depuis un navigateur non géré a passé sans alerte pendant 4 semaines, entre juin et juillet. Le dossier contient le ticket de correction, la règle ajoutée et le retest réussi.

L’auditeur n’en fait pas une non-conformité. Il a néanmoins sous les yeux un contrôle surveillé et corrigé. Sans ces traces, l’angle mort serait resté invisible, et vous auriez discuté captures d’écran.

Checklist 8.12 avant l’audit

• Le contrôle 8.12 figure dans la déclaration d’applicabilité, avec sa justification.
• Les informations sensibles sont classifiées et les étiquettes sont exploitées par les outils.
• Une matrice canaux / contrôles existe et elle est à jour.
• Des tests ont été menés sur chaque canal de la matrice, avec des données synthétiques.
• Vos résultats sont datés, conservés, et suivent le même format.
• Chaque écart a une priorité, un responsable, une échéance et un retest.
• Des indicateurs de suivi sont présentés à la direction lors de la revue de direction.
• Le DPO a validé l’encadrement de la surveillance au regard de la vie privée.

Le contrôle 8.12 recoupe d’autres exigences. Si vous êtes aussi concerné par la directive européenne, l’article sur NIS2 et la preuve des mesures de protection montre comment mutualiser les mêmes traces. Pour le cadre général, consultez la page de référence sur le test d’exfiltration de données.

FAQ