Gouvernance des données à caractère personnel (PII) pour ISO/IEC 27701:2025 et GDPR

La demande est arrivée dans la boîte de réception du RSSI avec une simplicité trompeuse : « Project Wellness ». Une fintech en forte croissance souhaitait analyser des données de transactions clients existantes afin de proposer des conseils d’épargne personnalisés, des recommandations de produits et des indicateurs de risque d’attrition. Le marketing y voyait de l’engagement client. Le produit y voyait de l’innovation. La direction y voyait un avantage concurrentiel.

Le RSSI y voyait un enjeu de gouvernance majeur.

Les données de transaction avaient été collectées pour le traitement des paiements, selon une finalité et une base légale définies. L’entreprise souhaitait désormais les réutiliser pour des analyses de bien-être financier, la personnalisation de campagnes et la notation prédictive. Pour accélérer la livraison, l’équipe voulait également transmettre un jeu de données pseudonymisé à un fournisseur tiers d’analytique IA.

Aucun attaquant n’était présent sur le réseau. Aucune base de données n’avait fuité. Aucun ticket d’incident ne clignotait en rouge.

Pourtant, c’est précisément là que commencent de nombreuses défaillances de responsabilité au titre du GDPR.

La question n’est pas de savoir si l’organisation dispose d’une mention d’information, d’un délégué à la protection des données, d’un registre des bases légales ou d’un calendrier de conservation. La question de fond est opérationnelle : qui approuve une nouvelle collecte de PII, qui confirme la nécessité, qui définit les règles d’utilisation interne autorisée, qui décide si la réutilisation est compatible, qui autorise la divulgation à un fournisseur, et qui peut prouver la décision par la suite ?

C’est cette lacune de contrôle que les mises en œuvre du système de management des informations relatives à la vie privée ISO/IEC 27701:2025, ou PIMS, doivent combler. GDPR Article 5 exige que les données à caractère personnel soient traitées de manière licite, loyale et transparente, collectées pour des finalités déterminées, explicites et légitimes, limitées à ce qui est nécessaire, exactes, conservées uniquement pendant la durée requise, protégées de manière appropriée et traitées sous la responsabilité du responsable du traitement. GDPR Article 6 ajoute la logique de base légale et de compatibilité pour les traitements ultérieurs. Mais ces principes ne deviennent défendables que lorsqu’ils sont traduits en processus, registres, approbations, règles d’accès, contrôles fournisseurs, surveillance et éléments probants.

L’approche de Clarysec est simple : traiter la gouvernance de la collecte, de l’utilisation et de la divulgation des PII comme un modèle opérationnel maîtrisé, et non comme une note juridique. Le modèle s’inscrit dans l’ossature du SMSI ISO/IEC 27001:2022, s’étend aux rôles PIMS ISO/IEC 27701:2025, et s’appuie sur les politiques, registres, Zenith Blueprint : feuille de route d’audit en 30 étapes et Zenith Controls : guide de conformité croisée de Clarysec.

Pourquoi la gouvernance des PII échoue même lorsque les documents de protection des données existent

La plupart des programmes de protection des données n’échouent pas parce que personne ne connaît GDPR. Ils échouent parce que les décisions relatives à la protection des données sont prises dans des tickets produit, des courriels d’intégration des fournisseurs, des exports de tableurs, des expérimentations de tableaux de bord et des pilotes IA, sans point de contrôle reproductible.

Le schéma type est familier :

1. Une équipe ajoute un nouveau champ à un formulaire d’inscription parce qu’il améliore la segmentation.
2. Personne ne consigne pourquoi ce champ précis est nécessaire.
3. Une autre équipe réutilise ensuite les données pour une finalité différente.
4. Un fournisseur reçoit un export au titre d’un accord de services général.
5. Le registre des traitements est mis à jour après la mise en production, lorsqu’il l’est.
6. Lors de l’audit, l’organisation peut présenter une mention d’information, mais pas les éléments probants de la décision.

GDPR Articles 4 et 5 définissent largement le traitement. La collecte, l’enregistrement, le stockage, l’utilisation, la divulgation, l’effacement et la destruction sont tous concernés. Article 5 rend également explicite la responsabilité. Les responsables du traitement doivent être en mesure de démontrer la conformité aux principes.

