Lors d’une préparation d’audit, un directeur informatique m’a montré un dossier partagé intitulé « ISO 27001 final ». Il contenait plus de 300 fichiers : politiques copiées d’un modèle, procédures jamais relues, captures d’écran non datées. Il manquait pourtant deux éléments attendus par l’auditeur : une analyse de risques défendable et une déclaration d’applicabilité cohérente. Les documents indispensables à la certification ISO 27001 ne sont pas ceux qui remplissent un répertoire. Ce sont ceux qui démontrent que l’organisation pilote réellement sa sécurité.

La norme ISO/IEC 27001:2022 ne demande pas une bibliothèque documentaire uniforme. Elle demande des informations documentées adaptées au contexte, au périmètre et aux risques de l’entreprise. Une clinique, un groupe financier et une PME de services ne produiront donc pas exactement les mêmes preuves. En revanche, tous doivent pouvoir expliquer leurs choix, montrer leur application et présenter des enregistrements fiables.

Documents indispensables à la certification ISO 27001

Le premier document à stabiliser est le périmètre du système de management de la sécurité de l’information. Il précise les activités, entités, sites, applications, données et interfaces concernées par la certification. Ce texte paraît simple, mais il évite beaucoup de difficultés. Un périmètre trop large crée des obligations impossibles à démontrer. Un périmètre artificiellement restreint suscite, lui, des questions légitimes sur les fournisseurs, les infrastructures partagées ou les données qui circulent hors du champ annoncé.

Vient ensuite la politique de sécurité de l’information, approuvée par la direction. Elle doit donner une orientation claire : protection de la confidentialité, de l’intégrité et de la disponibilité, respect des exigences applicables, amélioration continue et attribution des responsabilités. Une page utile vaut mieux qu’un texte de quinze pages que personne ne connaît. L’auditeur vérifiera surtout si cette politique correspond aux pratiques observées.

L’organisation doit aussi documenter ses objectifs de sécurité et la façon de les suivre. Des formulations comme « améliorer la sécurité » ne permettent aucun pilotage. Un objectif exploitable indique un résultat attendu, un responsable, une échéance et un indicateur. Par exemple : réduire le délai de retrait des accès après le départ d’un collaborateur, ou atteindre un taux défini de revue des comptes à privilèges.

Le dossier qui porte réellement la décision : risques et traitements

Dans la pratique, le cœur du dossier ISO 27001 est l’ensemble formé par la méthode d’analyse des risques, le registre des risques, le plan de traitement et la déclaration d’applicabilité.

La méthode d’appréciation des risques explique comment les risques sont identifiés, évalués et acceptés. Elle doit définir les critères utilisés : vraisemblance, impact, seuils de tolérance, propriétaires des risques et règles de validation. Il n’est pas nécessaire d’employer une matrice complexe. En revanche, la méthode doit être reproductible. Deux équipes utilisant la même grille devraient parvenir à des conclusions comparables.

Le registre des risques traduit cette méthode dans la réalité de l’entreprise. Il associe un actif ou un processus, une menace, une vulnérabilité, une conséquence, un niveau de risque et un responsable. Un registre utile ne se limite pas aux risques techniques. L’absence de clause de sécurité dans un contrat fournisseur, l’indisponibilité d’une personne clé ou une revue d’accès irrégulière peuvent créer des expositions concrètes.

Le plan de traitement des risques décrit les décisions prises : réduire, transférer, éviter ou accepter un risque. Pour chaque action, il faut une échéance, un porteur et, lorsque nécessaire, des moyens attribués. C’est souvent ici que la documentation révèle un écart entre l’ambition et la capacité d’exécution. Prévoir vingt projets de sécurité sur six mois avec une équipe de deux personnes n’est pas un plan crédible.

La déclaration d’applicabilité, souvent appelée SoA, mérite une attention particulière. Elle recense les mesures de l’annexe A retenues ou écartées, avec une justification. Elle indique également leur état de mise en œuvre. Ce document fait le lien entre les risques identifiés et les mesures choisies. Une mesure exclue sans justification claire sera rapidement repérée. À l’inverse, sélectionner tous les contrôles par prudence complique inutilement l’audit et la maintenance du système.

Ne confondez pas déclaration et preuve

Une politique affirme qu’une revue des accès est réalisée. La preuve, ce sont les campagnes de revue datées, les décisions de retrait, les validations des responsables et le suivi des écarts. Une procédure décrit la gestion des incidents. La preuve, ce sont les tickets, l’analyse des causes, les communications et les actions correctives.

Cette distinction change la préparation de l’audit. Beaucoup d’organisations rédigent correctement leurs documents de référence, puis découvrent tardivement que les enregistrements opérationnels sont dispersés, incomplets ou détenus par un prestataire. Il faut donc prévoir, dès le départ, qui conserve chaque preuve et pendant combien de temps.

