J’ai bâclé 3 revues de direction ISO 27001 — les 7 étapes qui rendent la quatrième incontestable

La revue de direction est le document que les organisations produisent le plus vite et que les auditeurs lisent le plus lentement. Trois fois, nous avons produit une réunion d’une heure, un compte rendu de deux pages et la conviction d’avoir coché la case. Trois fois, l’auditeur a posé la même question et nous n’avions pas la réponse. Voici la méthode en sept étapes que nous appliquons depuis.

Ce que la clause 9.3 demande réellement

La revue de direction est la réunion périodique par laquelle la direction examine le système de management de la sécurité de l’information pour s’assurer qu’il reste pertinent, adéquat et efficace. La norme en fixe trois choses : le principe, la liste des éléments à examiner, et la nature des décisions qui doivent en sortir.

Les sept entrées attendues sont les suivantes :

• l’état des actions décidées lors des revues précédentes ;
• les changements des enjeux externes et internes pertinents pour le système ;
• les changements des besoins et attentes des parties intéressées ;
• les retours sur la performance de la sécurité : non-conformités et actions correctives, résultats de surveillance et de mesure, résultats d’audit, atteinte des objectifs ;
• les retours des parties intéressées ;
• les résultats de l’appréciation des risques et l’état du plan de traitement ;
• les opportunités d’amélioration continue.

Et les sorties attendues tiennent en une phrase : des décisions relatives aux opportunités d’amélioration continue et aux éventuels changements à apporter au système.

Le malentendu fondamental est là. Beaucoup d’organisations traitent la revue comme un exercice de reporting : on présente ce qui s’est passé, la direction écoute, on archive. La norme attend un exercice de décision. Une revue qui ne produit aucune décision n’a pas rempli son objet, même si les sept entrées ont été scrupuleusement présentées.

Étape 1 — Convoquer les personnes qui peuvent engager des ressources

C’est l’étape que nous avons ratée trois fois de suite, et elle rend toutes les suivantes inutiles.

Une revue tenue par le responsable de la sécurité, le directeur informatique et deux ingénieurs n’est pas une revue de direction. C’est une réunion technique avec un mauvais titre. La distinction n’est pas protocolaire : elle détermine si la réunion peut produire des décisions ou seulement des constats.

La règle pratique tient en une question : quelqu’un dans la salle peut-il décider d’affecter un budget ou une personne ? Si la réponse est non, reportez la réunion. Une revue tenue sans décideur produira une liste d’actions que personne n’a le pouvoir de lancer, et vous relirez la même liste l’année suivante.

Un auditeur consulte la liste des présents avant de lire le document. C’est le contrôle le plus rapide dont il dispose pour savoir si le système est porté par l’organisation ou par une seule personne.

Étape 2 — Reprendre l’état des décisions précédentes, en premier

C’est la première entrée listée par la norme, et c’est aussi le motif d’écart le plus fréquent que nous rencontrons sur cette clause.

Le scénario classique : la revue de l’année N décide de six actions. La revue de l’année N+1 présente une nouvelle situation, de nouveaux indicateurs, de nouvelles actions — sans jamais dire ce que sont devenues les six précédentes. Le système n’a alors aucune mémoire, et l’amélioration continue exigée par la norme devient littéralement invisible.

Le format qui fonctionne est un tableau de quatre colonnes, présenté en ouverture : l’action, son responsable, son état, et — colonne décisive — la raison si elle n’a pas été menée.

Cette dernière colonne est inconfortable et c’est exactement pour cela qu’elle est utile. Trois actions non réalisées pour cause de manque de moyens racontent quelque chose de bien plus important sur votre système que n’importe quel indicateur : elles disent que la direction décide des actions qu’elle ne finance pas.

Étape 3 — Documenter les changements de contexte et de parties intéressées

Deux entrées de la norme, une seule préparation. La question à laquelle il faut répondre est : qu’est-ce qui a changé autour du périmètre depuis la dernière revue ?

• Changements internes : nouveaux services, nouveaux sites, croissance des effectifs, migration d’un système majeur, externalisation d’une fonction.
• Changements externes : nouvelles obligations réglementaires applicables, évolution de la menace sur votre secteur, incidents survenus chez des acteurs comparables.
• Changements de parties intéressées : nouveaux clients imposant des exigences contractuelles de sécurité, nouveaux fournisseurs critiques, nouvelles attentes d’un assureur.

Cette étape se prépare en une heure et évite l’écart le plus embarrassant qui soit : un périmètre certifié qui ne correspond plus à l’organisation réelle. Une entreprise qui a ouvert un site ou externalisé son hébergement sans que le périmètre ait été revu se présente à l’audit avec un système qui décrit une organisation disparue.

Étape 4 — Présenter la performance avec des chiffres, pas des adjectifs

C’est l’entrée la plus fournie de la norme et la plus mal traitée en pratique. Elle recouvre quatre éléments distincts : les non-conformités et actions correctives, les résultats de surveillance et de mesure, les résultats d’audit, et l’atteinte des objectifs de sécurité.

Le piège est le vocabulaire. « La situation s’améliore », « le niveau reste satisfaisant », « les équipes sont mobilisées » : ces formulations ne permettent aucune comparaison d’une année sur l’autre, et un auditeur les traite comme du silence.

