Gouvernance des accès aux données à caractère personnel pour ISO 27701:2025 et GDPR

La question de l’auditeur externe resta en suspens, d’une simplicité trompeuse.

« Pouvez-vous me présenter le journal de revue des accès relatif aux accès de votre équipe support aux données à caractère personnel en production sur le dernier trimestre ? »

Pour Anya, RSSI de Medtelligence, fournisseur SaaS de technologies de santé en forte croissance, c’était le moment de vérité. Medtelligence agit comme sous-traitant de données à caractère personnel pour des hôpitaux et traite des données sensibles de patients sur une plateforme cloud. L’entreprise disposait d’une authentification forte, de rôles définis et d’une équipe d’ingénierie mature. Mais l’auditeur ne demandait pas si une page de connexion existait. Il demandait la preuve que les accès aux données à caractère personnel étaient gouvernés dans la durée.

Il voulait voir qui pouvait accéder aux données à caractère personnel en production, pourquoi ces accès existaient, quand ils avaient été approuvés, s’ils étaient encore nécessaires, si l’activité de support était journalisée et si les droits inutiles avaient été supprimés.

Anya ouvrit la console IAM. Elle y trouva des ingénieurs support, des administrateurs de bases de données, un compte de service d’intégration, un prestataire de services managés, deux rôles d’accès d’urgence, ainsi qu’un ancien contractant encore présent dans un groupe, car le ticket de départ avait été clôturé avant la suppression de l’habilitation. Les ressources humaines indiquaient que la personne avait quitté l’entreprise six semaines plus tôt. Le tableur de revue des accès affichait « en attente ». Le SIEM contenait des journaux, mais personne n’avait cartographié les événements permettant de prouver l’accès aux données à caractère personnel.

C’est à ce moment que la gouvernance de la protection des données devient concrète.

Au titre du GDPR, les données à caractère personnel doivent être traitées de manière à garantir leur intégrité et leur confidentialité, et être protégées contre le traitement non autorisé ou illicite, la perte, la destruction ou les dommages accidentels, au moyen de mesures techniques et organisationnelles appropriées. Le GDPR rend également explicite la responsabilité : le responsable du traitement doit être en mesure de démontrer la conformité. ISO/IEC 27701:2025 transforme cette responsabilité en système de management des informations relatives à la vie privée, ou PIMS, dans lequel l’accès aux données à caractère personnel n’est plus un détail technique traité après coup. Il devient un cycle de vie gouverné couvrant les rôles, les sous-traitants, les plateformes cloud, les employés, les administrateurs à privilèges, les journaux, les revues, les contrats et les éléments probants.

Pour de nombreuses organisations, la lacune ne tient pas à l’absence de contrôle d’accès. Elle tient à l’incapacité de prouver de manière cohérente la gouvernance des accès aux données à caractère personnel dans ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 et COBIT 2019.

La gouvernance des accès aux données à caractère personnel ne se limite pas à l’IAM

Un programme IAM traditionnel demande : « Les bons utilisateurs peuvent-ils accéder aux bons systèmes ? »

Un PIMS ISO/IEC 27701:2025 mature pose des questions plus exigeantes :

• Quels systèmes traitent des données à caractère personnel ?
• Quels rôles nécessitent un accès à quelles catégories de données à caractère personnel ?
• L’organisation agit-elle en tant que responsable du traitement, sous-traitant, responsable conjoint du traitement ou sous-traitant ultérieur de données à caractère personnel ?
• L’accès est-il limité par la finalité, le besoin métier documenté et le moindre privilège ?
• Les actions à privilèges sont-elles journalisées et revues ?
• L’organisation peut-elle prouver que les accès des sous-traitants et des sous-traitants ultérieurs sont encadrés contractuellement ?
• Les circuits de support cloud, l’isolement des locataires, les exports et les actions d’administration sont-ils inclus dans les éléments probants ?
• Les décisions d’accès sont-elles revues après l’intégration, un changement de rôle, un incident, un départ et une modification substantielle du système ?

