Revues des accès utilisateurs qui satisfont chaque auditeur
Les revues d'accès figurent parmi les contrôles les plus souvent mis en défaut lors des audits, rarement parce que personne ne les a réalisées, et généralement parce que personne ne peut prouver qu'elles ont été menées correctement.
Cet article couvre les 11 référentiels que ControlMapping avait mis en correspondance au moment de sa rédaction. Depuis, DORA, CPS 234, Cyber Essentials ont été ajoutés le 2026-10-27 ; leurs pages et la matrice de couverture les intègrent.
Peu de contrôles sont aussi universels, ou aussi fréquemment mis en défaut, que les revues des accès utilisateurs. Chaque référentiel attend que quelqu'un vérifie périodiquement que chaque personne a toujours besoin des accès dont elle dispose. La plupart des organisations réalisent la revue. Bien moins nombreuses sont celles qui peuvent démontrer à un auditeur qu'elle a été complète, indépendante et suivie d'effets.
Ce qu'exigent les référentiels
| Référentiel | Contrôle d'accès | Lien |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | Définition du sujet |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | Correspondance |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | Correspondance |
| SOC 2 | CC6.1CC6.2CC6.3 | Éditorial |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | Correspondance |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | Correspondance |
| 800-53 | AC-2AC-3 | Correspondance |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | Correspondance |
| GDPR | Art.25(2)Art.32(1)(b) | Éditorial |
| NIS2 | 11.111.211.5 | Correspondance |
| Essential Eight | — | Aucune correspondance dans nos données |
Détail complet et raison de chaque lien : Contrôle d'accès dans les référentiels →
PCI DSS est le seul à imposer une fréquence fixe : tous les comptes utilisateurs et leurs privilèges doivent être revus au moins tous les six mois (7.2.4), ainsi que les comptes d'application et de système (7.2.5.1). Les auditeurs SOC 2 vérifient que les accès sont autorisés, modifiés et retirés de manière appropriée (CC6.2, CC6.3), et recherchent des revues périodiques comme preuves. ISO 27001 exige que les droits d'accès soient revus à intervalles réguliers (A.5.18). HIPAA exige la gestion des accès à l'information et la revue de l'activité (§164.308(a)(4)). CMMC attend que les accès soient limités aux utilisateurs et fonctions autorisés (AC.L2-3.1.1, 3.1.2) ainsi que le moindre privilège.
Une revue conforme
- Population complète. Extrayez la liste des utilisateurs directement du système (un export, et non un tableur tenu manuellement), y compris les comptes de service et partagés.
- Bon relecteur. Le propriétaire du système ou des données, ou le manager de chaque utilisateur, et non l'administrateur qui a accordé l'accès.
- Contexte suffisant. Présentez aux relecteurs le rôle et le niveau d'accès de chaque utilisateur, afin que « approuver » soit une décision éclairée.
- Une décision par compte. Conserver, modifier ou supprimer, avec le nom et la date du relecteur.
- Modifications réellement effectuées. Ouvrez des tickets pour les suppressions et conservez la preuve de leur réalisation.
- Preuves conservées. L'export, les décisions, les tickets et la validation, stockés ensemble.
Fréquence
Utilisez les six mois de PCI DSS comme base pour tous les systèmes dans le périmètre, et revoyez les accès privilégiés chaque trimestre. Si vous disposez d'un rapport SOC 2 de type II, assurez-vous qu'au moins une revue (idéalement deux) tombe dans chaque période d'observation.
Ce que relèvent les auditeurs
- Approbation automatique : chaque compte approuvé en quelques minutes par une personne qui ne pouvait pas le savoir.
- Populations incomplètes : la revue couvrait l'application mais pas la base de données, ou les comptes humains mais pas les comptes de service.
- Auto-revue : des administrateurs approuvant leurs propres accès.
- Suppressions non effectuées : la revue indiquait de supprimer ; le compte existe toujours des mois plus tard.
- Départs détectés par la revue : signe que votre processus de départ des collaborateurs ne fonctionne pas, ce que les auditeurs testeront séparément.
Points clés
- Les revues échouent aux audits sur les preuves, pas sur l'effort : populations incomplètes, auto-revue et suppressions jamais effectuées.
- Utilisez un export système, le bon relecteur, une décision par compte et la preuve des modifications.
- Des revues semestrielles (règle de PCI DSS) et trimestrielles pour les accès privilégiés satisfont tous les référentiels.
- Limitez le périmètre aux systèmes qui comptent et automatisez la mécanique.
Rendre la démarche durable
Automatisez l'export et les rappels, effectuez la revue par système plutôt que par utilisateur, et limitez le périmètre aux systèmes qui comptent : production, données clients, outils privilégiés et tout ce qui relève du périmètre d'un référentiel. Une revue plus petite mais bien documentée vaut mieux qu'une revue étendue qui est toujours en retard.
Consultez les pages Sujet Contrôle d'accès et Accès privilégiés pour chaque exigence avec sa source, ainsi que notre article sur la réutilisation des preuves entre SOC 2, ISO 27001 et PCI DSS.
Questions
À quelle fréquence les accès utilisateurs doivent-ils être revus ?
PCI DSS exige que les comptes utilisateurs et les privilèges d'accès soient revus au moins tous les six mois (7.2.4). La plupart des autres référentiels exigent une revue périodique à une fréquence que vous définissez ; une revue trimestrielle pour les accès privilégiés et semestrielle pour les autres constitue une base courante.
Qui doit effectuer une revue des accès ?
Le propriétaire du système ou des données, ou le manager de l'utilisateur, et non l'administrateur qui a accordé l'accès. Les auditeurs recherchent l'indépendance et un relecteur informé.
Les comptes de service doivent-ils faire l'objet de revues des accès ?
Oui. Les auditeurs incluent de plus en plus les comptes de service, partagés et d'API dans la population soumise à revue ; PCI DSS exige explicitement la revue périodique des comptes d'application et de système (7.2.5.1).
Données au 2026-10-27 : les chiffres de cet article sont calculés à partir de la correspondance actuelle et sont mis à jour lorsqu'elle évolue. Correspondance une table de correspondance publiée (NIST, ENISA, CIS, PCI SSC) établit le lien · Éditorial Jugement de ControlMapping lorsqu'aucune table de correspondance n'existe ; le motif est affiché · partage seulement un résultat CSF 2.0 : à vérifier, mais ce n'est pas une correspondance · Aucune correspondance dans nos données rien de mappé dans nos données ; souvent un travail nouveau, mais consultez les notes de couverture. Pas un conseil en conformité.
Articles connexes
Analyse · 2026-10-27APRA CPS 234 et ISO 27001 : ce que couvre votre SMSI et ce qu'APRA ajouteUn SMSI ISO 27001 couvre presque chaque paragraphe de la norme CPS 234 de l'APRA, mais l'APRA ajoute des obligations pour le conseil d'administration, l'assurance des tiers et des délais de notification stricts.
Analyse · 2026-10-13Exigences MFA comparées dans 11 référentiels de sécuritéQuels référentiels imposent le MFA, à qui et avec quelle rigueur : PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 et HIPAA, comparés côte à côte.
Analyse · 2026-09-29Règle de sécurité HIPAA sous l'angle du NIST CSF 2.0Un programme NIST CSF 2.0 correspond à presque chaque exigence de la Règle de sécurité HIPAA. Ce qui se transpose, les deux exigences qui ne correspondent pas, et ce que le CSF apporte en plus de HIPAA.