La question d’audit n’est donc pas seulement : « Disposez-vous d’une politique ? » Elle devient : « Montrez-moi comment cet élément de données précis a été approuvé, pourquoi il était nécessaire, comment il a été utilisé, qui l’a reçu et quels contrôles ont empêché les usages abusifs. »

La P17 Politique de protection des données et de la vie privée de Clarysec définit clairement l’exigence de cycle de vie :

Elle formalise les responsabilités de l’entreprise au regard des normes internationales et des cadres réglementaires, en veillant à ce que les informations personnelles (PII) soient collectées, traitées, conservées, partagées et éliminées de manière licite, sécurisée et transparente.

Pour les PME, la Politique de protection des données et de la vie privée - PME de Clarysec transforme le même principe en règle opérationnelle pragmatique :

Les données à caractère personnel ne peuvent être collectées que lorsqu’elles sont nécessaires à une finalité légitime, licite ou contractuelle.

Et pour la minimisation :

Seules les données à caractère personnel strictement nécessaires doivent être collectées et conservées.

Ces énoncés ne sont efficaces que s’ils sont appliqués avant le début du traitement. À défaut, ils restent un langage de protection des données sans preuve opérationnelle.

L’objectif de contrôle : arrêter les traitements non maîtrisés à trois points de passage

Un PIMS robuste doit contrôler les décisions relatives aux PII à trois moments : avant la collecte, avant l’utilisation et avant la divulgation.

Avant la collecte, l’organisation doit savoir ce qu’elle souhaite collecter, auprès de qui, par quel canal, pour quelle finalité, selon quelle base légale, et pourquoi chaque champ est nécessaire.

Avant l’utilisation, l’organisation doit définir les règles d’utilisation interne autorisée. Le support, la réussite client, le marketing, la fraude, la finance et l’ingénierie ont rarement besoin du même niveau de visibilité ou de la même autorisation d’agir sur les PII.

Avant la divulgation, l’organisation doit savoir qui est le destinataire, quel rôle il joue, pourquoi la divulgation est nécessaire, où le traitement a lieu, quelles catégories de PII sont partagées, à quelle fréquence le partage intervient et quelle autorité permet ce partage.

La PII09 Politique de collecte, d’utilisation, de divulgation et de partage des PII de Clarysec est conçue pour cette couche de gouvernance. Elle utilise un marquage des rôles PIMS, en particulier le rôle de responsable du traitement, car les décisions de collecte, d’utilisation et de divulgation relèvent généralement de l’organisation qui détermine les finalités et les moyens.

Pour la limitation de la collecte, la PII09 Politique de collecte, d’utilisation, de divulgation et de partage des PII exige :

[Responsable du traitement] Le responsable de processus / propriétaire métier DOIT consigner dans REG02 la finalité de la collecte, la source ou le canal, les catégories de PII, les catégories de personnes concernées et les éléments de données minimaux avant le début de toute nouvelle activité de collecte ou modification substantielle de la collecte.

Elle rend ensuite la minimisation vérifiable :

[Responsable du traitement] Le responsable de processus / propriétaire métier DOIT consigner dans REG02 une justification de nécessité pour chaque élément de données PII avant sa collecte.

L’exigence « chaque élément de données PII » fait la différence entre un inventaire des traitements générique et des éléments probants de responsabilité au niveau du champ.

Pour l’utilisation interne, la même politique exige :

[Responsable du traitement] Le responsable de processus / propriétaire métier DOIT consigner dans REG02 les règles d’utilisation interne approuvées pour chaque activité de traitement avant le début de l’utilisation.

Pour la réutilisation :

[Responsable du traitement] Le responsable de processus / propriétaire métier DOIT consigner dans REG02 un test de compatibilité de réutilisation avant que les PII soient utilisées pour une finalité non déjà approuvée pour l’activité de traitement.

Et pour la divulgation externe :

[Responsable du traitement] Le responsable des fournisseurs / des achats DOIT consigner dans REG08 l’identité du destinataire, son rôle, la finalité de la divulgation, les catégories de PII, la fréquence de partage, le lieu de traitement et la source d’autorisation avant le début de tout partage externe récurrent.

Ces clauses apportent une réponse claire lorsque la direction demande si l’entreprise peut innover rapidement : oui, si la décision passe par un processus de gouvernance documenté et si les contrôles correspondent à l’approbation.

REG02 et REG08 : la chaîne politique-contrôle de Clarysec