C’est pourquoi la gouvernance de la sécurité et du contrôle d’accès aux données à caractère personnel constitue un pont naturel entre ISO/IEC 27701:2025 et GDPR. Le GDPR fournit le cadre juridique de responsabilité. ISO/IEC 27701:2025 opérationnalise la gestion de la protection des données pour les responsables du traitement et les sous-traitants. ISO/IEC 27001:2022 fournit le moteur de gestion des risques du SMSI. ISO/IEC 27002:2022 fournit l’architecture des mesures de sécurité, notamment la vie privée et la protection des données à caractère personnel, le contrôle d’accès, les droits d’accès, la journalisation, les services cloud, les relations avec les fournisseurs, la classification, la suppression, le masquage et la cryptographie.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec place ce sujet dans la phase « Contrôles en action ». À l’étape 23, qui couvre les mesures organisationnelles 5.19 à 5.37, il décrit la mesure ISO/IEC 27002:2022 5.34, Vie privée et protection des données à caractère personnel, comme un enjeu de confiance, et non comme un simple enjeu de données :

Les informations personnellement identifiables ne sont pas un simple type de données supplémentaire ; elles constituent une représentation hautement sensible de la confiance. Noms, adresses, identifiants, dossiers médicaux, informations financières : ces données racontent l’histoire de personnes réelles.

Le même passage donne le fondement pratique : la protection de la vie privée commence par la connaissance des données. Une organisation doit savoir quelles données à caractère personnel elle collecte, où elles résident, pourquoi elles sont traitées et qui peut y accéder.

La pression de conformité derrière le contrôle d’accès aux données à caractère personnel

La gouvernance des accès aux données à caractère personnel n’est plus un sujet relevant d’un seul référentiel. Des organisations comme Medtelligence opèrent à l’intersection de la réglementation relative à la protection des données, du droit de la cybersécurité, de la résilience opérationnelle, de l’assurance demandée par les clients et de la certification de sécurité.

L’Article 5 du GDPR exige que les données à caractère personnel soient traitées selon les principes de licéité, loyauté, transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, intégrité et confidentialité. L’Article 5(2) introduit la responsabilité : le responsable du traitement est responsable du respect de ces principes et doit être en mesure de démontrer la conformité. L’Article 32 exige ensuite des mesures techniques et organisationnelles appropriées pour la sécurité du traitement.

L’Article 21 de NIS2 impose aux entités essentielles et importantes de prendre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées de gestion des risques de cybersécurité. Ses domaines minimaux incluent l’analyse des risques, les politiques de sécurité, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, l’évaluation de l’efficacité, l’hygiène cyber et la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et, le cas échéant, l’authentification multifacteur ou continue ainsi que les communications sécurisées. L’Article 20 confie également aux organes de direction la responsabilité d’approuver et de superviser les mesures de gestion des risques de cybersécurité.

DORA s’applique depuis le 17 janvier 2025 à un large éventail d’entités financières et crée un régime sectoriel de résilience opérationnelle. Il couvre la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique, le partage d’informations, le risque lié aux tiers TIC et les accords contractuels avec les prestataires tiers de services TIC. Pour les entités financières et les prestataires de services TIC qui les soutiennent, le contrôle d’accès n’est pas seulement un enjeu de protection des données. Il fait partie de la résilience opérationnelle.

ISO/IEC 27001:2022 rattache ces obligations à un système de management fondé sur les risques. Les clauses 6.1.1 à 6.1.3 exigent des organisations qu’elles traitent les risques et opportunités, définissent un processus d’appréciation des risques de sécurité de l’information, identifient les risques pesant sur la confidentialité, l’intégrité et la disponibilité, évaluent les risques, sélectionnent les options de traitement, déterminent les mesures de sécurité, comparent les mesures sélectionnées à l’Annexe A, documentent la Déclaration d’applicabilité, obtiennent l’approbation du propriétaire du risque et acceptent les risques résiduels. Les clauses 8.2 et 8.3 exigent des appréciations des risques à intervalles planifiés ou après une modification significative, ainsi que la mise en œuvre du plan de traitement des risques avec des résultats documentés.

Pour la gouvernance des données à caractère personnel, cela signifie que le contrôle d’accès n’est pas un simple paramètre IAM isolé. C’est une décision de traitement des risques. Un rôle capable d’exporter des dossiers de paie, des données de patients, des informations de paiement, des pièces d’identité, des données de localisation ou des transcriptions de support client doit être justifié dans le registre des risques, reflété dans la Déclaration d’applicabilité, appliqué dans l’IAM, journalisé en production, revu périodiquement et supprimé lorsqu’il n’est plus requis.

