Planification et risques

Pourquoi la clause 6 est le pivot du SMSI

La clause 4 pose le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, la clause 5 formalise l'engagement de la direction. Mais c'est la clause 6, « Planification », qui transforme la norme en système réellement opérationnel. Elle impose une méthode d'appréciation des risques (6.1.2), un plan de traitement (6.1.3) et des objectifs mesurables (6.2). Sans cette clause, un SMSI reste un empilement de politiques déclaratives sans mécanisme de priorisation ni de décision.

En audit de certification, la clause 6 concentre une part disproportionnée du temps de l'auditeur, parce qu'elle est la charnière entre l'analyse (ce qui menace l'organisme) et l'action (ce qui est réellement mis en œuvre). L'auditeur vérifie la cohérence d'une chaîne complète : appréciation des risques → traitement → Déclaration d'Applicabilité → contrôles Annexe A effectivement en place. Une rupture n'importe où dans cette chaîne — un risque sans traitement documenté, un contrôle justifié dans la SoA mais absent en pratique — figure parmi les non-conformités les plus fréquemment relevées lors des audits initiaux.

La clause 6 ne demande pas une méthodologie précise, contrairement à une idée reçue héritée de la version 2005 de la norme. Elle exige seulement que la méthode choisie soit documentée, cohérente, reproductible et comparable dans le temps. C'est cette cohérence, pas la sophistication du calcul, que l'auditeur évalue en premier.

Le cycle d'appréciation des risques (6.1.2)

Deux familles de méthodes coexistent en pratique, et le choix entre elles dépend surtout de la taille du périmètre et de la maturité de l'organisme.

• Approche par actifs, héritée de l'ISO 27005:2011 : on inventorie les actifs informationnels, on leur associe des menaces et des vulnérabilités, puis on calcule un niveau de risque par triplet actif/menace/vulnérabilité. Exhaustive, elle devient vite lourde sur un périmètre large ou évolutif.
• Approche par scénarios, favorisée par l'ISO 27005:2022 : on part de scénarios de risque métier plausibles — par exemple « exfiltration de la base clients via un compte administrateur compromis » — et on évalue directement leur vraisemblance et leur impact. Plus rapide à dérouler, elle exige une bonne connaissance du métier pour ne pas passer à côté d'un scénario significatif.

Quelle que soit l'approche retenue, quatre éléments doivent être fixés avant toute évaluation :

1. Les critères d'acceptation du risque — le seuil au-delà duquel un risque doit obligatoirement faire l'objet d'un traitement.
2. Les critères d'appréciation — l'échelle de vraisemblance et d'impact, et la façon de les combiner (matrice, somme pondérée, score composite).
3. Les propriétaires de risque (risk owners) — la clause 6.1.2 exige nommément l'identification d'une personne responsable, capable d'accepter formellement un niveau de risque résiduel.
4. La reproductibilité — deux évaluations menées à des moments différents, par des personnes différentes, doivent produire des résultats comparables sur un même scénario.

Le piège le plus fréquent en audit : une méthodologie décrite dans un document mais jamais appliquée telle quelle sur le terrain. Si le document annonce une échelle de 1 à 5 sur la vraisemblance et que le registre de risques ne contient que des appréciations qualitatives (« faible », « fort »), l'auditeur note l'incohérence — non-conformité mineure isolée, ou majeure si elle est systématique sur l'ensemble du registre.

Matrice de risque et priorisation

La matrice de risque croise vraisemblance et impact pour attribuer à chaque scénario un niveau qui détermine le traitement attendu. Une échelle à cinq niveaux sur chaque axe est un bon compromis : assez fine pour prioriser efficacement, assez grossière pour rester explicable en comité de direction sans donner une illusion de précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire quantitative.

Évitez les matrices trop fines (7×7, 10×10). Elles donnent une illusion de précision quantitative alors que les entrées — vraisemblance et impact — restent des estimations qualitatives d'experts. Une fausse précision complique la communication avec la direction sans améliorer la qualité de la décision.

Traitement des risques (6.1.3)

