Histoire vraie.
Un responsable sécurité que j'ai formé l'année dernière m'a raconté ceci : il était en poste depuis trois mois. Son prédécesseur était parti. La passation de service, c'était un dossier partagé. Dedans : 200 documents, un registre des risques datant de 2022, une politique de sécurité de l'information qui mentionnait GDPR mais pas ISO27001, et une Déclaration d'Applicabilité avec le nom d'une autre entreprise encore visible dans le pied de page.
Son responsable lui a dit : « Nous passons la recertification dans six mois. C'est vous qui pilotez. »
Il a souri. Il a acquiescé. Il est rentré chez lui et a commencé à mettre son LinkedIn à jour.
Si vous avez un jour côtoyé une implémentation ISO27001, une version de cette histoire vous parlera probablement. Peut-être que vous n'avez pas hérité d'un chantier. Peut-être que vous partez de zéro. Mais le sentiment est le même : la norme vous dit ce qui doit exister. Elle ne vous dit jamais comment le construire.
Cet article traite de cet écart. Et de la façon de le combler.
Le document que tout le monde prétend comprendre
ISO/IEC 27001:2022 fait 30 pages. Elle est parfaitement structurée. Les chapitres 4 à 10, l'Annexe A, 93 mesures, 34 sous-clauses obligatoires. Elle se lit comme un ensemble d'instructions claires.
Jusqu'au moment où vous essayez de les suivre.
« L'organisme doit déterminer les enjeux externes et internes pertinents au regard de sa finalité. » Parfait. À quoi cela ressemble-t-il concrètement ? Un atelier ? Une analyse PESTEL ? Une conversation avec le PDG autour d'un café ? La norme ne le dit pas.
« L'organisme doit définir et appliquer un processus d'appréciation du risque de sécurité de l'information. » Très bien. Qualitatif ou quantitatif ? Échelle à trois niveaux ou à cinq ? Comment définir « probable » pour que l'IT et la finance soient d'accord ? Comment éviter que la colonne « propriétaire du risque » n'indique « Dave » pour tout ? La norme ne le dit pas.
« L'organisme doit produire une Déclaration d'Applicabilité. » Excellent. Mais qu'est-ce qu'une bonne DdA ? Quel niveau de détail pour les justifications ? Qu'est-ce qui constitue une preuve de mise en œuvre ? Comment éviter qu'elle ne devienne un tableur de 93 lignes remplies de « Oui, implémenté » sans rien derrière ? La norme ne le dit absolument pas.
Ce n'est pas un défaut. ISO27001 est délibérément neutre sur le plan technologique, sectoriel et organisationnel. Elle doit l'être. Mais cette neutralité crée un écart entre ceux qui comprennent la norme et ceux qui peuvent réellement l'implémenter. Et c'est dans cet écart que les carrières stagnent, que les projets échouent et que les audits déraillent.
Cinq façons dont j'ai vu des implémentations ISO 27001 mourir
J'ai été CISO assez longtemps pour voir les mêmes erreurs se répéter. Non pas parce que les gens font mal leur travail. Parce que personne ne leur a enseigné la méthodologie.
- Le registre des risques qui n'est en réalité qu'un tableur d'opinions.
Tout le monde se retrouve dans une salle. Quelqu'un dit « ransomware » et tout le monde acquiesce. Vraisemblance : élevée. Impact : élevé. Propriétaire du risque : IT. Risque suivant. On répète pendant trois heures. Le résultat est une liste de préoccupations, notées à l'instinct, sans aucune méthodologie documentée derrière. L'auditeur demande « comment avez-vous défini votre échelle d'impact ? » et le silence s'installe.
- La DdA copiée sur internet.
Je n'invente rien. J'ai examiné des Déclarations d'Applicabilité où la colonne des justifications indique « implémenté » pour chaque mesure, la colonne des preuves est vide, et les propriétés du document affichent encore l'auteur original d'une entreprise totalement différente. Votre DdA est le premier arrêt de l'auditeur. Si c'est un copier-coller, l'audit est terminé avant même d'avoir commencé.
- Le SMSI qui vit dans un dossier SharePoint et nulle part ailleurs.
Des politiques que personne n'a lues. Des procédures que personne ne suit. Un inventaire des actifs auquel manquent deux départements. Une revue de direction qui a eu lieu une fois, il y a dix-huit mois, sans aucun suivi. C'est de la conformité sur le papier. Ça coche des cases dans un tableur, mais ça s'effondre dès que quelqu'un demande : « montrez-moi comment ça fonctionne en pratique. »
- L'audit qui prend tout le monde de court.
L'étape 1 est une revue documentaire. L'étape 2 porte sur les preuves opérationnelles. La plupart des équipes se préparent pour l'une et paniquent face à l'autre. Elles ont de beaux documents mais ne peuvent pas démontrer que les mesures fonctionnent. Ou elles ont des mesures opérationnelles mais ne peuvent pas produire la traçabilité des preuves. L'auditeur se moque de savoir quel écart vous avez : les deux sont des non-conformités.
- Le comité de direction qui croit qu'ISO 27001 est un pare-feu.
Vous demandez un budget. Le DAF dit « on a déjà acheté le pare-feu. » Vous essayez d'expliquer qu'ISO 27001 est un système de management, pas un achat technologique. Le DAF regarde son téléphone. C'est un échec d'adhésion du management, et cela tue plus d'implémentations que n'importe quel écart technique.
Ce qui fonctionne réellement
Chaque implémentation ISO 27001 réussie à laquelle j'ai participé repose sur les mêmes ingrédients. Pas de magie. Juste de la méthodologie.
Un domaine d'application clair avec une justification documentée. Pas « tout » sans explication. Pas artificiellement restreint pour éviter la complexité. Un périmètre cohérent pour l'organisation, avec des frontières qu'on peut expliquer à un auditeur en deux minutes.
Une méthodologie d'appréciation des risques reproductible et défendable. Des échelles définies. Des critères calibrés. Une distinction claire entre menaces, vulnérabilités et risques. Des propriétaires qui comprennent réellement ce dont ils sont responsables. Une documentation qu'un auditeur peut suivre sans que vous soyez à côté pour la lui expliquer.
Une DdA qui raconte une histoire. Pas un exercice de cases à cocher. Chaque mesure dispose d'une justification qui renvoie à l'appréciation des risques. Les exclusions sont expliquées, pas laissées vides. Les preuves de mise en œuvre sont référencées, pas supposées.
Un management qui comprend ce qu'il valide. Des revues de direction qui produisent des décisions, pas seulement des comptes rendus. Une politique de sécurité que le PDG a effectivement lue. Une allocation de ressources qui reflète le périmètre du SMSI, pas uniquement le budget IT.
Une préparation à l'audit qui commence le Jour 1, pas la semaine d'avant. Chaque document, chaque enregistrement, chaque processus conçu dès le départ pour produire des preuves. Parce que si vous ne pouvez pas prouver que c'est arrivé, ça n'est pas arrivé.
C'est à ça que servent les 5 jours
Du 11 au 15 mai. En ligne. En anglais. Une cohorte en direct, limitée à 6 participants, construite autour de la méthodologie d'implémentation que j'utilise sur de vrais projets.
Ce n'est pas un parcours commenté de la norme. Vous pouvez lire la norme vous-même. C'est le système d'exploitation qui se trouve derrière : comment initier le projet, comment structurer l'appréciation des risques, comment rédiger la DdA, comment sélectionner et déployer les mesures, comment mettre en place le suivi et la mesure, comment préparer l'audit de certification, le tout étape par étape, avec des exercices et des études de cas à chaque étape.
JourFocusLundiISO 27001 en contexte. Initiation de l'implémentation. Compréhension de l'organisation, de son contexte, des parties intéressées. Définition et justification du périmètre du SMSI.MardiObtenir l'adhésion du management. Analyser l'existant. Rédiger la politique de sécurité. Construire la méthodologie d'appréciation des risques. La Déclaration d'Applicabilité.MercrediSélectionner et concevoir les mesures de l'Annexe A. Déployer des mesures adaptées. Gestion documentaire. Communication, compétences, sensibilisation. Pilotage des opérations de sécurité.JeudiSurveillance et mesure. Audit interne. Revue de direction. Traitement des non-conformités. Amélioration continue. Préparation à l'étape 1 et à l'étape 2.
Le vendredi, vous repartez avec une méthodologie utilisable dès la semaine suivante, et une certification qui l'atteste.
Qui enseigne cette formation
Moi. Christophe Mazzola. CISO en activité, fondateur de Cyber Academy.
Je n'enseigne pas ISO 27001 parce que j'ai lu un livre dessus. Je l'enseigne parce que je l'implémente. Quand je parle d'appréciation des risques, c'est parce que j'ai animé des ateliers dans des salles de réunion. Quand je parle de préparation à l'audit, c'est parce que j'ai préparé des organisations pour l'étape 1 et l'étape 2 et que j'ai observé ce que l'auditeur fait réellement. Quand quelqu'un dans la formation dit « mon registre des risques est un désastre », je ne lui donne pas une réponse théorique. Je lui donne ce que je ferais si j'étais assis à sa place le lundi matin.
C'est la différence entre une formation et un diaporama.
La garantie
Aucune condition au-delà de la complétion du programme et du passage de l'examen. Pas de petits caractères. Nous appelons ça Certifié ou Remboursé, et nous le pensons.
Pourquoi ? Parce que la méthodologie fonctionne. Le taux de réussite le prouve. Et si vous investissez une semaine de votre temps et l'argent de votre entreprise, vous méritez de savoir que le prestataire mise sur le même résultat que vous.
Les détails
Formation : ISO/IEC 27001:2022 Lead Implementer, PECB Certified
Dates : 11–15 mai 2026
Format : En ligne, en direct. Interactif. Non enregistré.
Langue : Anglais
CPD : 31 crédits
Rattrapage gratuit : Dans les 12 mois
À vous de jouer
Si vous êtes en pleine implémentation et que vous êtes bloqué, c'est la formation qui vous débloque.
Si on vous a demandé de piloter un projet et que vous n'avez pas de méthodologie, celle-ci vous en donne une.
Si vous êtes consultant et que vous avez besoin de la certification pour appuyer ce que vous savez déjà, cette formation vous certifie.
Si vous avez hérité d'un dossier SharePoint et d'une prière, voici votre plan de sauvetage en cinq jours.
Des questions ? Écrivez-moi directement. Pas d'équipe commerciale. Pas de chatbot. Juste moi.
Christophe Mazzola