Le modèle de contrôle Clarysec : de la promesse de protection des données aux éléments probants

Clarysec traite la gouvernance des accès aux données à caractère personnel comme une chaîne d’éléments probants. Cette chaîne commence par l’inventaire des données et la définition des rôles, se poursuit par l’approbation et l’application des accès, puis se termine par la surveillance, la revue, la révocation et les enregistrements exploitables en audit.

Dans Zenith Controls: The Cross-Compliance Guide, le sujet s’articule principalement autour de trois mesures ISO/IEC 27002:2022 :

Les auditeurs acceptent rarement « nous utilisons l’IAM » comme élément probant. Ils attendent de voir comment les décisions IAM se rattachent aux obligations de protection des données, à la propriété des systèmes, à la classification des données, au besoin métier, au traitement des risques, à la fréquence de revue des accès, au périmètre de journalisation et aux contrats fournisseurs.

La PII Security and Access Control Policy de Clarysec établit le référentiel de base en langage PIMS :

[Both] Le Propriétaire du système / Propriétaire d’application DOIT restreindre l’accès aux données à caractère personnel aux rôles approuvés et aux utilisateurs autorisés enregistrés ou traçables dans REG02 ou REG12 avant l’activation de l’accès.

Extrait de la section « 4.2 Référentiel de base du contrôle d’accès », clause de politique 4.2.1.

Le tag « [Both] » signifie que la mesure s’applique que l’organisation agisse en tant que responsable du traitement ou sous-traitant de données à caractère personnel. Cette distinction est importante. Les responsables du traitement omettent souvent de définir des règles d’accès fondées sur la finalité. Les sous-traitants omettent souvent de prouver que l’accès est limité aux instructions du client, aux circuits de support approuvés et au personnel contractuellement autorisé.

La même politique renforce l’exigence pour les données à caractère personnel sensibles ou à fort impact :

[Both] Le Propriétaire du système / Propriétaire d’application DOIT revoir au moins trimestriellement l’accès des utilisateurs aux systèmes traitant des données à caractère personnel sensibles ou à fort impact et enregistrer le résultat de la revue dans REG12.

Extrait de la section « 4.2 Référentiel de base du contrôle d’accès », clause de politique 4.2.3.

C’est à ce niveau qu’un PIMS devient auditable. La revue des accès n’est pas un simple courriel de manager. C’est un enregistrement dans REG12, rattaché à un système, une catégorie de données, un rôle, un propriétaire, un résultat de revue et une action de remédiation.

Fondement de politique : moindre privilège, besoin métier et refus par défaut

Une gouvernance efficace commence par des règles applicables. Avant qu’Anya puisse présenter à l’auditeur un journal de revue des accès, elle devait montrer que l’exigence de revue des accès avait été formellement établie.

La Access Control Policy - SME de Clarysec pour les PME pose le principe suivant :

Cette politique applique le principe du moindre privilège et exige que l’accès soit limité au minimum nécessaire à l’exercice des fonctions.

Extrait de la section « Objet », clause de politique 1.3.

La Data Protection and Privacy Policy - SME pour les PME rattache l’accès au besoin métier :

L’accès des utilisateurs aux données à caractère personnel doit être limité aux rôles disposant d’un besoin métier documenté.

Extrait de la section « Exigences de gouvernance », clause de politique 5.3.2.

Pour les organisations de plus grande taille, la Data Protection and Privacy Policy d’entreprise exprime l’attente de contrôle comme une exigence système :

Tous les systèmes doivent appliquer par défaut les accès selon le principe du moindre privilège.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.1.

La distinction est importante. Une petite entreprise peut avoir besoin d’un enregistrement léger mais explicite du besoin métier. Une entreprise de plus grande taille a besoin d’une application au niveau système, d’une revue périodique, de la séparation des tâches, d’une gouvernance des accès à privilèges et d’éléments probants conservés pour l’audit interne, l’assurance demandée par les clients, les demandes des autorités de régulation et l’investigation des violations.

Le cycle de vie des accès aux données à caractère personnel : approbation, utilisation, revue, révocation

La défaillance la plus courante en matière d’accès aux données à caractère personnel n’est pas l’approbation initiale. C’est la persistance des accès.

