Ce que les Auditeurs Voient Lorsqu'ils Demandent des Contrôles PII
Lors d'un audit d'autorité de surveillance GDPR ou d'une évaluation ISO 27001, l'une des questions standard est : "Quels contrôles techniques avez-vous pour l'anonymisation des PII ?"
L'auditeur recherche une réponse claire et défendable : un contrôle spécifique, appliqué de manière cohérente, avec une documentation sur son fonctionnement et des preuves de son efficacité.
La réponse qui crée un risque de conformité : "Nous utilisons différents outils selon le contexte. Pour la navigation web, nous utilisons l'extension Chrome, pour les documents Word, nous utilisons une macro, pour les fichiers en vrac, notre équipe de données a un script Python qu'elle a écrit, et pour les demandes urgentes, nous utilisons l'application web."
Cette réponse déclenche un suivi : "Quelles sont les différences de couverture entre ces outils ? Comment garantissez-vous des résultats cohérents entre les outils ? Où est la piste de vérification qui démontre une application cohérente ?"
Ce sont des questions auxquelles des outils fragmentés ne peuvent pas répondre clairement.
Le Problème de la Cohérence de Couverture
Différents outils de détection de PII utilisent différentes approches de détection sous-jacentes :
Outils uniquement Regex : Recherchent des motifs spécifiques (format SSN, format email, format de carte de crédit). Manquent les entités basées sur NER (noms de personnes, organisations ne correspondant pas à une liste connue), identifiants contextuels et formats non américains.
Outils uniquement NER : Détectent les types d'entités en utilisant des modèles entraînés. Manquent les entités basées sur des motifs (IBAN, numéros de compte avec des formats spécifiques), identifiants organisationnels personnalisés et entités non présentes dans les données d'entraînement.
Outil A vs. Outil B vs. Outil C : Chacun a une couverture de type d'entité différente, des seuils de confiance différents, un traitement différent des cas particuliers. Le même document traité par l'Outil A et l'Outil C peut produire des résultats de détection différents.
Le problème de conformité : si l'Outil A (utilisé pour les PDF) détecte les dates de naissance mais que l'Outil B (utilisé pour Excel) ne le fait pas, alors la date de naissance du même sujet de données dans un PDF est anonymisée tandis que sa date de naissance dans une feuille de calcul Excel ne l'est pas. Le contrôle de conformité systématique présente un écart qui dépend du format du document.
Pour les enquêtes des APD, cet écart est découvrable. Si une violation de données se produit et que l'enquête révèle que la version feuille de calcul Excel des dossiers d'un sujet de données n'a pas été anonymisée tandis que la version PDF l'a été, l'incohérence entre les outils est un facteur contribuant à l'exposition.
Le Problème de la Piste de Vérification
La documentation de conformité nécessite des preuves que les contrôles sont appliqués de manière cohérente. Pour l'anonymisation des PII, la preuve est la piste de vérification : ce qui a été traité, quand, par qui, avec quel outil, et quel a été le résultat.
Quatre outils différents produisent quatre formats de piste de vérification différents — ou aucune piste de vérification du tout. Une macro Word ne produit pas de journal d'audit. Un script Python peut écrire dans un fichier local qui n'est pas intégré au système de gestion de la conformité. L'extension Chrome peut produire des journaux côté navigateur non accessibles pour la documentation de conformité. Seule l'application web peut produire une piste de vérification centralisée.
Pour une enquête de l'APD nécessitant des preuves de piste de vérification, la réponse "nous avons traité ce document dans une macro Word, ces journaux sont sur la machine locale du développeur" n'est pas satisfaisante. La réponse "voici le journal d'audit centralisé couvrant tout le traitement d'anonymisation sur toutes les plates-formes pour la période demandée" est satisfaisante.
Le traitement sur une seule plate-forme permet une couverture de piste de vérification unique. Les outils fragmentés rendent impossible une piste de vérification centralisée.
Le Problème de la Dérive de Configuration
Au fil du temps, différents outils utilisés par différents membres de l'équipe développent différentes configurations :
- L'extension Chrome est configurée avec les types d'entités personnalisés de l'organisation
- Le script Python n'a pas été mis à jour lorsque les types d'entités personnalisés ont été ajoutés
- La macro Word a été configurée par un membre de l'équipe qui est depuis parti, et personne ne connaît les paramètres actuels
- Le préréglage de l'application web a été mis à jour le mois dernier pour exclure les noms des contractuels, mais cette mise à jour n'a pas été propagée aux autres outils
La dérive de configuration crée le problème d'incohérence à l'envers : même si tous les outils produisaient à l'origine des résultats similaires, une activité de maintenance sur un outil sans mettre à jour les autres crée une divergence au fil du temps.
Pour les contrôles ISO 27001, l'exigence de documentation de configuration rend cela particulièrement problématique. Un auditeur ISO demandant "montrez-moi la configuration de vos contrôles d'anonymisation des PII" ne peut pas être répondu de manière satisfaisante par "nous avons quatre outils avec quatre configurations différentes, et nous ne sommes pas sûrs qu'elles soient toutes à jour."
La Découverte ISO 27001
Une équipe de 15 personnes d'une société de conseil en conformité a utilisé quatre outils différents : un outil de scraping web pour les données en ligne, un outil de bureau Windows autonome pour les fichiers en vrac, une macro Word pour les documents juridiques, et une extension Chrome pour les outils d'IA.
Un audit ISO 27001 a produit une découverte : "Procédures d'anonymisation des données incohérentes entre les plates-formes. Différents outils utilisés pour différents contextes produisent des résultats de détection différents et aucune piste de vérification centralisée. Cela crée un écart dans le contrôle ISO/IEC 27001:2022 Annexe A 8.11 (Masquage des données) — le contrôle ne peut pas être démontré comme appliqué de manière cohérente."
La découverte de l'audit a nécessité un plan d'action correctif. L'action corrective mise en œuvre : consolidation sur une seule plate-forme d'anonymisation pour tous les cas d'utilisation.
Résultats après consolidation :
- Même moteur de détection sur toutes les plates-formes (Application Web, Application de Bureau, Add-in Office, Extension Chrome)
- Même préréglage appliqué à travers les contextes
- Piste de vérification centralisée pour tout le traitement
- Découverte ISO 27001 clôturée lors du prochain audit de surveillance
Le projet de consolidation de 6 semaines a éliminé la découverte d'audit qui avait nécessité une réponse corrective de 12 pages.
Le Test de Narratif de Conformité
Un test utile pour évaluer la fragmentation des outils PII : pouvez-vous répondre clairement aux questions suivantes ?
- Quels types d'entités sont détectés sur toutes les plates-formes que votre équipe utilise pour l'anonymisation des PII ?
- Quel est le seuil de détection (niveau de confiance) pour chaque type d'entité, de manière cohérente sur toutes les plates-formes ?
- Où est la piste de vérification centralisée pour tout le traitement d'anonymisation au cours des 12 derniers mois ?
- Comment garantissez-vous que les changements de configuration sont appliqués de manière cohérente sur toutes les plates-formes ?
Si l'une de ces questions produit une réponse hésitante, la fragmentation crée un risque de conformité. La réponse claire à ces quatre questions est réalisable — mais seulement avec un moteur unifié sur toutes les plates-formes.
Sources :