Preuves d'audit ISO 27001 : ce que demandent les auditeurs et comment les collecter sans course de dernière minute

Les auditeurs ISO 27001 échantillonnent des enregistrements datés sur toute la période auditée, pas un instantané du mois précédent. Les informations documentées exigées, les preuves typiques par domaine, leur vitesse d'obsolescence et comment les collecter au fil du travail.

Daniel Grigorovich
Daniel Grigorovich
Fondateur · 7 Sept 2026 · 11 min de lecture
ISO 27001EvidenceAudit
Preuves d'audit ISO 27001 : ce que demandent les auditeurs

Les preuves d’audit ISO 27001 sont des enregistrements datés, créés au moment où le travail a été fait : les informations documentées qu’exigent les articles 4 à 10, plus les tickets, journaux et revues qui montrent que les mesures de l’annexe A ont été appliquées. Les auditeurs de certification les échantillonnent sur toute la période auditée. Un dossier constitué le mois précédent montre l’état actuel et appelle des questions sur tous les autres mois.

Ce guide couvre ce que demandent les auditeurs, les informations documentées exigées, ce que les auditeurs acceptent, la collecte automatique, les preuves manquantes, les outils de gestion des preuves, ce que l’automatisation ne prouve pas, et une liste de contrôle.

Domaine de mesuresPreuves typiquesOù elles se trouventQuand elles se périment
Cœur du SMSI (4.3, 5.2, 6.1, 6.2)Périmètre, politique, registre des risques, DdA, plan de traitement, objectifsEspace documentaire ou outil GRCQuand l’activité change ; revue au moins annuelle
Actifs (A.5.9)Inventaire avec propriétaires, rapproché de ce qui tourne réellementGestion des appareils, comptes cloudÀ chaque nouvel appareil ou nouvelle ressource cloud
Droits d’accès (A.5.18)Tickets d’arrivée et de départ, enregistrements de retrait des accès, revues d’accès signéesSIRH, fournisseur d’identité, outil de ticketsÀ chaque embauche et chaque départ ; revues souvent trimestrielles
Authentification et configuration (A.8.5, A.8.9)Couverture de l’authentification à plusieurs facteurs (MFA) par compte, configurations de référence, rapports de dériveFournisseur d’identité, outils de posture cloudEn continu : un seul nouveau compte administrateur la modifie
Vulnérabilités (A.8.8)Résultats de scans, tickets montrant les corrections dans vos délaisScanner, outil de ticketsDe chaque semaine à chaque mois
Sauvegarde (A.8.13)Rapports de tâches et résultats datés des tests de restaurationOutil de sauvegarde, compte rendu de testTâches chaque jour ; tests de restauration à l’intervalle fixé par votre politique
Journalisation et surveillance (A.8.15, A.8.16)Paramètres de conservation, tickets d’alerte, enregistrements de revuePlateforme de journaux, outil de ticketsEn continu
Changements (A.8.32)Tickets de changement ou pull requests avec approbationOutil de tickets, gestion de versionsÀ chaque changement
Fournisseurs (A.5.19 à A.5.22)Registre, évaluations, clauses contractuelles, enregistrements de revueRéférentiel des contrats, achatsÀ chaque nouveau fournisseur ; revues souvent annuelles
Incidents (A.5.24 à A.5.27)Registre des incidents, enregistrements de réponse, enseignements appliquésOutil de ticketsÀ chaque incident
Formation (A.6.3, 7.2)Attestations de suivi par personnePlateforme de formation, RHÀ chaque arrivée ; cycles souvent annuels
Audit et revue (9.2, 9.3, 10.2)Programme et rapports d’audit, comptes rendus de revue, registre des actions correctivesEspace documentaire, outil de ticketsÀ chaque intervalle planifié

La dernière colonne relève de la pratique, pas d’une exigence. ISO 27001 dit le plus souvent « à des intervalles planifiés » ou « régulièrement » et vous laisse fixer la fréquence. L’auditeur vous évalue ensuite au regard de vos propres intervalles.

Quelles preuves les auditeurs ISO 27001 demandent-ils ?

Les organismes de certification sont accrédités selon l’ISO/IEC 17021-1. Cette norme exige que les auditeurs recueillent les informations par un échantillonnage approprié et les vérifient pour qu’elles deviennent des preuves d’audit (9.4.4.1), au moyen d’entretiens, d’observations et de l’examen de la documentation et des enregistrements (9.4.4.2). L’entretien vérifie si les personnes font ce que dit l’enregistrement. Chaque rapport d’audit indique que l’audit repose sur un processus d’échantillonnage (9.4.8.2).

