Protection des données à caractère personnel prête pour l'audit pour GDPR, NIS2 et DORA
L’alerte est arrivée dans la boîte de réception de Sarah un mardi à 22 h.
En tant que RSSI d’une FinTech SaaS en forte croissance, Sarah connaissait bien les alertes tardives. Celle-ci était différente. Un développeur junior avait exposé une base de données de préproduction sur un point de terminaison public pendant les tests d’une nouvelle fonctionnalité d’analyse. La base était censée contenir des données de test, mais une synchronisation récente de la production vers la préproduction l’avait alimentée avec de véritables données à caractère personnel de clients.
L’incident a été rapidement contenu. Puis une seconde découverte est arrivée. Une feuille de calcul de migration nommée customer_users_final_v7.xlsx avait été copiée depuis le même jeu de données. Elle contenait des noms, des adresses électroniques, des habilitations de rôle, des journaux d’utilisation, des champs pays, des notes de support et des commentaires en texte libre qui n’auraient jamais dû entrer dans un flux de travail de test. Elle avait été copiée sur un lecteur partagé, téléchargée par un développeur, jointe à un ticket, puis oubliée.
À minuit, Sarah ne gérait plus une simple mauvaise configuration technique. Elle gérait un problème d’audit.
L’entreprise était déjà certifiée ISO/IEC 27001:2022. Le conseil d’administration demandait une assurance GDPR avant un lancement sur le marché de l’UE. Les clients du secteur financier envoyaient des questionnaires de diligence raisonnable DORA. Les relations avec les prestataires cloud et de services managés soulevaient des questions NIS2 sur la chaîne d’approvisionnement. Le service juridique pouvait expliquer les obligations. L’ingénierie pouvait mentionner le chiffrement. Le produit affichait des intentions de protection de la vie privée dès la conception. La Déclaration d’applicabilité mentionnait la vie privée et la protection des données à caractère personnel.
Mais personne ne pouvait montrer, dans une chaîne de traçabilité unique, quelles données à caractère personnel existaient, pourquoi elles étaient traitées, qui pouvait y accéder, où elles étaient masquées, quels fournisseurs y avaient accès, combien de temps elles étaient conservées et comment un incident serait qualifié au regard de GDPR, NIS2 ou DORA.
C’est précisément pour combler cet écart que ISO/IEC 27701:2025 et ISO/IEC 29151:2022 sont importantes. Ce ne sont pas de simples labels de protection de la vie privée. Elles aident les organisations à transformer les engagements de protection de la vie privée en contrôles de protection des données à caractère personnel prêts pour l’audit. ISO/IEC 27701:2025 étend un système de management de la sécurité de l’information ISO/IEC 27001:2022 à la gestion des informations relatives à la vie privée. ISO/IEC 29151:2022 ajoute des lignes directrices pratiques pour protéger les informations personnelles identifiables (PII) tout au long de leur cycle de vie.
L’approche de Clarysec consiste à construire un modèle opérationnel unique de sécurité et de protection de la vie privée fondé sur les éléments probants, et non des silos de conformité distincts. Ce modèle combine Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls et les politiques Clarysec dans un système de traçabilité unique couvrant GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, l’assurance de type NIST et les attentes de gouvernance COBIT 2019.
Pourquoi la protection des données à caractère personnel est désormais un enjeu d’audit au niveau du conseil d’administration
La protection des données à caractère personnel était auparavant considérée comme une responsabilité de l’équipe chargée de la vie privée. Aujourd’hui, c’est un enjeu de confiance, de résilience et de conformité réglementaire au niveau du conseil d’administration.
GDPR reste le référentiel de base pour la protection des données à caractère personnel en Europe et au-delà. Il définit les données à caractère personnel, le traitement, le responsable du traitement, le sous-traitant, le destinataire, le tiers, le consentement et la violation de données à caractère personnel d’une manière qui affecte les contrats SaaS, les opérations de support, l’analytique, la télémétrie produit, la gestion des fournisseurs et la réponse aux incidents. Ses principes imposent la licéité, la loyauté, la transparence, 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é. En audit, GDPR ne demande pas seulement si les données sont chiffrées. Il demande si l’organisation peut démontrer pourquoi les données existent et comment la conformité est assurée.
NIS2 relève le niveau d’exigence en matière de gouvernance de la cybersécurité pour les entités essentielles et importantes. Article 21 exige des mesures de gestion des risques de cybersécurité, notamment 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é, le traitement des vulnérabilités, l’évaluation de l’efficacité des contrôles, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs, l’authentification et les communications sécurisées. Article 23 ajoute une notification des incidents par étapes, notamment une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans le mois suivant la notification.
DORA change la donne pour les entités financières et leurs prestataires de services TIC. Il s’applique depuis le 17 janvier 2025 et crée un régime harmonisé de résilience opérationnelle numérique couvrant la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience, le risque lié aux prestataires tiers de services TIC, les exigences contractuelles et la supervision des prestataires tiers critiques de services TIC. Pour de nombreuses entités financières, DORA constitue l’acte juridique sectoriel de l’Union lorsque des obligations équivalentes à NIS2 se recoupent. Pour les fournisseurs SaaS et de services TIC au service d’établissements financiers, la pression DORA arrive souvent par les clauses contractuelles, les audits clients, les exigences de planification de sortie, les obligations d’assistance en cas d’incident et les tests de résilience.
ISO/IEC 27001:2022 fournit l’ossature du système de management. Elle exige le contexte, les parties intéressées, le domaine d’application, la responsabilité de la direction, les politiques, les rôles, l’appréciation des risques, le traitement des risques, la Déclaration d’applicabilité, l’audit interne, la revue de direction et l’amélioration continue. L’annexe A comprend des contrôles directement pertinents pour la protection des données à caractère personnel, notamment 5.34 Protection de la vie privée et des données à caractère personnel, 5.18 droits d’accès, 8.11 masquage des données, 5.23 Sécurité de l’information pour l’utilisation des services cloud, 8.15 journalisation, 8.33 Informations de test, 8.24 Utilisation de la cryptographie et 8.10 Suppression de l’information.
Le problème n’est pas que les organisations n’ont aucun contrôle. Le problème est que les contrôles sont fragmentés. Les registres de protection de la vie privée sont détenus par le service juridique. Les revues d’accès sont gérées par l’IT. Les scripts de masquage sont détenus par l’ingénierie. Les contrats fournisseurs sont gérés par les achats. Les éléments probants sont dispersés dans des tickets, des captures d’écran, des feuilles de calcul et des courriels.
ISO/IEC 27701:2025 et ISO/IEC 29151:2022 aident à unifier ces éléments probants autour de la gestion des informations relatives à la vie privée et des pratiques de protection des données à caractère personnel. Clarysec transforme cette structure en modèle opérationnel.
Du SMSI au PIMS : la chaîne intégrée de contrôle de la vie privée
Un SMSI ISO/IEC 27001:2022 répond à une question essentielle : la sécurité de l’information est-elle gouvernée, fondée sur les risques, mise en œuvre, surveillée et améliorée ?
Un système de management des informations relatives à la vie privée, ou PIMS, étend cette question aux données à caractère personnel : les responsabilités liées à la vie privée, les activités de traitement des données à caractère personnel, les risques relatifs à la vie privée, les obligations de responsable du traitement et de sous-traitant, les droits des personnes concernées et les éléments probants relatifs aux contrôles de vie privée sont-ils gérés dans le même système ?
ISO/IEC 27701:2025 étend le SMSI à la gouvernance de la protection des données. ISO/IEC 29151:2022 la complète par des lignes directrices pratiques de protection des données à caractère personnel, notamment la limitation de la collecte, la gestion de la divulgation, l’application du masquage ou de la pseudonymisation, la protection des transferts, la restriction des accès et l’alignement des contrôles sur le risque relatif à la vie privée.
| Couche | Question principale | Éléments probants d’audit typiques |
|---|---|---|
| ISO/IEC 27001:2022 | Existe-t-il un SMSI gouverné, fondé sur les risques, avec des contrôles sélectionnés et opérationnels ? | Domaine d’application, parties intéressées, appréciation des risques, plan de traitement des risques, SoA, politiques, audit interne, revue de direction |
| ISO/IEC 27701:2025 | Les responsabilités liées à la vie privée, les risques relatifs à la vie privée et les activités de traitement des données à caractère personnel sont-ils gouvernés dans le système de management ? | Rôles liés à la vie privée, registre des traitements, procédures de responsable du traitement et de sous-traitant, évaluations des risques relatifs à la vie privée, DPIA, processus de traitement des demandes des personnes concernées |
| ISO/IEC 29151:2022 | Des mesures pratiques de protection des données à caractère personnel sont-elles mises en œuvre tout au long du cycle de vie des données ? | Classification des données à caractère personnel, restrictions d’accès, masquage, pseudonymisation, contrôles de conservation, mesures de protection des transferts, éléments probants relatifs aux incidents |
| GDPR | L’organisation peut-elle démontrer un traitement licite, loyal, transparent, minimisé, sécurisé et responsable ? | Registres des bases légales, avis de confidentialité, DPIA, processus de gestion des violations, accords avec les sous-traitants, traitement des droits |
| NIS2 et DORA | L’organisation peut-elle gouverner les risques de cybersécurité et de résilience, y compris les incidents et les fournisseurs ? | Supervision par la direction, cadre de gestion des risques liés aux TIC, classification des incidents, playbooks de notification, registres fournisseurs, droits d’audit, tests de continuité |
Ce modèle par couches évite l’erreur la plus fréquente en conformité vie privée : traiter les données à caractère personnel comme un simple type de données sensibles. Les données à caractère personnel emportent des obligations juridiques, éthiques, opérationnelles, contractuelles et réputationnelles. Elles exigent une chaîne de contrôle qui commence par la sensibilisation aux données et se termine par les éléments probants.
Commencer par la connaissance des données, pas par des schémas de chiffrement
La défaillance la plus fréquente que Clarysec observe en matière de vie privée est l’absence de contexte. Une entreprise ne peut pas protéger les données à caractère personnel si elle ne sait pas quelles données elle détient, où elles se trouvent, à quelle finalité elles répondent, combien de temps elles sont conservées ou qui peut y accéder.
Le Zenith Blueprint lance ce travail tôt dans la phase de gestion des risques. À l’étape 9, Identification des actifs, des menaces et des vulnérabilités, il demande aux organisations d’inventorier les actifs informationnels et de signaler explicitement les données à caractère personnel :
« Pour chaque actif, consignez les informations clés : nom/description, propriétaire, emplacement et classification (sensibilité). Par exemple, un actif pourrait être : “Base de données clients – détenue par le département IT – hébergée sur AWS – contient des données à caractère personnel et financières (sensibilité élevée)”. »
Il ajoute également : « Veillez à signaler les actifs contenant des données à caractère personnel (pour la pertinence GDPR) et à noter les actifs de services critiques (pour une applicabilité potentielle de NIS2 si vous opérez dans un secteur réglementé). »
C’est le fondement de l’adoption de ISO/IEC 27701:2025 et ISO/IEC 29151:2022. La séquence pratique est simple :
- Identifier les systèmes, jeux de données, référentiels, journaux, rapports, sauvegardes, outils de support, environnements de développement et fournisseurs qui traitent des données à caractère personnel.
- Désigner un propriétaire pour chaque actif contenant des données à caractère personnel.
- Classifier les données à caractère personnel selon la sensibilité, la finalité métier, la base légale, le rôle de traitement et l’exigence de conservation.
- Relier chaque actif contenant des données à caractère personnel aux menaces, vulnérabilités, scénarios de risque et obligations réglementaires.
- Sélectionner les contrôles, attribuer les éléments probants et surveiller leur fonctionnement dans le temps.
Les politiques Clarysec rendent ce dispositif opérationnel. La Politique de protection des données et de la vie privée pour PME Politique de protection des données et de la vie privée - PME indique :
« Le coordinateur de la protection des données doit tenir à jour un registre de toutes les activités de traitement de données à caractère personnel, y compris les catégories de données, la finalité, la base légale et les durées de conservation. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.1.
Pour les grandes organisations, la Politique de protection des données et de la vie privée Politique de protection des données et de la vie privée établit une règle stricte de minimisation :
« Seules les données nécessaires à une finalité métier spécifique et légitime peuvent être collectées et traitées. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.
Ces clauses transforment la responsabilité GDPR en opérations quotidiennes. Elles soutiennent également la gestion des informations relatives à la vie privée et la protection des données à caractère personnel, car elles obligent l’organisation à définir quelles données existent, pourquoi elles existent et si elles sont nécessaires.
Les trois contrôles qui rendent la protection des données à caractère personnel effective
Trois contrôles de l’annexe A de ISO/IEC 27001:2022 déterminent souvent si la protection des données à caractère personnel est défendable en audit : 5.34 Protection de la vie privée et des données à caractère personnel, 8.11 masquage des données et 5.18 droits d’accès.
5.34 Protection de la vie privée et des données à caractère personnel
La mesure 5.34 est le pivot de gouvernance. Dans Zenith Controls, 5.34 est traitée comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec les concepts de cybersécurité Identify et Protect et des capacités opérationnelles de protection de l’information et de conformité juridique.
Zenith Controls explicite la dépendance :
« Un inventaire des actifs informationnels (5.9) doit inclure les gisements de données à caractère personnel (bases de données clients, dossiers RH). Il soutient 5.34 en garantissant que l’organisation sait quelles données à caractère personnel elle détient et où elles se trouvent, ce qui constitue la première étape de leur protection. »
La mesure 5.34 dépend de 5.9 Inventaire des informations et autres actifs associés, car les données à caractère personnel ne peuvent pas être protégées si elles ne peuvent pas être localisées. Elle se rattache également à 5.23 Sécurité de l’information pour l’utilisation des services cloud, car la plupart des données à caractère personnel résident aujourd’hui dans des plateformes cloud, des outils SaaS, des environnements d’analyse et des services managés.
Pour les traitements à haut risque, la Politique de protection des données et de la vie privée d’entreprise exige :
« La modélisation des menaces et les analyses d’impact relatives à la protection des données (DPIA) sont obligatoires pour les systèmes de traitement à haut risque. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.4.
Cette clause est déterminante. Elle fait de la vie privée une activité de conception et de gestion des risques, et non une revue juridique de dernière minute.
8.11 masquage des données
La mesure 8.11 est la réponse directe à l’exposition de la base de données de préproduction de Sarah. Zenith Controls décrit 8.11 comme un contrôle préventif de confidentialité relevant de la protection de l’information. Elle relie 8.11 à 5.12 Classification de l’information parce que les décisions de masquage dépendent de la sensibilité, à 5.34 parce que le masquage soutient la protection de la vie privée, et à 8.33 Informations de test parce que les environnements de test ne doivent pas exposer de véritables données à caractère personnel.
La Politique de masquage des données et de pseudonymisation Politique de masquage des données et de pseudonymisation rend la règle explicite :
« Les données à caractère personnel réelles ne doivent pas être utilisées dans les environnements de développement, de test ou de préproduction. Des données masquées ou pseudonymisées doivent être utilisées à la place et doivent être générées à partir de modèles de transformation préapprouvés. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.
Pour les PME, la Politique de masquage des données et de pseudonymisation pour PME Politique de masquage des données et de pseudonymisation - PME ajoute une exigence clé de sécurité et de preuve :
« L’accès aux clés doit être chiffré, soumis à contrôle d’accès et journalisé. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.3.
Ce point est important, car la pseudonymisation ne réduit le risque que si la logique de transformation, les clés et les chemins de réidentification sont maîtrisés.
5.18 droits d’accès
La mesure 5.18 est le cœur opérationnel du moindre privilège. Zenith Controls la traite comme un contrôle préventif, lié à la confidentialité, l’intégrité et la disponibilité, et positionné dans la gestion des identités et des accès. Elle rattache 5.18 à 5.15 contrôle d’accès, 5.16 gestion des identités et 8.2 droits d’accès privilégiés.
La Politique de classification et d’étiquetage des données pour PME Politique de classification et d’étiquetage des données - PME indique :
« L’accès doit être limité aux utilisateurs spécifiquement autorisés ayant un besoin d’en connaître. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.1.
La Politique de classification et d’étiquetage des données d’entreprise Politique de classification et d’étiquetage des données ajoute la référence de classification :
« Tous les actifs informationnels doivent se voir attribuer une classification clairement définie au moment de leur création ou de leur intégration. En l’absence de classification explicite, les actifs doivent être classés par défaut comme “Confidentiel” jusqu’à revue formelle. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.4.
Ensemble, ces contrôles forment la chaîne pratique de protection des données à caractère personnel : connaître les données à caractère personnel, les classifier, limiter l’accès, les masquer lorsque l’identité complète n’est pas nécessaire, protéger les clés, journaliser les accès et conserver les éléments probants.
Construire la traçabilité au moyen de la Déclaration d’applicabilité
Un système de management de la vie privée devient prêt pour l’audit lorsqu’il peut démontrer sa traçabilité. Le Zenith Blueprint, dans la phase de gestion des risques, étape 13, Planification du traitement des risques et Déclaration d’applicabilité, décrit la Déclaration d’applicabilité comme un document de liaison :
« La SoA est, en pratique, un document de liaison : elle relie votre appréciation/traitement des risques aux contrôles effectivement en place. En la complétant, vous vérifiez également si certains contrôles ont été omis. »
Ce concept est central pour se préparer à ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 et DORA. Chaque contrôle relatif aux données à caractère personnel doit être traçable de l’exigence au risque, du risque au contrôle, du contrôle au propriétaire, du propriétaire aux éléments probants, puis des éléments probants à la revue.
| Élément de traçabilité | Exemple pour les données à caractère personnel du support client | Éléments probants attendus |
|---|---|---|
| Actif contenant des données à caractère personnel | Plateforme de tickets de support avec noms de clients, adresses électroniques, journaux et pièces jointes | Entrée du registre des actifs, propriétaire, emplacement cloud, classification |
| Finalité du traitement | Support client et diagnostic de service | Registre des traitements, base légale, durée de conservation |
| Scénario de risque | Un agent support ou un développeur accède à un volume excessif de données client | Entrée du registre des risques, vraisemblance, impact, propriétaire |
| Sélection des contrôles | 5.34 protection des données à caractère personnel, 5.18 droits d’accès, 8.11 masquage, 8.15 journalisation, 5.23 gouvernance cloud | SoA, politique d’accès, norme de masquage, configuration de journalisation |
| Éléments probants opérationnels | Contrôle d’accès fondé sur les rôles, exports masqués, revue d’accès trimestrielle, alertes sur téléchargements en masse | Enregistrements de revue d’accès, alertes DLP, journaux, éléments probants de ticket |
| Cartographie réglementaire | Responsabilité et sécurité GDPR, gestion des risques NIS2, risque TIC et exigences fournisseurs DORA | Matrice de conformité, playbook d’incident, registre des contrats fournisseurs |
| Éléments probants de revue | Constat d’audit interne clôturé, action de revue de direction acceptée | Rapport d’audit, action corrective, comptes rendus de revue de direction |
ISO/IEC 27005:2022 soutient cette approche fondée sur les risques en mettant l’accent sur les exigences des parties intéressées, des critères de risque communs, des propriétaires de risques responsables, une appréciation des risques répétable, le traitement des risques, la sélection des contrôles, l’alignement avec la Déclaration d’applicabilité, l’approbation du risque résiduel, la surveillance et l’amélioration continue. La protection des données à caractère personnel doit être un cycle de risque vivant, et non un exercice documentaire GDPR ponctuel.
Corriger la feuille de calcul risquée et la base de données de préproduction
L’incident de Sarah peut être transformé en pack de contrôle reproductible si la remédiation est traitée de manière systématique.
| Étape | Action | Résultat en matière d’éléments probants Clarysec |
|---|---|---|
| 1 | Enregistrer la base de données de préproduction et la feuille de calcul comme actifs contenant des données à caractère personnel | Entrées de l’inventaire des actifs avec propriétaire, emplacement, classification, catégories de données à caractère personnel, finalité et conservation |
| 2 | Mettre à jour l’activité de traitement | Entrée de registre indiquant les catégories de données, la base légale, la finalité et la durée de conservation |
| 3 | Classifier les fichiers et les jeux de données | Classification Confidentiel ou supérieure appliquée par défaut jusqu’à revue formelle |
| 4 | Retirer les données à caractère personnel réelles des environnements hors production | Jeu de données masqué ou pseudonymisé généré à partir de modèles de transformation approuvés |
| 5 | Restreindre et revoir les accès | Habilitations fondées sur le besoin d’en connaître, accès excessifs révoqués, enregistrement de revue d’accès |
| 6 | Protéger la logique de transformation et les clés | Accès aux clés chiffré, soumis à contrôle d’accès et journalisé |
| 7 | Centraliser la collecte des éléments probants | Enregistrement d’actif, entrée de risque, revue d’accès, preuve de suppression, approbation du masquage et clôture du ticket |
| 8 | Mettre à jour la SoA et le plan de traitement des risques | Scénario de risque lié à 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 et aux contrôles fournisseurs |
| 9 | Déterminer si une DPIA est requise | DPIA ou justification documentée des décisions relatives aux traitements à haut risque |
| 10 | Consigner les enseignements tirés | Formation mise à jour, règles de développement sécurisé, contrôles d’export, surveillance DLP et lignes directrices sur les données de test |
La Politique d’audit et de surveillance de la conformité pour PME Politique d’audit et de surveillance de la conformité - PME indique :
« Tous les éléments probants doivent être stockés dans un dossier d’audit centralisé. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.
La Politique de sécurité de l’information Politique de sécurité de l’information explicite l’attente d’audit plus large :
« Tous les contrôles mis en œuvre doivent être vérifiables en audit, étayés par des procédures documentées et par des éléments probants conservés attestant de leur fonctionnement. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.6.1.
Ces deux clauses font la différence entre disposer d’un contrôle et être en mesure de le prouver.
Cartographie de conformité croisée pour un jeu unique de contrôles des données à caractère personnel
La protection des données à caractère personnel devient plus facile à défendre lorsqu’elle est cartographiée entre référentiels avant que l’auditeur ne le demande.
| Thème de protection des données à caractère personnel | Pertinence GDPR | Pertinence ISO/IEC 27001:2022, ISO/IEC 27701:2025 et ISO/IEC 29151:2022 | Pertinence NIS2 | Pertinence DORA | Angle d’audit NIST et COBIT 2019 |
|---|---|---|---|---|---|
| Inventaire des données à caractère personnel et registre des traitements | Responsabilité, base légale, limitation des finalités, limitation de la conservation | Contexte du SMSI, inventaire des actifs 5.9, gestion des informations relatives à la vie privée, protection des données à caractère personnel | Gestion des actifs et analyse des risques | Connaissance des actifs TIC et des dépendances de services | Éléments probants de la fonction Identify et gouvernance des actifs informationnels |
| Droits d’accès et moindre privilège | Intégrité et confidentialité, accès limité selon le rôle | 5.15 contrôle d’accès, 5.16 gestion des identités, 5.18 droits d’accès, 8.2 droits d’accès privilégiés | Contrôle d’accès, sécurité RH, authentification | Contrôles du risque TIC et supervision des accès à privilèges | Application des accès, propriété, responsabilité et surveillance |
| Masquage et pseudonymisation | Minimisation des données, protection des données dès la conception, sécurité du traitement | 5.12 classification, 5.34 protection des données à caractère personnel, 8.11 masquage des données, 8.33 informations de test | Hygiène cyber et développement sécurisé | Tests sécurisés, réduction des pertes de données, résilience opérationnelle | Tests des mesures de protection techniques et fonctionnement fiable des contrôles |
| Classification et notification des incidents | Évaluation et notification des violations de données à caractère personnel | Planification des incidents, évaluation des événements, réponse, collecte des éléments probants | Alerte précoce sous 24 heures, notification sous 72 heures, rapport final | Classification et notification des incidents majeurs liés aux TIC | Critères d’escalade, journaux de décision, cause racine, remédiation |
| Traitements par les fournisseurs et dans le cloud | Obligations des sous-traitants, transferts, contrats | 5.21 chaîne d’approvisionnement TIC, 5.23 services cloud, 5.31 exigences légales et contractuelles | Sécurité de la chaîne d’approvisionnement | Risque lié aux prestataires tiers de services TIC, droits d’audit, sortie et transition | Gouvernance des tiers, assurance et responsabilité de la direction |
C’est là que Zenith Controls est particulièrement utile. Pour 5.34, il cartographie la protection des données à caractère personnel avec l’inventaire des actifs, le masquage des données et la gouvernance cloud. Pour 8.11, il cartographie le masquage avec la classification, la protection de la vie privée et les informations de test. Pour 5.18, il cartographie les droits d’accès avec le contrôle d’accès, la gestion des identités et l’accès à privilèges. Ces relations permettent à une équipe d’expliquer non seulement qu’un contrôle existe, mais pourquoi il existe et quels contrôles adjacents doivent fonctionner avec lui.
Comment différents auditeurs testent le même contrôle relatif aux données à caractère personnel
Un même contrôle, comme 8.11 masquage des données, sera examiné différemment selon l’angle d’audit.
| Type d’auditeur | Point d’attention principal | Éléments probants attendus |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 et ISO/IEC 27701:2025 | Intégration SMSI et PIMS, traitement des risques, exactitude de la SoA | Appréciation des risques, entrée SoA, politique de masquage, enregistrements de changement, résultats d’audit interne |
| Réviseur GDPR ou autorité de contrôle | Protection des données dès la conception, minimisation, responsabilité | Registre des traitements, base légale, DPIA, éléments probants de pseudonymisation, logique de conservation |
| Évaluateur NIS2 | Développement sécurisé, prévention des incidents, gouvernance | Procédure de développement sécurisé, formation des développeurs, éléments probants de remédiation d’incident, revue de l’efficacité des contrôles |
| Client ou auditeur DORA | Résilience opérationnelle numérique et risque lié aux tiers | Éléments probants des tests d’applications critiques, clauses contractuelles fournisseurs, obligations d’assistance en cas d’incident, planification de la reprise et de la sortie |
| Réviseur de type NIST ou COBIT 2019 | Conception, fonctionnement, propriété et surveillance des contrôles | Responsable de contrôle, indicateurs, référentiel d’éléments probants, reporting de direction, actions correctives |
Un auditeur ISO/IEC 27001:2022 commence par la logique du système de management. Les données à caractère personnel sont-elles incluses dans le domaine d’application ? Les exigences des parties intéressées sont-elles identifiées ? Les risques relatifs à la vie privée sont-ils appréciés selon des critères définis ? Les contrôles sont-ils sélectionnés par le traitement des risques ? La SoA est-elle exacte ? Les audits internes et les revues de direction couvrent-ils les contrôles relatifs aux données à caractère personnel ?
Un réviseur vie privée commence par la responsabilité. Quelles données à caractère personnel sont traitées ? Quelle est la base légale ? Les personnes concernées sont-elles informées ? Le traitement est-il limité à une finalité spécifique ? Les activités à haut risque sont-elles évaluées ? Les sous-traitants sont-ils gouvernés ?
Un évaluateur axé sur NIS2 commence par la gouvernance et la gestion des risques de cybersécurité. La direction approuve-t-elle et supervise-t-elle les mesures ? La gestion des incidents, la continuité, la sécurité des fournisseurs, le contrôle d’accès, la gestion des actifs, le développement sécurisé et l’évaluation de l’efficacité des contrôles sont-ils intégrés ?
Un client ou auditeur DORA demande si la gestion des risques TIC est documentée, gouvernée par le conseil d’administration, proportionnée et soutenue par des contrats. Si des données à caractère personnel sont traitées dans des services utilisés par des entités financières, il faut s’attendre à des questions sur l’assistance en cas d’incident, les emplacements de traitement des données, la reprise, les droits d’audit, les niveaux de service, la résiliation et la sortie.
Un réviseur COBIT 2019 ou de type ISACA teste l’alignement de la gouvernance. Qui est propriétaire du risque lié aux données à caractère personnel ? Quelle instance de gouvernance reçoit le reporting ? Les responsabilités sont-elles attribuées ? Les fournisseurs sont-ils surveillés ? Les écarts sont-ils suivis ? Les indicateurs servent-ils à la prise de décision ? Le risque résiduel est-il formellement accepté ?
Un seul modèle d’éléments probants peut satisfaire tous ces angles, mais uniquement si le système de contrôle est conçu pour la traçabilité dès le départ.
Constats d’audit fréquents dans les programmes de protection des données à caractère personnel
Les organisations qui abordent la préparation à ISO/IEC 27701:2025 ou à ISO/IEC 29151:2022 sans boîte à outils intégrée rencontrent souvent les mêmes constats.
| Constat | Pourquoi c’est important | Remédiation Clarysec |
|---|---|---|
| L’inventaire des données à caractère personnel exclut les journaux, sauvegardes, exports d’analyse ou pièces jointes de support | Les données à caractère personnel cachées ne peuvent pas être protégées ni supprimées de manière fiable | Étendre l’inventaire des actifs de l’étape 9 et le registre des traitements pour inclure tous les emplacements contenant des données à caractère personnel |
| Les environnements de test utilisent des données de production | De véritables données à caractère personnel sont exposées là où elles ne sont pas nécessaires | Appliquer la politique de masquage et les modèles de transformation approuvés |
| Les revues d’accès sont génériques et ne se concentrent pas sur les référentiels contenant des données à caractère personnel | Les accès excessifs restent indétectés | Cartographier les droits d’accès 5.18 avec les propriétaires d’actifs contenant des données à caractère personnel et les éléments probants de revue périodique |
| La base légale est documentée, mais non liée aux systèmes ni à la conservation | La responsabilité GDPR ne peut pas être démontrée | Ajouter les champs base légale et conservation au registre des traitements et à l’inventaire des actifs |
| Les contrats fournisseurs ne couvrent pas l’emplacement des données, l’assistance en cas d’incident, les droits d’audit ou les dispositions de sortie | Des lacunes d’assurance fournisseurs subsistent pour DORA, NIS2 et GDPR | Aligner la diligence raisonnable des fournisseurs et les contrats sur la gouvernance des prestataires tiers de services TIC et du cloud |
| Les playbooks d’incident ne distinguent pas les incidents de sécurité des violations de données à caractère personnel | Les délais de notification peuvent être manqués | Construire des arbres de classification pour les déclencheurs de notification GDPR, NIS2 et DORA |
| Les éléments probants sont dispersés entre tickets, lecteurs, captures d’écran et courriels | La préparation à l’audit échoue même lorsque les contrôles fonctionnent | Utiliser des dossiers d’audit centralisés et des normes de nommage des éléments probants |
Ces constats ne sont pas des problèmes documentaires. Ce sont des problèmes de modèle opérationnel. ISO/IEC 27701:2025 et ISO/IEC 29151:2022 ne les corrigeront pas si la gouvernance de la protection des données, les contrôles de sécurité et la gestion des éléments probants ne sont pas intégrés aux flux de travail habituels.
Les questions que la direction doit poser avant le prochain audit
Avant d’engager une préparation à ISO/IEC 27701:2025, une mise en œuvre de ISO/IEC 29151:2022 ou une évaluation client GDPR, NIS2 ou DORA, la direction doit poser dix questions directes :
- Disposons-nous d’un registre complet des activités de traitement des données à caractère personnel, incluant les catégories de données, la finalité, la base légale et la conservation ?
- Les actifs contenant des données à caractère personnel sont-ils signalés dans l’inventaire des actifs, y compris les journaux, sauvegardes, exports, outils d’analyse et pièces jointes de support ?
- Les classifications de données sont-elles attribuées à la création ou à l’intégration, avec une classification par défaut Confidentiel pour les actifs non revus ?
- Pouvons-nous prouver que l’accès aux données à caractère personnel est limité aux utilisateurs autorisés ayant un besoin d’en connaître ?
- Les environnements de développement, de test et de préproduction utilisent-ils des données masquées ou pseudonymisées au lieu de données à caractère personnel réelles ?
- Les modèles de masquage sont-ils approuvés, les clés protégées, soumises à contrôle d’accès et journalisées ?
- La SoA relie-t-elle les risques relatifs aux données à caractère personnel aux contrôles et aux obligations réglementaires ?
- Les contrats cloud et fournisseurs sont-ils revus au regard de l’emplacement des données, de la sécurité, du support en cas d’incident, des droits d’audit, de la reprise et de la sortie ?
- Notre processus de gestion des incidents peut-il classifier les violations de données à caractère personnel GDPR, les incidents significatifs NIS2 et les incidents majeurs liés aux TIC au sens de DORA ?
- Les éléments probants sont-ils stockés de manière centralisée et conservés de façon à permettre à un auditeur d’en suivre la chaîne ?
Si la réponse à l’une de ces questions n’est pas claire, l’organisation n’est pas encore prête pour l’audit.
Rendre la protection des données à caractère personnel démontrable
L’incident nocturne de Sarah aurait pu se transformer en course désordonnée à la conformité. Il peut au contraire devenir le point de départ d’un modèle opérationnel plus robuste : un SMSI ISO/IEC 27001:2022 étendu à la vie privée avec ISO/IEC 27701:2025, renforcé par les pratiques ISO/IEC 29151:2022, et cartographié avec GDPR, NIS2, DORA, l’assurance de type NIST et les attentes de gouvernance COBIT 2019.
C’est la véritable valeur d’une protection des données à caractère personnel prête pour l’audit. Elle ne dépend pas de la capacité à retrouver la bonne feuille de calcul avant l’arrivée de l’auditeur. Elle dépend d’un système qui sait déjà où se trouvent les données à caractère personnel, pourquoi elles existent, comment elles sont protégées, qui est responsable, quels fournisseurs sont impliqués et où résident les éléments probants.
Commencez par Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour structurer votre mise en œuvre. Utilisez Zenith Controls: The Cross-Compliance Guide Zenith Controls pour cartographier la protection des données à caractère personnel avec ISO/IEC 27001:2022, GDPR, NIS2, DORA, l’assurance de type NIST et les attentes de gouvernance COBIT 2019. Opérationnalisez le dispositif avec les politiques Clarysec, notamment la Politique de protection des données et de la vie privée Politique de protection des données et de la vie privée, la Politique de masquage des données et de pseudonymisation Politique de masquage des données et de pseudonymisation, la Politique de classification et d’étiquetage des données Politique de classification et d’étiquetage des données, la Politique d’audit et de surveillance de la conformité pour PME Politique d’audit et de surveillance de la conformité - PME et la Politique de sécurité de l’information Politique de sécurité de l’information.
Si votre prochain audit client, votre revue GDPR, votre projet de préparation NIS2 ou votre évaluation fournisseur DORA approche, n’attendez pas qu’une violation révèle les lacunes. Téléchargez les kits Clarysec, demandez une démonstration ou planifiez une évaluation de la protection des données à caractère personnel, et construisez un programme de protection de la vie privée qui n’est pas seulement conforme, mais défendable.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