Dans les mises en œuvre Clarysec, REG02 n’est pas un inventaire des traitements passif. C’est l’enregistrement de décision relatif à la finalité de collecte, à la base légale, aux catégories de PII, à la nécessité, aux règles d’utilisation interne, à l’alignement avec la conservation et à la compatibilité de la réutilisation.

REG08 est le registre de contrôle des divulgations et des partages. Il est particulièrement important pour les fournisseurs, partenaires, sociétés du groupe, autorités, sous-traitants ultérieurs, intégrations et exports récurrents.

Ensemble, ils créent une chaîne politique-contrôle qui peut être testée par les équipes protection des données, sécurité, achats et audit.

Ce modèle s’aligne naturellement sur ISO/IEC 27001:2022. Les clauses 4 à 10 exigent que l’organisation comprenne le contexte, les exigences des parties intéressées, le domaine d’application, les responsabilités de la direction, l’appréciation des risques, le traitement des risques, la maîtrise opérationnelle, l’évaluation des performances et l’amélioration. Les obligations de protection des données au titre de GDPR et d’ISO/IEC 27701:2025 deviennent une partie du système de management, et non une enclave séparée.

ISO/IEC 27002:2022 soutient également le modèle opérationnel. La mesure 5.31, Exigences légales, statutaires, réglementaires et contractuelles, ancre GDPR et les obligations sectorielles. La mesure 5.34, Protection de la vie privée et protection des PII, couvre la protection propre à la vie privée. La mesure 5.9, Inventaire des informations et des autres actifs associés, soutient la connaissance des données. Les mesures 5.12 et 5.13 soutiennent la classification et l’étiquetage. La mesure 5.14 régit le transfert d’information. Les mesures 5.19 à 5.23 couvrent les relations avec les fournisseurs, les accords fournisseurs, la chaîne d’approvisionnement TIC, la surveillance des services fournisseurs et les services cloud. La mesure 8.11 soutient le masquage des données, 8.12 la prévention des fuites de données, 8.15 la journalisation, 8.16 les activités de surveillance et 8.24 l’utilisation de la cryptographie.

Zenith Blueprint inscrit ces contrôles dans un parcours de mise en œuvre. Dans la phase Contrôles en action, l’étape 23 couvre les contrôles organisationnels 5.19 à 5.37, y compris la mesure 5.34 relative à la protection de la vie privée et à la protection des PII. Le Blueprint explique :

Dans le monde actuel axé sur les données, les informations personnellement identifiables ne sont pas simplement un type de données supplémentaire : elles constituent une représentation profondément sensible de la confiance. Noms, adresses, identifiants, dossiers de santé, informations financières : ces données racontent une histoire sur des personnes réelles.

Il donne ensuite le socle opérationnel :

Le fondement de cette mesure est la connaissance des données. L’organisation doit savoir quelles PII elle collecte, où elles résident, pourquoi elles sont traitées et qui peut y accéder.

C’est ce que REG02 et REG08 fournissent lorsqu’ils sont traités comme des enregistrements de gouvernance vivants.

Exemple pratique : approuver Project Wellness sans perdre le contrôle

Revenons au scénario de la fintech. L’entreprise veut analyser les données de transactions clients pour produire des recommandations personnalisées de bien-être financier. Le marketing souhaite utiliser les résultats pour des campagnes. Le produit souhaite construire des scores d’attrition et d’engagement. Une plateforme tierce d’analytique IA traitera une partie du jeu de données.

Voici comment Clarysec encadrerait la demande.

Étape 1 : créer ou mettre à jour l’activité de traitement REG02

Le responsable de processus ouvre REG02 et consigne l’activité de traitement avant le début des travaux.

Le point essentiel est le moment. REG02 est mis à jour avant le début du nouveau traitement, et non après la mise en production de la fonctionnalité.

Étape 2 : consigner les justifications de nécessité au niveau du champ

Le marketing demande initialement cinq ans d’historique complet de transactions, y compris les noms des commerçants, les horodatages exacts, les métadonnées de carte et les attributs de profil client. L’équipe de gouvernance remet en cause chaque champ.

C’est la minimisation des données sous forme d’éléments probants, et non comme une intention. L’entreprise conserve des analyses utiles, mais le jeu de données est réduit à ce qui est nécessaire pour la finalité approuvée.

Étape 3 : classifier et étiqueter le jeu de données