Ils échantillonnent sur une période, pas à un instant donné. Pas une revue d’accès, mais une série de revues datées. L’étape 2 a pour objet d’évaluer la mise en œuvre, y compris l’efficacité, du système de management (9.3.1.3), et cela suppose un historique. En pratique, les organismes de certification attendent d’abord environ trois mois de fonctionnement. En surveillance, la fenêtre est la période écoulée depuis la dernière visite. Le premier audit est détaillé dans les audits d’étape 1 et d’étape 2.

Certains enregistrements sont vérifiés à chaque visite. Chaque audit de surveillance doit couvrir, entre autres, les audits internes, la revue de direction et les actions menées sur les non-conformités précédentes (9.6.2.2). Aucun de ces éléments ne peut être produit après coup de manière crédible. Les années deux et trois sont traitées dans les audits de surveillance.

Quelles informations documentées la norme ISO 27001 exige-t-elle ?

L’article 7.5.1 les répartit en deux : les informations documentées exigées par la norme, et celles que vous jugez nécessaires à l’efficacité du SMSI. Sa note précise que leur étendue varie selon la taille, la complexité et la compétence des personnes. Une entreprise de 30 personnes n’a pas besoin d’un manuel de 200 pages.

La partie exigée, article par article, dans l’ISO/IEC 27001:2022 :

ArticleInformations documentées
4.3Périmètre du SMSI
5.2Politique de sécurité de l’information
6.1.2Processus d’appréciation des risques
6.1.3Processus de traitement des risques, déclaration d’applicabilité
6.2Objectifs de sécurité de l’information
7.2Preuves de compétence
8.1De quoi avoir l’assurance que les processus se sont déroulés comme prévu
8.2, 8.3Résultats de l’appréciation et du traitement des risques
9.1Résultats de la surveillance et de la mesure
9.2.2Programme d’audit et résultats d’audit
9.3.3Résultats des revues de direction
10.2Non-conformités, actions entreprises, résultats des actions correctives

L’article 8.1 est celui qui s’étend jusqu’à l’annexe A. Des enregistrements doivent exister dans la mesure nécessaire pour avoir l’assurance que les processus ont été réalisés comme prévu. C’est de là que vient l’essentiel des preuves opérationnelles. La mesure 5.28 de l’annexe A, « Recueil de preuves », est autre chose : elle couvre les preuves relatives aux événements liés à la sécurité de l’information, c’est-à-dire les incidents et l’investigation numérique.

L’article 7.5.3 s’applique ensuite aux preuves elles-mêmes. Elles doivent être disponibles quand on en a besoin, protégées contre la perte de confidentialité, une utilisation inappropriée ou la perte d’intégrité, soumises à la maîtrise des versions, et conservées ou éliminées de manière délibérée. Un dossier partagé de captures d’écran modifiable par tous se défend mal au regard de cet article.

Quelles preuves les auditeurs ISO 27001 acceptent-ils ?

L’idée que les preuves doivent être soignées génère beaucoup de travail inutile. Les auditeurs acceptent des enregistrements produits comme sous-produit du travail. Un ticket daté. Une entrée de journal. Une approbation dans l’outil où se font les approbations. Une revue validée, avec le nom du réviseur et la date.

Ils repèrent les preuves fabriquées pour eux, car elles se voient facilement. Des documents aux horodatages rapprochés. Une netteté que les opérations réelles n’ont pas. Une capture d’écran d’un paramètre plutôt que la trace du changement qui l’a défini.

Ils acceptent les lacunes expliquées. Un historique de correctifs avec un trou et une note qui explique pourquoi, c’est un système qui fonctionne avec un problème connu. Un historique de correctifs sans aucun trou, pour une entreprise de quarante personnes, c’est une affirmation à laquelle personne ne croit.

Le niveau attendu n’est pas la perfection. C’est la contemporanéité : cela a-t-il été enregistré au moment où c’est arrivé ?

Collecte de preuves ISO 27001 : que peut-on automatiser ?

  • État de configuration. Application de la MFA, chiffrement, politiques d’accès, posture cloud. Lisible directement dans les systèmes, en continu. Si vous faites encore des captures d’écran de paramètres, corrigez cela en premier.
  • Enregistrements d’événements. Connexions, changements, correctifs, alertes, incidents. Les systèmes les créent de toute façon. Le travail consiste à les conserver sur toute la fenêtre d’audit.
  • Décisions humaines. Acceptations de risques, approbations, dérogations, évaluations de fournisseurs, décisions de revue de direction. Elles ne peuvent pas se générer seules, car la décision est la preuve. Elles ont besoin d’un endroit où vivre, avec un responsable et une date.
  • Activités périodiques. Revues d’accès, formation, tests de restauration, exercices de continuité, audits internes. Elles ont besoin d’un calendrier qui produit un enregistrement daté, que quelqu’un pense à l’audit ou non.

