Ce que 20 ans de cybersécurité m'ont appris sur les audits
Après deux décennies de préparation, de participation et de suivi d'audits de sécurité, quelques enseignements restent vrais, quel que soit le référentiel.

J'ai passé vingt ans dans la cybersécurité, et une bonne partie de ce temps a été consacrée aux audits : les préparer, y participer, débattre des constats et corriger ce qu'ils ont mis en évidence. Les référentiels ont changé à maintes reprises. Ces enseignements, eux, non.
1. Les preuves l'emportent sur le récit
Le constat d'audit le plus fréquent n'est pas un contrôle manquant. C'est un contrôle qui a été effectué mais qu'on ne peut pas prouver. La revue des accès a eu lieu, mais personne n'a conservé la liste. Le changement a été approuvé dans un fil de discussion depuis supprimé. Les auditeurs ne peuvent se fier qu'à ce qu'ils voient. Concevez des contrôles qui laissent des preuves comme effet secondaire de leur exécution, et la plupart des constats disparaissent.
2. Le périmètre décide de tout
La plupart des difficultés en audit remontent au périmètre : trop large, si bien que chaque système doit satisfaire chaque contrôle ; trop étroit, si bien que la certification ne répond pas à la question du client ; ou flou, si bien que personne ne sait quels systèmes comptent. Définissez-le délibérément, consignez-le par écrit et défendez-le. Notre article sur le périmètre d'un premier rapport SOC 2 s'applique à presque tout audit.
3. Les contrôles qui échouent sont ceux dont personne n'est responsable
Lorsqu'un contrôle a un propriétaire désigné qui l'exécute dans le cadre de sa mission, il fonctionne. Lorsqu'il relève de « l'IT » ou de « l'équipe sécurité » en général, il dérive jusqu'à la semaine qui précède l'audit. La responsabilisation est l'amélioration de contrôle la moins coûteuse qui soit.

4. Les documents doivent décrire la réalité
Une politique type qui décrit une entreprise que vous n'êtes pas est pire qu'une politique courte qui décrit l'entreprise que vous êtes. Les auditeurs testent ce que vous avez écrit. Chaque écart entre le document et la pratique devient un constat, et souvent un problème de crédibilité pour tout le reste de ce que vous leur présentez.
5. Les auditeurs sont plus utiles comme alliés que comme adversaires
Les audits qui se passent le mieux sont ceux où l'équipe considère l'auditeur comme une seconde paire d'yeux plutôt que comme un adversaire. Demandez tôt comment ils testeront un contrôle. Signalez les faiblesses connues accompagnées d'un plan. Un constat que vous avez soulevé vous-même, avec une correction en cours, se lit très différemment de celui qu'ils ont dû déterrer.
6. Le second référentiel devrait coûter peu
Les organisations qui gèrent un programme par référentiel paient chaque audit intégralement. Celles qui construisent un jeu de contrôles unique, mis en correspondance avec chacun des référentiels auxquels elles répondent, ne paient pour l'essentiel qu'une seule fois. Le travail de correspondance est fastidieux, mais il se cumule. C'est en grande partie pourquoi j'ai créé ControlMapping.
7. Des référentiels différents, mêmes questions
Après suffisamment d'audits, les référentiels finissent par se confondre. Les auditeurs ISO, les auditeurs SOC 2, les évaluateurs PCI et les régulateurs emploient des mots différents, mais posent les mêmes questions : quel est le périmètre, qui est responsable, comment savez-vous que cela fonctionne, et que se passe-t-il quand ça ne fonctionne pas ? Une organisation capable de répondre clairement à ces quatre questions, preuves à l'appui, s'en sort bien dans presque tout audit. La matrice de couverture l'illustre bien : à travers onze référentiels, les mêmes sujets fondamentaux reviennent sans cesse.
Points clés
- Concevez des contrôles qui laissent des preuves comme effet secondaire.
- Définissez le périmètre délibérément et attribuez un propriétaire nommé à chaque contrôle.
- Considérez les audits comme un sous-produit d'une sécurité bien gérée.
8. Réussir l'audit n'est pas le but
Un audit sans constat signifie que les contrôles du périmètre ont fonctionné sur les échantillons testés. Cela ne signifie pas que l'organisation est sécurisée ; la conformité n'est pas la sécurité. Les meilleures équipes que j'ai vues considèrent les audits comme un sous-produit d'une sécurité bien gérée, et non comme sa finalité.
Si vous ne retenez qu'une chose : décidez de ce que vous faites, faites-le de manière cohérente, et laissez les preuves s'accumuler d'elles-mêmes. L'analyse d'écarts permet de voir jusqu'où vos contrôles actuels vont déjà.
Questions
Quelle est la raison la plus fréquente des constats d'audit ?
D'après mon expérience, des preuves manquantes ou incomplètes pour des contrôles effectivement réalisés : revues effectuées mais non consignées, changements approuvés verbalement, populations qui ne correspondent pas.
Comment se préparer à un audit de sécurité ?
Exécutez les contrôles en continu et conservez leurs preuves au fil de l'eau, vérifiez que les documents correspondent à la pratique, et parcourez vous-même un échantillon avant que l'auditeur ne le fasse.
Devons-nous signaler à l'auditeur les faiblesses que nous connaissons déjà ?
En général, oui. Une faiblesse que vous avez identifiée, avec un responsable et un plan de remédiation, donne l'image d'un environnement de contrôle maîtrisé. Une faiblesse découverte par l'auditeur donne celle d'un défaut de supervision.
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é.