Mise à jour du 11 septembre 2026 : ce guide précise la portée du certificat et sa distinction avec NIS2. Les anciennes fourchettes génériques de coût et de délai ont été retirées faute de justification adaptée à chaque projet.
Une certification ISO 27001 atteste la conformité d’un système de management de la sécurité de l’information à un référentiel, dans un périmètre défini. Pour préparer votre entreprise, commencez par ce périmètre et par les décisions qui organisent réellement la sécurité. Acheter une bibliothèque de procédures ou afficher un objectif de certification ne démontre pas que les pratiques fonctionnent.
Ce guide vous aide à structurer le dossier : activités concernées, responsabilités, traitement des risques, preuves, audit et budget. Les exemples sont des situations fictives destinées à expliquer la méthode, sans résultat attribué à un client. Ils ne remplacent pas le texte complet de la norme ni l’examen de vos obligations sectorielles. L’objectif est de préparer des questions vérifiables avant de vous engager dans un calendrier de certification.
Comprendre la portée du SMSI et du certificat
Un système de management de la sécurité de l’information, ou SMSI, organise la manière de piloter les risques concernant l’information. Il relie des objectifs, des responsabilités, des pratiques et leur évaluation. La présentation officielle d’ISO/IEC 27001 couvre la mise en place, le maintien et l’amélioration de ce système. Elle concerne des organisations de tailles et de secteurs différents, pas uniquement les entreprises informatiques.
La confidentialité, l’intégrité et la disponibilité permettent de formuler le besoin. Qui doit pouvoir consulter une information ? Comment éviter sa modification indue ? Quand doit-elle être accessible pour l’activité ? Ces questions s’appliquent aussi aux échanges humains et aux documents physiques. Un SMSI ne se résume donc pas à installer des outils de protection sur un réseau.
Lisez toujours le certificat avec son périmètre. Une activité d’exploitation peut être couverte alors qu’un autre service du groupe ne l’est pas. Le nom d’une entreprise sur un document ne permet pas de conclure que toutes ses filiales, toutes ses applications et tous ses produits sont certifiés. Pour un achat, demandez si la prestation que vous utiliserez entre effectivement dans le champ annoncé.
Le certificat ne prouve pas l’absence de vulnérabilité ou l’impossibilité d’un incident. Il constitue un élément de confiance à examiner avec les autres informations nécessaires à votre décision. Évitez également d’assimiler le certificat d’un hébergeur à celui de votre propre organisation : l’usage de son infrastructure ne transfère pas automatiquement sa certification à votre application ni à vos processus.
Vérifier le référentiel avant de lancer le projet
Au moment de cette révision, la fiche ISO présente l’édition ISO/IEC 27001:2022 et signale un amendement de 2024 consacré au changement climatique. Il ne s’agit pas d’une « version 2026 » créée parce que le guide est mis à jour cette année. Demandez au certificateur de préciser la référence applicable à votre démarche, y compris les amendements, et utilisez cette même référence dans le dossier.
ISO/IEC 27001 et ISO/IEC 27002 ont des fonctions différentes. La première définit les exigences du système de management ; la seconde fournit un ensemble de mesures de sécurité accompagné de conseils de mise en œuvre. Une lecture technique de mesures ne suffit pas à montrer comment la direction choisit les priorités, attribue les moyens et suit les résultats.
Disposez d’un accès légitime à la documentation nécessaire. Une fiche publique et un article pédagogique peuvent aider au cadrage, mais ne donnent pas toutes les exigences ni toutes leurs conditions. Ne constituez pas votre dossier à partir d’extraits anonymes ou de listes dont l’édition n’est pas identifiable. Cette vérification documentaire évite de résoudre un problème de rédaction qui provient en réalité d’une mauvaise référence.
Précisez enfin ce que vous cherchez à obtenir. Mettre en place une démarche inspirée d’un référentiel et demander une certification par un tiers sont deux décisions distinctes. Si un client exige un certificat, demandez la formulation exacte de son attente. Vous saurez ainsi si votre projet répond à la demande, sans promettre une reconnaissance que le client n’a pas confirmée.
Définir un périmètre utile sans masquer les dépendances
Le périmètre doit être compréhensible par une personne extérieure. Décrivez l’activité concernée, les sites, les équipes et les informations traitées. Une formule comme « sécurité informatique de l’entreprise » laisse trop de questions ouvertes. Une description opérationnelle indique ce qui est fourni, à qui, avec quels principaux systèmes et quelles responsabilités. Elle rend aussi les exclusions plus visibles.
Prenons un exemple fictif : une entreprise veut couvrir l’exploitation d’une plateforme de réservation. Elle doit examiner les personnes qui l’administrent, les comptes utilisés, les fournisseurs qui l’hébergent et les processus qui permettent de la maintenir. Exclure le service de développement ne supprime pas les risques liés aux changements logiciels livrés par ce service. Les interfaces entre activités doivent rester explicites.
Un périmètre ciblé peut faciliter le pilotage, mais il n’est pas toujours préférable à un périmètre large. Il doit correspondre à l’objectif et ne pas créer une impression trompeuse auprès des clients. Avant de le retenir, vérifiez les contrats, les dépendances partagées et les systèmes auxquels vous ne pouvez pas attribuer une responsabilité claire. Ces difficultés doivent être résolues ou documentées, pas simplement sorties du dessin.
Conservez une version datée du périmètre et identifiez qui approuve ses changements. Une acquisition, un nouveau site ou un nouveau fournisseur peuvent modifier les hypothèses. Lorsqu’un changement survient, examinez son effet sur les risques, les responsabilités et la portée du certificat envisagé. Vous éviterez de piloter une organisation réelle avec une description devenue historique.
Répartir les responsabilités et les moyens
La sécurité ne peut pas être portée uniquement par la personne qui rédige le dossier. Identifiez le responsable de chaque décision : validation d’une priorité, allocation d’un budget, acceptation d’un risque et suivi d’une action. Le rôle de coordination peut revenir au responsable de la sécurité des systèmes d’information, le RSSI, sans lui transférer toutes les décisions métier.
Une répartition utile indique aussi qui exécute et qui vérifie. Pour une revue des accès, la personne qui extrait une liste de comptes n’est pas nécessairement celle qui sait si chaque accès reste justifié. Le responsable métier apporte cette appréciation ; une autre fonction peut effectuer la modification technique. Si personne ne se reconnaît dans une étape, la procédure restera difficile à appliquer.
Préparez un calendrier compatible avec les disponibilités réelles. Les réunions, les corrections et la collecte de preuves demandent du temps aux équipes déjà chargées de l’exploitation. Écrivez les arbitrages nécessaires plutôt que de supposer que le projet sera absorbé sans effet sur le reste du travail. Un engagement ne devient crédible que lorsque les personnes disposent des moyens de le tenir.
La documentation peut rester simple si elle permet de retrouver les décisions. Pour chaque action, indiquez son responsable, son objectif, l’échéance choisie et la preuve attendue. Prévoyez comment signaler un retard et qui peut arbitrer. Cette organisation est une méthode pratique de suivi, pas un modèle de tableau imposé par la norme à toutes les entreprises.
Relier les risques aux mesures retenues
Une analyse de risque doit aider à choisir ce que vous allez traiter. Elle perd son utilité si elle se limite à une liste de menaces recopiée. Décrivez les informations et activités à protéger, les événements redoutés et les conséquences pour votre organisation. Demandez aux métiers ce qui rendrait une interruption ou une divulgation particulièrement dommageable dans leur contexte.
L’ANSSI propose la méthode EBIOS Risk Manager et des supports pour structurer cette réflexion collaborative. Notre guide des ateliers EBIOS RM détaille leur déroulement. Ici, le point décisif est la traçabilité entre un risque, une décision et une action ; la certification ne doit pas être présentée comme imposant exclusivement cette méthode.
Dans un second exemple fictif, un prestataire conserve un accès administrateur après la fin de sa mission. Le risque ne se traite pas seulement en ajoutant le mot « contrôle » à une procédure. Vous devez savoir qui connaît la date de fin, qui demande la suppression, qui l’exécute et comment elle est vérifiée. La mesure technique dépend d’un signal organisationnel fiable.
Documentez également ce qui reste incertain. Une information manquante sur un fournisseur peut nécessiter une vérification avant de décider. Un risque accepté doit correspondre à une décision identifiée, prise par la personne habilitée dans votre organisation. Ne remplacez pas cette décision par une case verte destinée à rendre le tableau plus rassurant.
Préparer une déclaration d’applicabilité explicable
La déclaration d’applicabilité, souvent appelée SoA pour Statement of Applicability, relie les mesures de sécurité aux choix de votre SMSI. Elle doit pouvoir être lue avec les résultats de l’analyse et le traitement des risques. Le but n’est pas de produire un document indépendant que personne ne sait rapprocher des pratiques réellement mises en place.
Pour préparer ce travail, demandez pour chaque mesure retenue : pourquoi est-elle nécessaire, comment est-elle mise en œuvre et où en vérifier le fonctionnement ? Une justification peut tenir compte du risque mais aussi d’un engagement contractuel ou d’une exigence applicable. L’absence d’un risque décrit dans votre tableau ne suffit donc pas, à elle seule, à justifier mécaniquement une exclusion.
L’annexe A constitue une référence à examiner dans le cadre de la démarche. Elle ne doit pas devenir une limite artificielle qui empêcherait de retenir une mesure nécessaire à votre situation. Consultez les exigences complètes pour formaliser la déclaration, puis vérifiez sa cohérence avec les actions suivies. Un résumé public ne remplace pas ce contrôle de conformité documentaire.
Évitez les statuts ambigus comme « partiellement fait » sans explication. Distinguez une pratique en fonctionnement, une mesure décidée mais non déployée et un point restant à analyser. Indiquez le document ou l’équipe permettant de vérifier l’état annoncé. Cette précision facilite une discussion utile avec les responsables et réduit les malentendus lors de la préparation de l’audit.
Constituer des preuves de fonctionnement proportionnées
Une preuve doit répondre à une question précise. Pour une revue des accès, une liste de comptes montre ce qui existe ; elle ne démontre pas, à elle seule, qu’une personne a évalué leur justification. Un compte rendu de décision, les modifications demandées et leur suivi permettent de comprendre le travail effectué. Choisissez les éléments qui rendent la séquence vérifiable sans accumuler des fichiers inutiles.
Les sauvegardes offrent un autre exemple. Un message indiquant qu’une copie s’est terminée ne prouve pas que la restauration répond au besoin métier. Si vous avez prévu un exercice, conservez son objectif, les conditions retenues, le résultat et les écarts observés. Le guide de gestion de crise et de continuité traite les étapes voisines, sans que cet exemple constitue un programme d’essai universel.
Ne fabriquez pas rétrospectivement un historique de fonctionnement. Si une activité vient de commencer, indiquez sa date réelle et les observations disponibles. Un modèle de compte rendu peut aider à organiser les prochaines revues ; il ne doit pas être rempli comme si des réunions avaient eu lieu. L’absence de preuve est un constat à traiter, pas une invitation à inventer une trace.
Organisez enfin l’accès aux pièces sensibles. Un dossier de préparation peut contenir des informations sur l’architecture, les incidents ou les personnes. Partagez uniquement ce qui est nécessaire avec les interlocuteurs autorisés et convenez des modalités d’échange. Un audit de sécurité ne justifie pas la diffusion générale de secrets, d’identifiants ou de copies non maîtrisées de données de production.
Une preuve a également une durée d’utilité. Identifiez sa date, le périmètre observé et les changements intervenus depuis. Une ancienne revue peut montrer qu’un processus a fonctionné, mais ne décrit pas forcément les accès actuels après une réorganisation. Pour chaque décision importante, demandez si les éléments disponibles sont encore pertinents. Vous pourrez alors actualiser ce qui compte, au lieu de collecter systématiquement une nouvelle copie de tous les documents.
Utiliser l’audit interne pour améliorer le dispositif
L’audit interne sert à examiner le système au regard des critères retenus et à identifier les écarts. Préparez son périmètre, les sujets à examiner et les personnes concernées. Cherchez une appréciation suffisamment objective du travail réalisé. Le simple fait que le rédacteur d’une procédure la relise ne constitue pas forcément un examen adapté de son application.
Suivez un petit nombre de situations jusqu’au bout : une arrivée ou un départ, une modification importante, une décision de traitement du risque. Comparez ce qui était prévu avec ce qui s’est passé. Si une étape manque, recherchez la cause : responsabilité floue, outil inaccessible, consigne incomprise ou charge de travail sous-estimée. Une correction durable traite cette cause, pas seulement le document où l’écart apparaît.
La revue de direction permet ensuite de présenter les résultats et les décisions attendues. Préparez les actions en retard, les évolutions du contexte et les ressources nécessaires. N’en faites pas une simple signature ajoutée au dossier. Les arbitrages doivent être compréhensibles et leur suite suivie, notamment lorsque la direction choisit de reporter une action ou de modifier une priorité.
Pour le suivi technique, notre guide de gestion des vulnérabilités développe la priorisation des corrections. Dans le SMSI, examinez surtout la manière dont les décisions sont prises et vérifiées. Une liste de failles corrigées peut apporter une preuve, mais ne démontre pas automatiquement que tout le système de management fonctionne.
Choisir le certificateur et préparer l’audit externe
ISO explique qu’elle ne réalise pas elle-même les certifications. L’organisme certificateur conduit le processus et prend la décision selon ses règles. L’accréditation est une reconnaissance distincte de compétence pour une portée donnée. Vérifiez cette portée auprès de l’organisme d’accréditation concerné et demandez les références nécessaires, plutôt que de vous fier à un logo isolé.
La présentation d’AFNOR Certification distingue une étape préparatoire documentaire, puis un audit initial examinant les pratiques et les preuves. Elle sépare également l’audit de la décision de certification. Utilisez cette description pour comprendre le déroulement général, puis faites préciser le programme, les pièces attendues et les modalités exactes de votre propre contrat.
Avant l’intervention, désignez les interlocuteurs capables d’expliquer chaque activité. Ils doivent connaître leur travail, pas mémoriser une réponse écrite pour l’occasion. Vérifiez l’accès aux documents et la disponibilité des personnes sans modifier artificiellement les pratiques pour la seule journée d’audit. Une question non résolue doit pouvoir être reconnue et suivie.
En présence d’un écart, demandez sa formulation précise et les suites attendues. Les modalités de réponse, les délais et l’évaluation de la correction doivent être compris avec le certificateur. Ne supposez pas qu’envoyer un plan d’action suffit dans tous les cas. Une proposition commerciale, un audit réservé ou une appréciation orale favorable ne constituent pas un certificat délivré.
À la réception du certificat, relisez le nom de l’entité, la référence, le périmètre et les dates avant de le transmettre à un client. Vérifiez que la description correspond au service présenté dans vos documents commerciaux. Si une formulation laisse penser qu’un produit est lui-même certifié alors que seul le système de management est concerné, corrigez cette formulation. La communication doit rester fidèle à ce qui a été évalué.
Préparez aussi une réponse pour les demandes de pièces complémentaires. Un client peut vouloir comprendre une limite de périmètre ou le traitement d’une dépendance particulière. Le certificat ne répond pas à toutes ces questions. Déterminez ce que vous pouvez communiquer, sous quelles conditions et avec quelle validation interne. Refuser de diffuser une pièce sensible n’oblige pas à rester vague : vous pouvez expliquer sa portée et proposer un échange adapté.
Budgéter le projet sans promettre un délai universel
Séparez le coût du processus de certification de celui de la préparation. L’audit externe est une prestation ; les changements nécessaires dans l’organisation peuvent mobiliser d’autres budgets. L’accompagnement éventuel, la documentation, la formation, les outils et le temps interne doivent être identifiés. Une somme globale sans périmètre empêche de comparer des propositions qui n’incluent pas les mêmes tâches.
Demandez un devis construit sur les activités, sites et effectifs concernés, ainsi que sur la complexité du système. Faites préciser les déplacements, les interventions complémentaires, la surveillance et le renouvellement. Si un consultant vous accompagne, distinguez ses livrables des responsabilités qui restent dans votre entreprise. Aucun accompagnement ne peut remplacer les décisions de la direction ni garantir le résultat de l’audit.
Le calendrier dépend aussi des écarts à traiter et des observations à constituer. Une équipe déjà organisée ne part pas de la même situation qu’une entreprise qui découvre ses dépendances. Plutôt que d’annoncer un nombre de mois universel, identifiez les conditions nécessaires avant l’audit : périmètre stabilisé, responsabilités attribuées, pratiques opérationnelles et points ouverts traités selon leur importance.
Conservez une marge pour les corrections sans inventer un taux standard d’imprévu. Si un client attend une certification à une date donnée, présentez-lui honnêtement l’état du projet et les étapes restantes. Ne remplacez pas un certificat encore absent par une formulation ambiguë comme « certification en cours » sans expliquer ce que cette expression recouvre réellement.
Distinguer ISO 27001 des exigences NIS2
L’ANSSI indique explicitement que la certification ISO 27001 ne vaut pas, à elle seule, conformité à NIS2. Les démarches poursuivent des objectifs différents. Votre organisation doit examiner séparément son assujettissement, les exigences qui lui sont applicables et les systèmes concernés. Un périmètre de certification volontaire ne décide pas du champ d’une obligation réglementaire.
Vous pouvez rapprocher des travaux lorsqu’ils concernent les mêmes pratiques, mais chaque correspondance doit être justifiée. Pour une exigence donnée, identifiez la preuve déjà disponible, son périmètre et ce qu’elle ne couvre pas. La présence d’une politique générale ne démontre pas automatiquement que toutes les attentes particulières sont satisfaites. Gardez une colonne pour les compléments nécessaires et leur propriétaire.
La même prudence s’applique aux autres cadres. Une certification de système de management ne doit pas être confondue avec une qualification d’offre ou une conformité juridique générale. Pour les prestations cloud, le guide consacré à SecNumCloud traite une autre démarche. Avant d’utiliser une attestation dans un contrat, vérifiez l’objet exact que le client demande de justifier.
Maintenir le SMSI après la décision
Le fonctionnement du SMSI se poursuit après la délivrance du certificat. AFNOR Certification décrit un cycle avec suivi annuel et renouvellement tous les trois ans. Vérifiez les conditions de votre certificat, son statut et les obligations de signalement des changements. Une date de validité imprimée ne suffit pas à conclure qu’un document n’a jamais été suspendu ou retiré.
Lorsqu’un nouveau service, un fournisseur ou une organisation de travail apparaît, reprenez les décisions concernées. Le but n’est pas de réécrire tout le dossier à chaque événement, mais de maintenir un lien fiable entre la réalité et les documents. Les incidents et les écarts constituent aussi des informations pour réexaminer les mesures et leurs priorités.
Pour démarrer, réunissez le responsable du projet et les métiers autour de trois documents : une description de périmètre, une liste de responsabilités et un état des preuves disponibles. Le glossaire cybersécurité aide à clarifier les termes avant cette réunion. À partir des informations manquantes, attribuez les vérifications et sollicitez les précisions du certificateur. Vous disposerez d’un dossier de décision explicable, plutôt que d’un objectif de certification détaché du fonctionnement de l’entreprise.