Le Zenith Blueprint, dans la phase « Contrôles en action », étape 22, explique ainsi la mesure ISO/IEC 27002:2022 5.18, Droits d’accès :

Le contrôle 5.18 veille à ce que les droits d’accès ne soient pas seulement accordés de manière appropriée, mais aussi revus, ajustés et révoqués de façon contrôlée et traçable.

Il décrit ensuite des scénarios familiers : un nouvel employé reçoit des accès, change de rôle et conserve ses anciennes autorisations ; un ancien administrateur quitte l’entreprise mais un jeton reste actif ; le compte d’un contractant expire sur le papier mais pas dans l’IAM. Ce sont précisément les faiblesses qui deviennent des incidents de sécurité au titre du GDPR lorsque des données à caractère personnel sont concernées.

La User Account and Privilege Management Policy - SME de Clarysec pour les PME définit une fréquence de base :

Une revue de tous les comptes utilisateurs et privilèges doit être réalisée tous les six mois.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.

Pour les environnements d’entreprise, la User Account and Privilege Management Policy resserre le rythme opérationnel :

Des revues trimestrielles de tous les comptes utilisateurs et privilèges associés doivent être réalisées par la Sécurité informatique en collaboration avec les responsables de département.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.5.1.

Un cycle de vie pratique des accès aux données à caractère personnel doit inclure :

1. Classifier le système et les catégories de données à caractère personnel.
2. Définir les rôles approuvés et le besoin métier documenté.
3. Cartographier les rôles avec les finalités de traitement.
4. Approuver l’accès avant son activation.
5. Appliquer le moindre privilège, la séparation des tâches et l’authentification forte.
6. Journaliser l’authentification, les accès, les exports, la configuration et les actions à privilèges.
7. Revoir les accès selon une fréquence fondée sur les risques.
8. Supprimer les accès en cas de changement de rôle, de départ, de clôture de projet, d’expiration contractuelle ou d’instruction du client.
9. Conserver les éléments probants dans le registre PIMS et la piste d’audit.

Ce n’est pas de la bureaucratie. C’est la manière dont une organisation prouve que l’accès aux données à caractère personnel est contrôlé dès la conception, par défaut et par les éléments probants.

Exemple pratique : la revue trimestrielle des accès aux données à caractère personnel

L’audit d’Anya a réussi lorsqu’elle a déplacé la discussion des déclarations de politique vers les éléments probants.

Elle a d’abord cité la PII Security and Access Control Policy, clause 4.2.3, qui exigeait une revue trimestrielle des accès aux données à caractère personnel sensibles ou à fort impact et l’enregistrement du résultat de la revue dans REG12.

Elle a ensuite présenté à l’auditeur le trimestre précédent :

• L’informatique a généré une liste de tous les utilisateurs, groupes, rôles à privilèges, comptes de service, comptes fournisseurs, rôles d’accès d’urgence et autorisations de support pour la base de données de production contenant les données des patients.
• La liste a été transmise au Propriétaire d’application, le responsable de la réussite client, qui détenait le besoin opérationnel de l’équipe support.
• Le Propriétaire d’application a revu la liste ligne par ligne au regard du rôle actuel, de la responsabilité de support client et de la finalité de traitement.
• Deux agents support ayant changé d’équipe ont été marqués pour révocation.
• Un ticket a été créé dans le système de gestion des services informatiques, lié à la revue des accès, associé à un SLA et clôturé après révocation.
• REG12 a été mis à jour avec l’enregistrement de revue, l’approbateur, les exceptions, le ticket de remédiation, les éléments probants de clôture et la prochaine date de revue.

Le résultat était une chaîne d’éléments probants en boucle fermée. Anya ne s’est pas contentée d’affirmer que Medtelligence appliquait le moindre privilège. Elle a présenté l’exigence de politique, le propriétaire responsable, la liste d’accès, la décision de revue, l’action corrective et la révocation réalisée.

C’est la différence entre contrôle d’accès et gouvernance des accès.

Accès des fournisseurs et des sous-traitants : l’angle mort des audits PIMS