Les procédures opérationnelles à formaliser selon vos risques

La norme n’impose pas un manuel de procédures identique pour tous. Toutefois, certains sujets demandent presque toujours une formalisation, car ils reviennent dans les entretiens d’audit et dans les incidents réels.

Les règles de gestion des identités et des accès doivent couvrir la création, la modification et la suppression des comptes, les droits à privilèges, l’authentification et les revues périodiques. Dans une organisation qui s’appuie fortement sur le cloud ou sur des partenaires externes, ce domaine mérite des preuves particulièrement précises.

La gestion des incidents de sécurité doit définir le circuit d’alerte, la qualification, l’escalade, la conservation des éléments utiles et le retour d’expérience. Une procédure trop détaillée sera peu suivie sous pression. Une procédure trop vague laissera les équipes seules au mauvais moment. Le bon niveau dépend de la maturité des équipes et des obligations sectorielles.

La gestion des fournisseurs est également attendue lorsque des tiers hébergent des données, administrent des systèmes ou accèdent à des informations sensibles. Les documents utiles comprennent les critères d’évaluation, les exigences contractuelles, les résultats de revues et le suivi des plans d’action. Un questionnaire fournisseur sans décision documentée ne démontre pas une maîtrise du risque.

Selon le périmètre, il faut aussi documenter les pratiques liées aux sauvegardes, à la continuité, aux changements, au développement sécurisé, à la classification de l’information, au télétravail ou à la protection physique. Le choix doit toujours être justifiable par les risques, les exigences légales et les engagements clients.

Les enregistrements que l’auditeur demandera à voir

La certification ne repose pas seulement sur des documents approuvés. Elle repose sur des traces montrant que le système fonctionne. Les principales preuves à organiser sont les suivantes :

• les résultats de surveillance et de mesure des objectifs de sécurité ;
• les dossiers de compétences, de sensibilisation et de formation des personnes concernées ;
• le programme et les rapports d’audit interne, avec le suivi des constats ;
• les comptes rendus de revue de direction et les décisions prises ;
• les non-conformités, analyses de causes et actions correctives ;
• les résultats des évaluations de risques et les validations d’acceptation ;
• les preuves de fonctionnement des mesures retenues dans la déclaration d’applicabilité.

L’audit interne est fréquemment sous-estimé. Un audit de qualité ne consiste pas à cocher que les politiques existent. Il teste l’application des règles sur un échantillon raisonnable : comptes utilisateurs, changements, incidents, sauvegardes, contrats ou revues de fournisseurs. Lorsqu’un écart est relevé, l’organisation doit montrer qu’elle l’a corrigé et qu’elle s’est interrogée sur sa cause.

La revue de direction joue un rôle différent. Elle permet aux dirigeants de prendre des décisions informées sur les risques résiduels, les ressources, les objectifs, les incidents significatifs et les améliorations à engager. Un compte rendu générique, sans décision ni responsable, apporte peu de valeur et peu de réassurance.

Construire un ensemble documentaire qui reste utilisable

Le piège classique consiste à acheter un pack de modèles et à vouloir tout adopter. Ces modèles peuvent accélérer le démarrage, mais ils doivent être adaptés aux pratiques existantes. Une procédure qui ne reflète ni les outils ni les responsabilités réelles devient une dette documentaire.

Commencez par cartographier les documents existants : politiques internes, contrats, rapports de tests, tickets d’incident, tableaux de bord, procédures IT, registres fournisseurs. Souvent, une part importante des preuves existe déjà, mais elle n’est ni gouvernée ni reliée aux exigences ISO 27001. Il faut ensuite définir un propriétaire, une date de révision, un circuit d’approbation et un emplacement de conservation pour chaque document important.

La version 2022 de la norme a renforcé l’attention portée à plusieurs thèmes, notamment le renseignement sur les menaces, la sécurité des services cloud, la préparation aux technologies de l’information et de la communication pour la continuité, ainsi que la prévention des fuites de données. Cela ne signifie pas que chaque organisation doit produire un dossier séparé pour chaque sujet. Elle doit démontrer que ces sujets ont été évalués lorsque leur contexte les rend pertinents.

Un système documentaire bien tenu doit aider les équipes à décider et à agir, pas seulement à réussir l’audit. Si vos documents ne permettent pas de savoir qui accepte un risque, comment un accès est retiré ou quelles mesures protègent une donnée sensible, ils ne remplissent pas leur fonction. La vraie question n’est donc pas « avons-nous tous les fichiers demandés ? », mais : vos preuves permettent-elles à un tiers de comprendre, en peu de temps, comment votre organisation prend et applique ses décisions de sécurité ?

Source : ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection – Information security management systems – Requirements.