Le jeu de données est classifié selon la Politique de classification et d’étiquetage des données de Clarysec. La version PME exige :

Le partage externe doit être explicitement autorisé et journalisé.

La Politique de classification et d’étiquetage des données d’entreprise ajoute une mesure de protection pour les informations sensibles :

Peut uniquement être partagé en externe dans le cadre d’un accord de non-divulgation ou de mesures de protection contractuelles équivalentes.

En pratique, le jeu de données Project Wellness ne peut pas être exporté de manière informelle vers une plateforme IA. Il nécessite un enregistrement de divulgation approuvé, des garanties contractuelles, des contrôles techniques de transfert et des journaux.

Zenith Blueprint, à l’étape 22 relative à la mesure 5.12 Classification de l’information, explique pourquoi cela compte :

Tout contrôle de sécurité de l’information jamais rédigé — restriction d’accès, chiffrement, sauvegarde, surveillance ou élimination — repose sur une hypothèse : l’organisation sait ce qu’elle protège.

Sans classification, les restrictions d’accès, le chiffrement, la DLP et les règles de conservation deviennent des approximations.

Étape 4 : définir les règles d’utilisation interne avant la mise en production

Le responsable de processus consigne les règles d’utilisation interne approuvées dans REG02. C’est souvent à ce stade que la dérive de finalité est arrêtée.

Un ensemble de règles défendable pourrait prévoir :

• Le produit peut utiliser des indicateurs agrégés de performance des recommandations.
• Le support client peut voir si une recommandation a été présentée à un client lorsqu’il traite une demande d’assistance.
• Le marketing ne peut pas utiliser des scores de bien-être au niveau individuel pour la segmentation de campagnes, sauf si un test de compatibilité de réutilisation est réalisé.
• La finance ne peut pas accéder aux analyses détaillées de bien-être, sauf s’il existe une finalité approuvée distincte.
• Les développeurs ne doivent pas utiliser de PII de production dans les environnements de test.
• L’évaluation des modèles IA doit utiliser des jeux de données masqués, pseudonymisés ou agrégés lorsque cela est possible.

Les deux dernières règles sont liées à la mesure ISO/IEC 27002:2022 8.11, Masquage des données. Zenith Blueprint, étape 19, décrit le masquage des données comme une méthode pratique pour prévenir l’exposition inutile dans les environnements de test, les jeux de données de formation, les plateformes analytiques, les intégrations tierces et les pipelines de test CI/CD.

Étape 5 : réaliser le test de compatibilité de réutilisation

Le marketing demande ensuite à utiliser les scores de bien-être pour des campagnes ciblées. Il s’agit d’une nouvelle finalité. En vertu de la clause 4.3.1 de la PII09 Politique de collecte, d’utilisation, de divulgation et de partage des PII, le propriétaire métier doit consigner un test de compatibilité dans REG02 avant le début de la nouvelle utilisation.

Le test doit évaluer :

• Si le marketing de bien-être financier est compatible avec la finalité initiale du traitement.
• Ce qui a été indiqué aux clients lors de la collecte et dans la mention d’information.
• Si les inférences dérivées des transactions peuvent être sensibles ou inattendues.
• Si la nouvelle utilisation peut créer une pression, une exclusion ou un profilage déloyal.
• Si des mesures de protection telles que l’agrégation, l’opposition, la pseudonymisation ou la segmentation au niveau du compte réduisent le risque.
• Si la base légale demeure valide.
• Si des mises à jour de transparence ou des mécanismes de consentement sont requis.

Le résultat peut être une approbation, une approbation assortie de mesures de protection ou un rejet. L’intérêt est que la décision soit documentée avant le début de l’utilisation.

Étape 6 : approuver la divulgation externe via REG08

Si le fournisseur d’analytique IA doit recevoir des données, le responsable des fournisseurs ou des achats consigne dans REG08 :

La Politique de sécurité des tiers et des fournisseurs - PME de Clarysec renforce l’accès fournisseur minimisé :

Les fournisseurs doivent obtenir uniquement l’accès minimal aux systèmes et aux données nécessaires à l’exécution de leur fonction.

C’est la minimisation relative à la vie privée appliquée à l’accès fournisseur et à la divulgation.

Étape 7 : ajouter la mise en application technique