Pour chaque risque dépassant le seuil d'acceptation, quatre options de traitement sont possibles.

Le résultat de cette étape est le plan de traitement des risques (Risk Treatment Plan, RTP) : pour chaque risque traité, il documente le contrôle retenu, le responsable de sa mise en œuvre, l'échéance et l'état d'avancement. C'est un document vivant, revu à chaque comité de pilotage du SMSI — pas un artefact figé produit une seule fois pour l'audit.

Une PME de développement logiciel identifie le risque « compromission du poste d'un développeur ayant accès au code source et aux secrets de déploiement ». Vraisemblance évaluée à 3/5 — le phishing ciblé est plausible dans le secteur — impact à 4/5, une compromission pouvant atteindre la chaîne de livraison. Traitement retenu : déploiement d'un EDR sur tous les postes de développement, rotation automatique des secrets exposés, séparation stricte des environnements CI. Le risque résiduel, réévalué après mise en œuvre, redescend à 2/5 et est accepté formellement par le RSSI, propriétaire désigné du risque.

Un arbitrage coût/bénéfice accompagne systématiquement le choix du traitement : un contrôle dont le coût de mise en œuvre dépasse la perte espérée en cas de matérialisation du risque n'est pas nécessairement pertinent, sauf si une exigence légale ou contractuelle l'impose indépendamment du calcul économique.

La Déclaration d'Applicabilité (SoA)

La Statement of Applicability est le document charnière entre l'appréciation des risques et l'Annexe A de la norme. Pour chacun des 93 contrôles de l'Annexe A, édition 2022, répartis en quatre thèmes — organisationnels (37), personnes (8), physiques (14), technologiques (34) — la SoA doit indiquer :

• si le contrôle est applicable ou exclu, avec justification dans les deux cas ;
• s'il est déjà mis en œuvre, partiellement mis en œuvre, ou planifié ;
• la justification de sélection, généralement le ou les risques qui motivent son inclusion.

Exclure un contrôle de l'Annexe A est parfaitement légitime — la norme ne demande pas d'appliquer les 93 contrôles intégralement — mais l'exclusion doit reposer sur l'absence de risque correspondant, jamais sur la difficulté ou le coût de mise en œuvre. « Trop coûteux à déployer » n'est pas une justification d'exclusion recevable en audit ; c'est un argument pour un traitement différé, documenté dans le RTP avec une échéance, pas pour une exclusion de la SoA.

Le passage de l'édition 2013 — 114 contrôles répartis en 14 catégories — à l'édition 2022 a fusionné plusieurs contrôles et introduit 11 contrôles nouveaux, dont la threat intelligence, la sécurité du cloud, la suppression des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire et le masquage de données. Les organismes encore certifiés sur la version 2013 doivent avoir migré leur SoA avant la fin de la période de transition fixée par leur organisme de certification.

Objectifs de sécurité (clause 6.2)

La clause 6.2 exige que l'organisme établisse des objectifs de sécurité de l'information aux fonctions et niveaux pertinents. Ces objectifs doivent être :

• cohérents avec la politique de sécurité définie en clause 5.2 ;
• mesurables, chaque fois que c'est réalisable ;
• communiqués et mis à jour ;
• assortis de ressources, de responsables, d'échéances et de critères d'évaluation des résultats.

La confusion la plus fréquente consiste à assimiler objectifs de sécurité et indicateurs de conformité. Un objectif du type « réduire de 30 % le délai moyen de correction des vulnérabilités critiques d'ici la fin de l'exercice » est un objectif de clause 6.2 valide. « Être certifié ISO 27001 » n'en est pas un : c'est un objectif de programme, pas un objectif de sécurité mesurable au sens de la clause.

Fréquence de réévaluation et déclencheurs

Le registre de risques n'est pas un document figé produit pour l'audit initial. La norme attend une revue au moins annuelle, complétée par une réévaluation systématique après tout changement significatif : mise en production d'une nouvelle application, changement de sous-traitant critique, incident de sécurité majeur, évolution réglementaire (par exemple l'entrée en vigueur de NIS2 pour un secteur donné), ou modification substantielle du périmètre défini en clause 4.3.