De nombreux risques d’accès non autorisé proviennent du support, de l’externalisation, des partenaires d’intégration, des prestataires de services managés et des sous-traitants ultérieurs. Un sous-traitant peut disposer d’un accès à distance aux données de production des clients. Un fournisseur cloud peut prévoir des circuits d’accès support. Un sous-traitant ultérieur peut maintenir un index de recherche contenant des identifiants clients. Un prestataire de services de sécurité managés peut accéder à des journaux contenant des données à caractère personnel.

Au titre du GDPR, les responsables du traitement doivent recourir à des sous-traitants présentant des garanties suffisantes. Dans ISO/IEC 27701:2025, la gouvernance des sous-traitants et des sous-traitants ultérieurs doit être opérationnalisée au moyen d’instructions documentées, de contrôles contractuels, d’assurance et de surveillance. ISO/IEC 27002:2022 soutient cette approche par les mesures relatives aux relations avec les fournisseurs, notamment 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.20 Traitement de la sécurité de l’information dans les accords fournisseurs et 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC.

Le Zenith Blueprint, phase « Contrôles en action », étape 23, résume notamment les domaines d’éléments probants relatifs aux accords fournisseurs :

✓ Responsabilités de contrôle d’accès, par exemple qui peut accéder à vos données, comment les identifiants sont gérés et quelle surveillance est en place ;

Il inclut également les obligations de confidentialité, les mesures techniques et organisationnelles, les délais de notification des incidents, le droit d’audit, les contrôles des sous-traitants, ainsi que la désactivation des comptes en fin de contrat.

La Processor, Subprocessor and Third-Party Privacy Management Policy de Clarysec transforme cela en éléments probants PIMS côté responsable du traitement :

[Controller] Le Délégué à la protection des données / responsable du PIMS DOIT vérifier que les champs de contrôles contractuels du sous-traitant dans REG08 couvrent le périmètre du traitement, la durée, la finalité, les catégories de données à caractère personnel, les catégories de personnes concernées, la confidentialité, la sécurité, l’autorisation des sous-traitants ultérieurs, l’assistance, l’audit ou l’assurance, la restitution, la suppression et la résiliation avant approbation.

Extrait de la section « 4.3 Contrôles contractuels et instructions documentées », clause de politique 4.3.2.

L’accès des fournisseurs est également encadré directement dans les politiques fournisseurs PME et entreprise de Clarysec. La Third-Party and Supplier Security Policy - SME pour les PME indique :

Les fournisseurs doivent recevoir uniquement l’accès minimal aux systèmes et aux données nécessaire à l’exercice de leur fonction.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.

La Third party and supplier security policy d’entreprise ajoute le RBAC, la revue et le moindre privilège :

Le personnel des fournisseurs doit être soumis au contrôle d’accès basé sur les rôles (RBAC), à des revues périodiques des accès et à l’application du moindre privilège.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.1.

Si l’accès d’un fournisseur peut atteindre des données à caractère personnel, il relève du PIMS. Il doit apparaître dans les contrôles contractuels, les approbations d’accès, les groupes IAM, le périmètre de journalisation, les enregistrements de revue, les enregistrements de départ, les playbooks d’incident et les éléments probants d’audit.

Accès cloud aux données à caractère personnel : la responsabilité partagée n’est pas une responsabilité partagée au titre du GDPR

La gouvernance des accès cloud aux données à caractère personnel est le domaine dans lequel les organisations surestiment souvent le fournisseur et sous-estiment leurs propres responsabilités. Le fournisseur cloud peut sécuriser l’infrastructure, mais le client continue de gouverner les identités, les rôles, la configuration du locataire, l’accès support, les journaux, les paramètres de chiffrement, les autorisations d’export et la préparation à la réponse aux incidents.

Le Zenith Blueprint, phase « Contrôles en action », étape 23, l’énonce clairement dans ses orientations relatives aux services cloud :

Les fournisseurs cloud sécurisent l’infrastructure, mais vous restez responsable de vos données, de vos configurations, de vos politiques d’accès et de votre préparation à la réponse aux incidents.

Il avertit également :

Dans le cloud, la visibilité est partielle sauf si elle est conçue intentionnellement. Vous devez configurer la journalisation, appliquer le chiffrement, définir les rôles d’identité et surveiller l’activité au moyen d’outils natifs ou d’intégrations avec des tiers. Ce n’est pas une tâche d’infrastructure : c’est une exigence du SMSI.