Les enregistrements de gouvernance doivent être appuyés par des contrôles techniques. Pour Project Wellness, Clarysec recommanderait généralement des règles DLP pour les exports, des restrictions d’accès fondées sur les rôles, la journalisation des événements d’accès et de transfert, des jeux de données masqués pour le développement, le chiffrement des transferts et du stockage, des revues d’accès fournisseurs, des diligences préalables de sécurité cloud et des échantillonnages périodiques de REG02 et REG08 au regard du comportement réel des systèmes.

C’est ainsi que la responsabilité ISO/IEC 27701:2025 et GDPR devient un ensemble d’éléments probants opérationnels.

Cartographie des contrôles : de la décision de protection des données à la mise en application de la sécurité

La gouvernance des PII n’est pas un contrôle isolé. Elle repose sur l’articulation entre exigences de protection des données, contrôles de sécurité, gouvernance des fournisseurs et éléments probants d’audit.

Zenith Controls traite la mesure ISO/IEC 27002:2022 5.34, Protection de la vie privée et protection des PII, comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec les concepts cybersécurité Identifier et Protéger, et des capacités opérationnelles de protection de l’information, ainsi que juridiques et de conformité.

Pour 5.34, Zenith Controls cartographie l’écosystème de contrôles associé, notamment l’inventaire, la classification, le transfert, l’accès, l’identité, le cloud, la sécurité des fournisseurs, le masquage, la prévention des fuites, la journalisation, la surveillance et la cryptographie.

Pour le masquage, Zenith Controls indique :

Le masquage des données (8.11) est une technique souvent utilisée pour protéger les PII dans les environnements hors production ou lors du partage de données. Il soutient directement 5.34 en réduisant l’exposition de données à caractère personnel réelles, ce qui réduit le risque relatif à la vie privée.

Pour la prévention des fuites de données, le guide explique la limite opérationnelle :

La DLP joue un rôle direct dans la protection des données à caractère personnel. La mesure 8.12 impose des limites sur la manière dont les PII peuvent être consultées, partagées ou déplacées, afin que les données à caractère personnel ne puissent pas fuir par des canaux non autorisés.

Un auditeur qui teste la gouvernance des divulgations peut donc demander non seulement REG08, mais aussi les politiques DLP, les journaux de transferts bloqués, les contrôles des courriels sortants, les restrictions de partage cloud, les exigences de chiffrement, les enregistrements d’accès fournisseurs et les éléments probants des exceptions approuvées.

Valeur de conformité croisée : GDPR, ISO/IEC 27701, NIS2, DORA, NIST et COBIT

La gouvernance de la collecte, de l’utilisation et de la divulgation des PII est pilotée par la protection des données, mais ses éléments probants soutiennent des obligations plus larges de cybersécurité, de résilience et de gouvernance.

GDPR Articles 2 et 3 définissent un champ matériel et territorial large, qui peut inclure les fournisseurs SaaS, fintech et de services numériques situés hors de l’UE lorsqu’ils servent ou surveillent des personnes dans l’UE. Article 5 exige la limitation des finalités, la minimisation des données, l’exactitude, la limitation de la conservation, l’intégrité, la confidentialité et la responsabilité. Article 6 exige une base légale et une évaluation de compatibilité pour les traitements ultérieurs. Article 9 ajoute des conditions plus strictes pour les données relevant de catégories particulières, pertinentes lorsque du profilage, des données proches du domaine de la santé, une intégration biométrique ou des attributs sensibles sont impliqués.

NIS2 Article 21 exige des entités essentielles et importantes qu’elles mettent en œuvre des mesures techniques, opérationnelles et organisationnelles proportionnées de gestion des risques. Ses domaines minimaux incluent 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é, l’efficacité des contrôles, la formation, la cryptographie, la sécurité des ressources humaines, le contrôle d’accès, la gestion des actifs et l’authentification.

DORA impose aux entités financières de maintenir un cadre de gestion des risques liés aux TIC, la responsabilité de l’organe de direction, l’identification des actifs TIC et des dépendances, des contrôles de protection et de prévention, la détection, la réponse, le rétablissement, la sauvegarde, l’apprentissage, la gestion des incidents, les tests et la gestion des risques liés aux prestataires TIC tiers. Il impose également des registres d’informations pour les contrats de services TIC, des diligences préalables, des droits d’audit, des exigences de sécurité et des stratégies de sortie.