Cinq à huit chiffres suffisent, à condition qu’ils soient identiques d’une revue à l’autre :

• nombre d’incidents de sécurité qualifiés sur la période, et délai médian de traitement ;
• nombre de non-conformités ouvertes, fermées, en retard ;
• couverture des correctifs sur les actifs exposés, en pourcentage ;
• taux de réalisation des actions de sensibilisation ;
• état d’avancement du plan de traitement des risques ;
• nombre de fournisseurs critiques évalués sur la période.

La valeur absolue de ces chiffres importe moins que leur évolution. Un indicateur qui se dégrade et qui est présenté comme tel, avec une décision associée, vaut infiniment mieux qu’un tableau entièrement vert que personne ne croit.

Étape 5 — Réexaminer l’appréciation des risques et le plan de traitement

C’est l’étape qui déclenche les vraies décisions, parce qu’elle confronte ce que la direction a accepté l’an dernier à ce qui s’est effectivement produit.

Trois questions, posées explicitement :

• Quels risques ont changé de niveau, et pourquoi ? Un risque qui monte parce que la menace a évolué ne se traite pas comme un risque qui monte parce que le système a changé.
• Quels risques acceptés se sont-ils matérialisés ? C’est la question la plus utile de toute la revue, et presque personne ne la pose. Une acceptation qui se réalise n’est pas un échec, mais elle doit être reconsidérée explicitement.
• Où en est le plan de traitement ? Non pas « en cours », mais : combien de mesures prévues, combien mises en œuvre, combien en retard et de combien.

C’est aussi le moment où la déclaration d’applicabilité doit être confrontée à la réalité : une mesure déclarée incluse mais toujours « planifiée » depuis deux revues n’est plus une mesure planifiée, c’est une mesure abandonnée qui s’ignore. Notre méthode de rédaction de ce document est détaillée dans la déclaration d’applicabilité en 7 étapes.

Étape 6 — Faire arbitrer les améliorations, avec un budget

La dernière entrée de la norme — les opportunités d’amélioration continue — est celle qui produit le plus de texte et le moins d’effet.

La raison est simple : une amélioration listée sans ressource affectée n’est pas une décision, c’est une intention. Et les intentions se recopient d’une revue à l’autre sans coût apparent, jusqu’au jour où un auditeur remarque que les mêmes trois lignes figurent dans les trois derniers relevés.

Le format qui force l’arbitrage : présenter au maximum cinq améliorations, chacune avec son coût estimé et le risque qu’elle réduit, puis demander à la direction de choisir celles qui sont financées. Celles qui ne le sont pas sortent de la liste et sont enregistrées comme écartées, avec la raison.

Un refus explicite est un excellent résultat de revue de direction. Il prouve que l’organe de direction a examiné et arbitré, ce qui est précisément ce que la norme lui demande de faire.

Étape 7 — Écrire le relevé de décisions le jour même

Trois colonnes, rédigées avant la fin de la séance : action, responsable nommé, échéance datée.

« L’équipe informatique » n’est pas un responsable. « Courant 2027 » n’est pas une échéance. Une décision qui ne désigne personne ne sera portée par personne, et vous la relirez à l’identique à l’étape 2 de la prochaine revue.

Le relevé doit également porter la trace que chacune des sept entrées a été examinée, y compris celles sans matière. Une ligne suffit : « Retours des parties intéressées : aucun retour formel sur la période. » C’est une réponse valable. L’omission, en revanche, se voit immédiatement.

Enfin : datez, versionnez, faites approuver. Un relevé non daté ne prouve rien, parce qu’on ne sait pas à quelle période ni à quel périmètre il correspond.

Articulation avec NIS2

NIS2 n’exige ni revue de direction ni certification ISO 27001. Elle impose des mesures de gestion des risques et — c’est le point décisif ici — elle fait peser sur les organes de direction une responsabilité explicite en matière d’approbation et de supervision de ces mesures.

Or c’est exactement ce que produit une revue de direction correctement tenue : une trace datée, signée, montrant que la direction a examiné le niveau de risque et arbitré. En pratique, un seul point supplémentaire à l’ordre du jour — les obligations de notification et leurs délais, que la clause 9.3 ne couvre pas — suffit pour que le même document serve les deux cadres.

Pour délimiter ce qui vous concerne effectivement, notre page audit de périmètre NIS2 pose les questions dans l’ordre. Sur le volet technique des décisions qui sortent de ce type de revue, les sujets de dépendances et de chaîne de production sont documentés côté écosystème open source, et les questions d’outillage et d’automatisation côté Plug-Tech.

Les trois erreurs que nous avons commises

Tenir la revue sans décideur. Nos deux premières revues réunissaient les bonnes compétences et aucun pouvoir d’engagement. Elles ont produit d’excellents constats et zéro décision.

Préparer la veille. La troisième a été préparée en une soirée. Les chiffres n’étaient pas comparables à ceux de l’année précédente, ce qui a rendu toute la partie performance inexploitable — et transformé une clause centrale en formalité.

Confondre compte rendu et relevé de décisions. Nous rédigions un récit de la réunion. L’auditeur cherchait un tableau. Un récit ne permet pas de vérifier qu’une action a été menée ; un tableau, si.

Questions fréquentes