Les deux premières catégories devraient être automatiques. Les décisions ont besoin d’un système de référence. Les activités périodiques ont besoin d’un calendrier contraignant. L’essentiel des difficultés de préparation d’audit vient du fait de traiter les quatre comme des décisions et de tout faire à la main.

Que faire s’il manque des preuves avant un audit ISO 27001 ?

Quatre à six semaines avant l’audit, quelqu’un ouvre la liste des mesures et commence à collecter. Une capture d’écran des paramètres MFA. Une liste de fournisseurs reconstituée de mémoire par trois personnes. Un rapport de sauvegarde pour ce mois-ci, parce que personne n’a gardé les précédents. L’audit passe, et tout recommence l’année suivante, car seule l’échéance a changé.

Le coût dépasse les heures passées. Des preuves assemblées reflètent l’état actuel, ce qui appelle la question des onze autres mois. Le travail retombe sur l’ingénieur qui était occupé à autre chose. On obtient un dossier, pas un enregistrement : un dossier constitué en mars décrit mars et n’apporte rien à l’audit suivant.

Si vous en êtes là :

  1. N’antidatez pas et ne recréez pas d’enregistrements. Les métadonnées des fichiers n’ont rien de discret, et un seul enregistrement fabriqué discrédite les vrais.
  2. Listez les mesures applicables de votre déclaration d’applicabilité et classez chacune : enregistrement existant, partiel, aucun.
  3. Lancez cette semaine les activités récurrentes manquantes, même imparfaites. Une revue d’accès imparfaite mais datée vaut mieux qu’une revue parfaite qui n’a pas eu lieu.
  4. Consignez chaque lacune comme une non-conformité, avec sa cause et une action corrective, conformément à l’article 10.2. Une lacune que votre propre système a détectée et qu’il est en train de combler prouve que le système fonctionne.
  5. Vérifiez d’abord les enregistrements essentiels : audit interne, revue de direction, appréciation des risques. Ils sont examinés à chaque visite.
  6. Si l’étape 2 approche et que des enregistrements essentiels manquent, décalez la date. Un audit de surveillance ne peut pas attendre : le premier doit avoir lieu dans les 12 mois suivant la décision de certification (ISO/IEC 17021-1, 9.1.3.3).

Que doit faire un outil de gestion des preuves ISO 27001 ?

La norme n’en exige pas. L’article 7.5.2 demande seulement un format et un support appropriés, papier compris. En pratique, un tableur et un lecteur partagé ne suivent plus au-delà de quelques systèmes sources. Quel que soit votre outil, vérifiez qu’il :

  • Lit les preuves dans les systèmes sources au lieu de demander des téléversements.
  • Conserve un historique daté, pas seulement l’état actuel, pour pouvoir répondre sur toute la période.
  • Rattache chaque élément à une mesure, pour qu’un même enregistrement serve à plusieurs référentiels et questionnaires clients.
  • Réunit mesures, lacunes et tâches, chacune avec un responsable et une échéance.
  • Envoie les exceptions à une personne, pas seulement à un tableau de bord.
  • Maîtrise les preuves comme l’exige l’article 7.5.3 : accès, intégrité, versions, conservation.
  • Exporte ce que l’auditeur échantillonne sans une semaine de mise en forme.

Une mesure porte alors quatre éléments : un responsable, un statut, ses preuves et une date. Quand un auditeur ou un client pose la question, la réponse est déjà là, comme le montre comment répondre à un questionnaire de sécurité.

La réalité technique : une preuve automatisée montre qu’une mesure a été exécutée, pas qu’elle a été efficace

Des preuves qui s’assemblent d’elles-mêmes suppriment la course de dernière minute. Elles ne prouvent pas que la mesure remplit son rôle, et le texte de la mesure exige souvent précisément ce qu’un enregistrement automatisé laisse de côté.

La mesure A.8.8 exige que l’exposition aux vulnérabilités soit évaluée et que des mesures appropriées soient prises. Un scan mensuel qui classe lui-même son rapport prouve que le scan a tourné. Il a le même aspect, que les constats critiques aient été corrigés en trois jours ou ignorés pendant neuf mois. La mesure A.8.15 exige que les journaux soient produits, stockés, protégés et analysés. Les paramètres de conservation prouvent les trois premiers points. La mesure A.8.13 exige que les sauvegardes soient testées régulièrement. Un rapport de tâche nocturne ne prouve aucune restauration.

