SOC 2 veut des preuves. Pas un tableur.

Sur le papier, votre revue d’accès fonctionne

Chaque trimestre, quelqu’un de l’équipe sécurité envoie un tableur à 40 managers. Les managers sont occupés, incertains de ce que leurs équipes utilisent vraiment, et flous sur ce que « revoir » veut dire. Ils cochent « approuvé » sur la plupart des lignes et renvoient le fichier. Quelqu’un collecte les réponses. Le dossier de preuves d’audit gagne une pièce jointe de plus.

C’est ainsi que la plupart des entreprises mènent leurs revues d’accès aujourd’hui. Cela satisfait la lettre de l’exigence. Cela satisfait de moins en moins les auditeurs, et sûrement pas l’esprit de ce que demandent SOC 2 et ISO 27001.

Ce que les référentiels exigent réellement

SOC 2 et ISO 27001 se soucient de la même question de fond : pouvez-vous prouver que les accès sont maîtrisés, appropriés, et retirés lorsqu’ils n’ont plus lieu d’être ?

La distinction déterminante pour SOC 2 se joue entre le Type I et le Type II. Le Type I dit : « nous avons des contrôles conçus pour satisfaire ces critères ». Le Type II dit : « ces contrôles ont fonctionné efficacement sur toute la période auditée ». Pour les revues d’accès, le Type II impose de démontrer que les revues ont bien eu lieu, qu’elles étaient complètes, et qu’elles ont donné lieu à des retraits, de façon constante sur 6 à 12 mois.

« Nous avons une politique » est une réponse de Type I à une question de Type II.

Trois façons dont les revues d’accès échouent en pratique

À quoi ressemble une bonne preuve

Ce que les auditeurs veulent voir, c’est une boucle fermée : découverte → revue → décision → remédiation → preuve. Chaque étape traçable, horodatée, et attribuable à un relecteur nommé.

Voici à quoi ressemble une campagne de revue structurée, quand les données sont réellement là pour la soutenir :

C’est la colonne « dernière activité » qui fait la différence entre une vraie revue et un tampon. Sans elle, un manager qui examine les accès de Tom n’a aucune base de décision. Avec elle, « il y a 94 jours » sur un compte administrateur Salesforce saute aux yeux.

Pour l’audit, l’export de cette revue doit montrer :

La question de la fréquence

SOC 2 ne prescrit pas de cadence précise, mais la plupart des auditeurs attendent une revue trimestrielle pour les accès à privilèges et au moins annuelle pour les utilisateurs standard. ISO 27001 dit « à intervalles réguliers », ce qui s’interprète généralement comme trimestriel ou semestriel selon votre profil de risque.

La question la plus utile est : pourquoi la fréquence est-elle la contrainte ?

La cadence trimestrielle est un artefact du processus manuel. Collecter les données d’accès, construire des tableurs, relancer les managers, réconcilier les retraits. C’est assez long pour qu’une fréquence supérieure soit hors de portée. Mais le risque sous-jacent, lui, est continu. Quelqu’un change de poste un mardi de février. La revue suivante n’est qu’en avril. Pendant deux mois, il détient un accès qu’il ne devrait plus avoir.

Quand les données d’accès sont vivantes et les campagnes automatisées, les revues peuvent se déclencher sur événement : un changement de poste, une fin de projet, 60 jours d’inactivité, plutôt que sur le seul calendrier. La revue trimestrielle devient alors un artefact de conformité qui confirme ce que la surveillance continue a déjà repéré, au lieu d’être la première ligne de découverte.

C’est toute la différence entre la revue d’accès comme exercice de conformité et la revue d’accès comme véritable contrôle.