La Cloud Usage Policy de Clarysec transforme cette exigence en exigence d’accès pour l’entreprise :

Tous les services cloud doivent appliquer un contrôle d’accès fondé sur l’identité, aligné sur le principe du moindre privilège.

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.

Pour les organisations agissant en tant que sous-traitants dans des environnements cloud, la Cloud PII Processor Policy de Clarysec définit une obligation de revue PIMS plus spécifique :

[Processor] Le Responsable de la sécurité de l’information DOIT revoir dans REG12, au moins trimestriellement, les accès cloud à privilèges, les accès support, les accès aux données à caractère personnel des clients et la couverture de journalisation.

Extrait de la section « 4.2 Configuration cloud, isolement des locataires, accès et journalisation », clause de politique 4.2.4.

Cette clause est particulièrement pertinente pour les entreprises SaaS, les plateformes hébergées dans le cloud, les services de données managés et les sous-traitants B2B.

La gouvernance des accès cloud aux données à caractère personnel n’est complète que si les journaux cloud natifs, les politiques IAM, les comptes de service, les rôles à privilèges, les outils de support client, les clés API et les fonctions d’export de données sont revus ensemble.

Journalisation et surveillance : la mémoire de la gouvernance des données à caractère personnel

Un programme PIMS de contrôle d’accès sans journaux est une promesse sans mémoire.

La PII Security and Access Control Policy impose de définir le périmètre de journalisation avant l’utilisation en production ou toute modification substantielle :

[Both] Le Propriétaire du système / Propriétaire d’application DOIT définir dans REG12 le périmètre de journalisation des données à caractère personnel pour les événements d’authentification, les événements d’accès, les actions à privilèges, les activités d’export de données à caractère personnel et les modifications substantielles de configuration avant l’utilisation en production ou toute modification substantielle.

Extrait de la section « 4.6 Journalisation et surveillance », clause de politique 4.6.1.

La Logging and Monitoring Policy - SME de Clarysec pour les PME explicite le contenu des journaux d’accès :

Journaux d’accès : accès aux fichiers, notamment pour les données sensibles ou à caractère personnel, modifications d’autorisations, utilisation de ressources partagées.

Extrait de la section « Exigences de gouvernance », clause de politique 5.4.3.

La Logging and Monitoring Policy d’entreprise se concentre sur l’utilisabilité en audit :

Le registre de piste d’audit du SMSI doit enregistrer la disponibilité des données de journalisation pour les audits, les investigations et les revues réglementaires.

Extrait de la section « Exigences de gouvernance », clause de politique 5.4.

C’est essentiel, car les éléments probants de protection des données doivent souvent répondre à des questions événementielles :

• Qui a accédé aux données à caractère personnel ?
• L’accès était-il autorisé ?
• L’accès était-il lié à un ticket de support, une demande juridique, une tâche opérationnelle ou une instruction du client ?
• Les données ont-elles été exportées, copiées, modifiées ou supprimées ?
• Un accès à privilèges a-t-il été utilisé ?
• Les autorisations ont-elles été modifiées avant ou après l’accès ?
• L’activité indiquait-elle un incident de sécurité ou une violation de données à caractère personnel ?

Les journaux ne servent pas seulement au SOC. Ce sont des éléments probants PIMS, des éléments probants d’assurance demandée par les clients, des éléments probants d’assurance des sous-traitants et des éléments probants de réponse aux incidents.

Cartographie croisée de conformité : un modèle d’accès, plusieurs angles d’analyse

Une faiblesse dans les revues d’accès aux données à caractère personnel n’est jamais un constat isolé. Elle peut devenir un problème de responsabilité au titre du GDPR, une faiblesse du PIMS ISO/IEC 27701:2025, une non-conformité ISO/IEC 27001:2022, une défaillance de gouvernance NIS2, un sujet de résilience DORA, une lacune de gouvernance NIST CSF 2.0 ou un enjeu de maturité de processus COBIT 2019.

Une table de correspondance plus détaillée des mesures montre comment un même processus de gouvernance des accès aux données à caractère personnel soutient plusieurs exigences :

La valeur de Zenith Controls est de permettre aux équipes de rattacher ces différents angles aux mêmes éléments probants de contrôle plutôt que de maintenir des silos de conformité séparés.