En pratique, les organismes matures distinguent deux rythmes : une revue de fond, annuelle, qui reconsidère l'ensemble du registre et de la méthodologie, et des revues ponctuelles déclenchées par un événement précis, qui ne portent que sur les risques concernés par ce changement. Cette distinction évite à la fois l'écueil du registre jamais révisé et celui de la révision permanente qui dilue la gouvernance.

Outils et gouvernance du registre

La tenue du registre de risques, du RTP et de la SoA dans trois fichiers bureautiques disjoints est la principale cause d'incohérence constatée en audit : un risque mis à jour dans un tableur n'est pas répercuté dans le document Word de la SoA, et l'écart n'est découvert que le jour de l'audit. Trois approches coexistent selon la maturité de l'organisme :

• Tableur structuré unique, avec un identifiant de risque commun aux trois vues (registre, RTP, SoA), suffisant pour un périmètre restreint et une équipe de moins d'une dizaine de contributeurs.
• Outil GRC dédié (Governance, Risk & Compliance), qui impose une structure de données relationnelle entre risques, contrôles et objectifs, et facilite les rapports pour la revue de direction.
• Modules intégrés aux plateformes de ticketing ou de gestion de projet existantes, une option pragmatique quand l'organisme dispose déjà d'un outil de suivi utilisé par les équipes techniques, évitant d'ajouter un système supplémentaire peu consulté.

Quel que soit l'outil, le critère décisif reste la capacité à répondre en quelques minutes, pendant un audit, à la question « montrez-moi tous les contrôles qui traitent ce risque » et réciproquement « montrez-moi tous les risques justifiant ce contrôle ». Un registre qui ne permet pas cette navigation dans les deux sens, quelle que soit sa sophistication apparente, ne remplit pas sa fonction première.

Articuler risques, SoA et objectifs

En audit de certification, la traçabilité attendue suit un fil précis :

1. Un risque est identifié et évalué dans le registre.
2. Il est traité par un ou plusieurs contrôles de l'Annexe A, référencés dans la SoA.
3. Le contrôle est décliné en objectif opérationnel mesurable ou en procédure documentée.
4. Le suivi de l'objectif ou de l'indicateur alimente la revue de direction (clause 9.3) et, le cas échéant, déclenche une révision du registre de risques.

Rompre ce fil — par exemple une SoA qui justifie un contrôle sans risque associé identifiable, ou un risque traité sans que le contrôle correspondant apparaisse dans la SoA — est la source la plus fréquente de non-conformités lors des audits de certification initiale.

Pièges courants

• Registre de risques figé, évalué une fois lors du projet de certification et jamais révisé depuis.
• SoA copiée d'un modèle générique sans lien réel avec les risques propres à l'organisme — facilement détecté par un auditeur qui croise les justifications avec le registre de risques.
• Confusion entre risque inhérent et risque résiduel : ne présenter que le risque après contrôles empêche de justifier pourquoi ces contrôles ont été choisis en premier lieu.
• Absence de propriétaire de risque nommé individuellement — « la DSI » n'est pas un propriétaire de risque recevable ; il faut une personne identifiée, capable d'accepter formellement un niveau de risque.
• Objectifs sans échéance ni indicateur — un objectif du type « améliorer la sécurité du cloud », sans mesure ni date, est systématiquement relevé en audit.

Checklist de sortie de clause 6

• Méthodologie d'appréciation des risques documentée et validée par la direction
• Critères d'acceptation du risque définis et approuvés
• Registre de risques à jour, avec propriétaires nommés individuellement
• Plan de traitement des risques avec échéances et responsables
• SoA couvrant les 93 contrôles, avec justification d'inclusion ou d'exclusion pour chacun
• Objectifs de sécurité mesurables déclinés par fonction concernée
• Traçabilité risque → contrôle → objectif vérifiable de bout en bout
• Date de dernière revue du registre et déclencheurs de réévaluation identifiés