Le NIST Cybersecurity Framework 2.0 fournit un langage de gouvernance intégrateur. Sa fonction Gouverner attend que les exigences légales, réglementaires et contractuelles, y compris les obligations de protection des données, soient comprises et gérées. Elle couvre également la stratégie de risque, les rôles, les politiques, la supervision et la gestion des risques fournisseurs.

Les auditeurs COBIT 2019 recherchent des objectifs de gouvernance, des droits de décision, la responsabilité, la propriété des processus, des indicateurs de performance et des éléments probants d’assurance. Pour la gouvernance des PII, cela signifie que les exigences de protection des données doivent être intégrées à la gouvernance d’entreprise, et non gérées comme un processus périphérique.

Comment les auditeurs testent la même couche de gouvernance

Une mise en œuvre PIMS robuste doit résister à différents styles d’audit.

Un auditeur ISO/IEC 27001:2022 et ISO/IEC 27701:2025 commencera par le domaine d’application, les parties intéressées, les exigences légales et contractuelles, l’appréciation des risques, la Déclaration d’applicabilité, la planification opérationnelle et les informations documentées. Il peut échantillonner des activités de traitement dans REG02 et tester si des contrôles tels que 5.34, 5.12, 5.14, 5.19 à 5.23, 8.11, 8.12, 8.15, 8.16 et 8.24 sont mis en œuvre et surveillés.

Un auditeur ou une autorité de contrôle orienté GDPR testera la responsabilité. Il peut commencer par une mention d’information, une plainte, une demande des personnes concernées ou une divulgation fournisseur, puis remonter la chaîne. Pourquoi ces données ont-elles été collectées ? Quelle base légale s’appliquait ? La finalité était-elle déterminée ? L’utilisation ultérieure était-elle compatible ? Le destinataire était-il autorisé ? Les personnes ont-elles été informées ? Les enregistrements ont-ils été mis à jour avant le début du traitement ?

Un superviseur DORA, le cas échéant, se concentrera sur les fonctions métier soutenues par les TIC, les prestataires TIC tiers, les clauses contractuelles, les droits d’audit, la protection des données, la communication d’incident, les tests de résilience et la planification de sortie. Si des PII clients sont partagées avec un fournisseur critique d’analytique ou de cloud, REG08, les diligences préalables relatives aux fournisseurs et les contrôles contractuels deviennent des éléments probants centraux.

Un évaluateur NIST CSF cadrera le sujet par les résultats de gouvernance. Les exigences légales et réglementaires sont-elles gérées ? Les rôles et responsabilités sont-ils clairs ? Les politiques sont-elles maintenues et appliquées ? Les risques fournisseurs sont-ils gouvernés ? Les résultats de protection des données, de surveillance et de réponse sont-ils opérationnels ?

Un auditeur COBIT ou de type ISACA demandera si les droits de décision sont définis, si les propriétaires métier acceptent le risque relatif à la vie privée, si la performance des contrôles est mesurée, si les exceptions sont suivies et si la direction reçoit des rapports pertinents.

Pièges fréquents constatés par Clarysec dans les mises en œuvre

Le premier piège consiste à traiter l’inventaire des traitements comme un exercice documentaire plutôt que comme un point d’approbation. Si REG02 est mis à jour après la mise en production, il ne peut pas prouver la gouvernance préalable.

Le deuxième est l’emploi de finalités vagues. « Analytique », « amélioration du service » ou « connaissance client » est rarement suffisamment précis pour contrôler l’utilisation interne ou la réutilisation.

Le troisième est l’absence de nécessité au niveau du champ. La minimisation des données ne peut pas être démontrée en affirmant que chaque champ est utile. L’entreprise doit expliquer pourquoi chaque champ est nécessaire à la finalité approuvée.

Le quatrième est la réutilisation non maîtrisée. Des données collectées pour l’administration de comptes deviennent discrètement du renseignement commercial, puis de la segmentation marketing, puis des données d’entraînement IA. Chaque changement de finalité exige une analyse de compatibilité et, dans certains cas, une nouvelle base légale ou une mise à jour de transparence.

Le cinquième est la faiblesse de la gouvernance des divulgations. Les listes de fournisseurs ne sont pas des enregistrements de divulgation. REG08 relie le destinataire, le rôle, la finalité, les catégories de PII, le lieu, la fréquence et la source d’autorisation dans une même piste d’approbation.