Réaliser un sprint de 45 minutes sur les éléments probants d’accès aux données à caractère personnel

Une façon utile de tester la préparation consiste à choisir un système à fort impact, par exemple une plateforme de support client, un système RH, un portail de paiement, un portail patient, un lac de données ou une base de données de production SaaS, puis à réaliser un sprint ciblé sur les éléments probants.

Étape 1 : définir le contexte de traitement des données à caractère personnel

Enregistrer dans REG12 :

• Nom du système et propriétaire
• Catégories de données à caractère personnel
• Catégories de personnes concernées
• Rôle de responsable du traitement ou de sous-traitant
• Finalité de traitement
• Indicateur de données à caractère personnel sensibles ou à fort impact
• Dépendances cloud, fournisseurs et sous-traitants ultérieurs

Si le système implique un sous-traitant, vérifier les champs de contrôles contractuels REG08 à l’aide de la Processor, Subprocessor and Third-Party Privacy Management Policy. L’approbation doit couvrir le périmètre du traitement, la durée, la finalité, les catégories de données à caractère personnel, les catégories de personnes concernées, la confidentialité, la sécurité, l’autorisation des sous-traitants ultérieurs, l’assistance, l’audit ou l’assurance, la restitution, la suppression et la résiliation.

Étape 2 : extraire la liste des accès

Exporter tous les utilisateurs, groupes, rôles à privilèges, comptes de service, rôles de support, comptes d’accès d’urgence, clés API et comptes fournisseurs. Comparer chaque habilitation aux rôles approuvés.

Étape 3 : confirmer le moindre privilège et l’alignement sur les finalités

Utiliser le référentiel de base de la PII Security and Access Control Policy : l’accès doit être limité aux rôles approuvés et aux utilisateurs autorisés enregistrés ou traçables dans REG02 ou REG12 avant activation. Si un utilisateur ne peut pas être rattaché à un rôle, une finalité et une approbation, le constat n’est pas « documentation manquante ». Le constat est « accès aux données à caractère personnel non démontrablement autorisé ».

Étape 4 : vérifier le périmètre de journalisation

Confirmer que les journaux capturent l’authentification, les événements d’accès, les actions à privilèges, les activités d’export de données à caractère personnel et les modifications substantielles de configuration. Confirmer ensuite où les journaux sont stockés, pendant combien de temps ils sont conservés, qui peut y accéder et s’ils sont enregistrés dans le registre de piste d’audit du SMSI pour les audits, les investigations et les revues réglementaires.

Étape 5 : boucler le processus

Pour chaque exception, enregistrer le propriétaire du risque, l’action immédiate de confinement, la remédiation permanente, la date cible, les éléments probants requis, la décision relative au risque résiduel et la nécessité éventuelle d’une évaluation d’une violation de données à caractère personnel.

Cet exercice révèle généralement la maturité réelle de la gouvernance des accès aux données à caractère personnel. Les organisations robustes peuvent répondre rapidement. Les organisations faibles découvrent que la politique de protection des données, la configuration IAM, les contrats de sous-traitants, la journalisation cloud et les éléments probants d’audit sont déconnectés.

Constats d’audit courants en matière de gouvernance des accès aux données à caractère personnel

La plupart des constats sont prévisibles. Ils apparaissent lorsque la protection des données, la sécurité, le juridique, l’informatique et les fournisseurs contrôlent chacun une partie du sujet, mais que personne ne possède le cycle de vie complet des accès aux données à caractère personnel.

Les constats courants incluent :

• Les systèmes contenant des données à caractère personnel ne sont pas entièrement listés dans l’inventaire PIMS.
• Les rôles d’accès sont définis techniquement mais ne sont pas rattachés aux finalités de traitement.
• Les données à caractère personnel sensibles sont accessibles via de larges groupes opérationnels.
• Les revues trimestrielles couvrent les employés, mais pas les comptes de service, les clés API ou les utilisateurs fournisseurs.
• L’accès support cloud est possible, mais n’est pas revu comme un accès aux données à caractère personnel.
• Des journaux existent, mais ne prouvent pas l’accès aux données à caractère personnel, l’export ou l’activité à privilèges.
• Les contrats de sous-traitants incluent des clauses de confidentialité génériques, mais pas de contrôles spécifiques relatifs au contrôle d’accès, à l’audit, aux sous-traitants ultérieurs, à la restitution, à la suppression ou à la résiliation.
• D’anciens employés ou contractants conservent des accès via des groupes partagés ou des jetons non gérés.
• L’accès à l’entrepôt de données est plus large que l’accès à l’application source.
• Des comptes d’accès d’urgence existent sans revue après utilisation.
• L’usurpation d’identité par le support client n’est pas journalisée avec le contexte du ticket.
• La Déclaration d’applicabilité inclut des contrôles d’accès, mais les éléments probants ne démontrent pas une mise en œuvre spécifique aux données à caractère personnel.