L’étape 2 évalue bien l’efficacité, mais celle du système de management, et sur un échantillon. Quelques jours d’échantillonnage peuvent passer à côté d’un constat resté ouvert pendant la majeure partie de l’année. Votre propre audit interne peut faire mieux s’il teste au lieu de relire : restaurer une sauvegarde, suivre un constat du scanner jusqu’à sa clôture.

Combler cet écart, c’est faire en sorte que les preuves enregistrent le résultat, pas seulement l’activité : délai de correction des constats critiques, alertes examinées et closes, restaurations chronométrées. Chaque constat a besoin d’un responsable et d’une échéance, imposée par autre chose que le calendrier d’audit. C’est ainsi que fonctionne la plateforme CloudSoul : collecte automatisée depuis vos systèmes, avec une expertise humaine dans la boucle qui examine les exceptions. C’est aussi ainsi que nous menons nos programmes ISO 27001. Si personne dans l’entreprise ne peut prendre en charge ces exceptions, ISO 27001 sans équipe sécurité explique qui fait quoi.

Liste de contrôle des preuves d’audit ISO 27001

  • Rattachez chaque mesure applicable de la DdA à un enregistrement, au système où il se trouve et à un responsable.
  • Collectez automatiquement l’état de configuration et les enregistrements d’événements, avec un historique daté.
  • Donnez à chaque acceptation de risque, dérogation et approbation un responsable et une date.
  • Planifiez les activités périodiques pour que chacune produise un enregistrement daté.
  • Tenez à jour le programme d’audit, les rapports d’audit, les comptes rendus de revue et le registre des actions correctives.
  • Enregistrez les lacunes comme des non-conformités avec des actions correctives. Ne complétez jamais a posteriori.
  • Faites en sorte que les preuves montrent des résultats : délais de correction, journaux analysés, restaurations testées.

Sources

  • ISO/IEC 27001:2022, Information security management systems: Requirements, articles 4 à 10 (notamment 7.5) et annexe A, ISO.
  • ISO/IEC 17021-1:2015, Conformity assessment: Requirements for bodies providing audit and certification of management systems, articles 9.1.3.3, 9.3.1.3, 9.4.4, 9.4.8.2 et 9.6.2.2, ISO.

Questions fréquentes

Quelles preuves les auditeurs ISO 27001 demandent-ils ?

Les informations documentées exigées par la norme, comme le périmètre, la politique, l'appréciation des risques, la déclaration d'applicabilité, les résultats d'audit interne et les résultats de revue de direction, ainsi que les enregistrements montrant que les mesures ont été appliquées. Les auditeurs échantillonnent ces enregistrements et les vérifient par des entretiens et des observations.

Sur quelle période les auditeurs ISO 27001 examinent-ils les preuves ?

Sur toute la période auditée, pas seulement l'état actuel. À l'étape 2, c'est la durée de fonctionnement du système de management, en pratique environ trois mois ou plus. Lors d'un audit de surveillance, c'est la période écoulée depuis la dernière visite.

Que faire s'il manque des preuves avant un audit ISO 27001 ?

N'antidatez pas et ne recréez pas d'enregistrements. Consignez chaque lacune comme une non-conformité avec une action corrective et commencez dès maintenant à produire l'enregistrement. Si l'étape 2 est proche et que des enregistrements essentiels comme l'audit interne manquent, décalez la date.

La norme ISO 27001 exige-t-elle un outil de collecte de preuves ?

Non. Les informations documentées peuvent être sous tout format ou sur tout support approprié, papier compris. Elles doivent être maîtrisées : disponibles en cas de besoin, protégées, soumises à la maîtrise des versions, et conservées ou éliminées de manière délibérée.

La mesure 5.28 de l'annexe A porte-t-elle sur la collecte des preuves d'audit ?

Non. La mesure 5.28 couvre les preuves relatives aux événements liés à la sécurité de l'information, c'est-à-dire les incidents et l'investigation numérique. Les preuves d'audit relèvent de l'article 7.5 sur les informations documentées et des articles qui y font appel.

Découvrez comment CloudSoul fonctionnerait pour vous.

Daniel Grigorovich

Daniel Grigorovich · Fondateur

Je pense qu'aucune entreprise ne devrait avoir à subir les « listes de contrôle de conformité » ni à se débattre avec des textes réglementaires obscurs. Bien que je reste attaché au principe selon lequel tous les logiciels doivent être fiables et sécurisés, je souhaite offrir aux entreprises un moyen de surmonter les difficultés rencontrées lors de la mise en œuvre de ces exigences.