Le sixième est l’absence de mise en application technique. Les politiques peuvent indiquer que les PII ne doivent pas quitter les canaux approuvés, mais les courriels, exports, lecteurs partagés et outils analytiques le permettent souvent. C’est là que les mesures ISO/IEC 27002:2022 5.14, 8.12, 8.15, 8.16 et 8.24 deviennent essentielles.

Plan de démarrage pratique sur 30 jours

Les organisations n’ont pas besoin de vouloir tout traiter d’un seul coup. Commencez par une activité de traitement à haut risque, de préférence impliquant du profilage client, de l’analytique IA, des attributs sensibles, un transfert transfrontalier ou une plateforme tierce.

La première semaine, identifiez l’activité de traitement, son propriétaire, les catégories de PII, les systèmes, les fournisseurs et la finalité actuelle. Confirmez si l’activité figure déjà dans REG02 et si la divulgation est représentée dans REG08.

La deuxième semaine, complétez les justifications de nécessité au niveau du champ. Remettez en cause les éléments de données excessifs. Confirmez la classification et l’étiquetage. Identifiez si le masquage, l’agrégation ou la pseudonymisation peuvent réduire le risque.

La troisième semaine, définissez les règles d’utilisation interne et réalisez les éventuels tests de compatibilité de réutilisation. Décidez si les mentions d’information, les appréciations de base légale ou les contrôles relatifs aux personnes concernées doivent être mis à jour.

La quatrième semaine, validez les enregistrements de divulgation externe, l’accès fournisseur, les garanties contractuelles, les termes de l’accord de traitement des données, les contrôles de transfert, la journalisation, la DLP et les obligations de suppression. Échantillonnez ensuite le comportement réel des systèmes au regard des approbations.

Au terme des 30 jours, la direction doit disposer d’un dossier d’éléments probants concret : REG02, REG08, enregistrements de classification, matrices d’accès, éléments probants DLP et de journalisation, diligences préalables fournisseurs, garanties contractuelles, tests de compatibilité et actions de remédiation ouvertes.

De la politique à la preuve

La gouvernance de la collecte, de l’utilisation et de la divulgation des PII est l’endroit où la protection des données devient réelle. Elle fait la différence entre affirmer « nous sommes conformes à GDPR » et prouver que chaque décision de collecte, d’utilisation, de réutilisation et de divulgation a été maîtrisée avant le traitement.

Le kit Clarysec fournit aux équipes protection des données, sécurité et conformité une trajectoire pratique :

• Utiliser la PII09 Politique de collecte, d’utilisation, de divulgation et de partage des PII pour définir les points d’approbation obligatoires.
• Utiliser la P17 Politique de protection des données et de la vie privée ou la Politique de protection des données et de la vie privée - PME pour ancrer un traitement licite, loyal, transparent et minimisé.
• Utiliser la Politique de classification et d’étiquetage des données et la Politique de sécurité des tiers et des fournisseurs - PME pour gouverner la classification, le partage et l’accès fournisseur.
• Suivre Zenith Blueprint : feuille de route d’audit en 30 étapes pour mettre en œuvre l’environnement de contrôle dans le bon ordre.
• Utiliser Zenith Controls : guide de conformité croisée pour comprendre comment les mesures ISO/IEC 27002:2022 telles que 5.34, 5.12, 5.14, 8.11 et 8.12 soutiennent GDPR, NIS2, DORA, NIST et les attentes d’audit.

Si votre prochain audit, votre prochaine demande de diligences préalables client ou votre prochaine revue par le conseil demande comment vous maîtrisez quelles PII sont collectées, comment elles sont utilisées et quand elles sont divulguées, ne vous appuyez pas uniquement sur des déclarations de politique.

Commencez par une activité à haut risque. Construisez l’enregistrement REG02. Justifiez chaque élément de données. Définissez les règles d’utilisation interne. Réalisez le test de compatibilité de réutilisation. Créez l’enregistrement de divulgation REG08. Testez ensuite si l’accès, la DLP, le masquage, la journalisation, le chiffrement et les contrôles fournisseurs correspondent à la décision.

C’est ainsi que la responsabilité ISO/IEC 27701:2025 et GDPR devient un ensemble d’éléments probants.

Explorez le kit PIMS de Clarysec, commencez par la PII09 Politique de collecte, d’utilisation, de divulgation et de partage des PII, et utilisez Zenith Blueprint pour transformer l’intention de politique en gouvernance de la protection des données étayée par des preuves exploitables en audit.