Chacun de ces constats peut devenir, selon le périmètre, un problème de responsabilité au titre du GDPR, un enjeu d’assurance demandée par les clients, une faiblesse de gouvernance NIS2 ou DORA, ou une non-conformité ISO/IEC 27001:2022.

À quoi ressemble un modèle mature

Un modèle opérationnel mature ne repose pas sur des nettoyages trimestriels héroïques. Il intègre la gouvernance des accès aux données à caractère personnel dans les opérations courantes.

Premièrement, l’organisation dispose d’une connaissance des données. Elle sait où se trouvent les données à caractère personnel, pourquoi elles sont traitées, quel rôle PIMS s’applique et quels systèmes, fournisseurs, services cloud, journaux, sauvegardes et exports relèvent du champ d’application.

Deuxièmement, les accès sont fondés sur les rôles et alignés sur les finalités. Les autorisations sont définies selon les rôles approuvés, le besoin métier documenté, la finalité de traitement et le moindre privilège.

Troisièmement, les contrôles sont appliqués techniquement. L’IAM, le RBAC, la gestion des accès à privilèges, l’authentification multifacteur, l’accès conditionnel, les contrôles des locataires, le chiffrement et la ségrégation des environnements appliquent les exigences de politique.

Quatrièmement, la surveillance est conçue intentionnellement. L’organisation peut reconstruire l’authentification, les accès, les exports, les actions à privilèges, les accès support et les modifications de configuration affectant les données à caractère personnel.

Cinquièmement, les revues sont fondées sur les risques et documentées. Les données à caractère personnel à fort impact font l’objet d’une revue au moins trimestrielle. Les accès fournisseurs et support cloud sont inclus. Les exceptions sont suivies jusqu’à leur clôture.

Sixièmement, les éléments probants sont réutilisables. Les mêmes enregistrements soutiennent la responsabilité au titre du GDPR, le fonctionnement du PIMS ISO/IEC 27701:2025, le traitement des risques ISO/IEC 27001:2022, les mesures de gestion des risques NIS2, la gouvernance des risques TIC DORA, les résultats GOVERN de NIST CSF 2.0 et l’assurance de management COBIT 2019.

C’est la différence entre un contrôle d’accès traité comme un paramètre et une gouvernance des accès traitée comme un système.

Transformer les accès aux données à caractère personnel en éléments probants exploitables en audit

Si votre prochain audit, votre prochaine revue client ou la prochaine demande d’une autorité de régulation commençait demain par « montrez-moi qui peut accéder aux données à caractère personnel », votre équipe produirait-elle des éléments probants en quelques minutes, ou commencerait-elle à rapprocher des tableurs ?

Clarysec peut vous aider à combler cet écart.

Commencez par la PII Security and Access Control Policy, alignez les obligations des sous-traitants et du cloud au moyen de la Processor, Subprocessor and Third-Party Privacy Management Policy et de la Cloud PII Processor Policy, puis utilisez le Zenith Blueprint: An Auditor’s 30-Step Roadmap pour mettre en œuvre les contrôles dans le bon ordre. Enfin, utilisez Zenith Controls: The Cross-Compliance Guide pour cartographier les éléments probants d’accès aux données à caractère personnel dans ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 et COBIT 2019.

La prochaine étape pratique la plus rapide est simple : sélectionner un système contenant des données à caractère personnel à fort impact, renseigner REG12, exporter la liste des accès, vérifier le périmètre de journalisation et réaliser une revue de type trimestriel. En une session, vous saurez si votre gouvernance des accès aux données à caractère personnel est prête pour l’audit, ou seulement prête sur le papier.