ISO 27001:2022 en pratique
Ce chapitre introductif présente le SMSI selon ISO/IEC 27001:2022 : sa logique de gouvernance, les nouveautés de la révision 2022 et la structure de l'Annexe A. Il pose les repères indispensables avant d'aborder, chapitre par chapitre, chaque clause du système de management.
Table des matières
ISO 27001:2022 en pratique
Pourquoi un SMSI plutôt qu'une liste de bonnes pratiques
Une entreprise qui empile des mesures de sécurité — pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire, sauvegardes, sensibilisation annuelle — sans les relier entre elles finit toujours par découvrir un angle mort au pire moment. La norme ISO/IEC 27001 ne vend pas des mesures techniques : elle impose un système de management qui pilote, dans la durée, les décisions de sécurité de l'information. C'est la différence entre « avoir un antivirus » et « savoir pourquoi, sur quel périmètre, avec quel budget et sous quelle responsabilité l'organisation a choisi ce niveau de protection ».
Un SMSI, Système de Management de la Sécurité de l'Information, répond à quatre questions que la plupart des politiques de sécurité artisanales laissent sans réponse : quel est le périmètre exact couvert, qui est responsable de quoi, comment les risques sont identifiés et traités, et comment le dispositif est corrigé quand il échoue. La norme ne dicte pas les mesures techniques précises à déployer — elle exige une démarche documentée, auditable et améliorée en continu. C'est un référentiel de gouvernance avant d'être un référentiel technique, ce qui surprend souvent les équipes techniques qui l'abordent pour la première fois.
ISO/IEC 27001 certifie un système de management, pas un niveau de sécurité absolu. Deux organisations certifiées peuvent avoir des postures très différentes si leurs analyses de risques et leurs périmètres divergent. La certification atteste d'une démarche rigoureuse et documentée, pas d'une invulnérabilité technique.
Ce que change la révision 2022
La version 2022 remplace celle de 2013, publiée depuis près de dix ans. Le calendrier de transition est désormais clos : depuis le 31 octobre 2025, les certificats délivrés sur la base de la version 2013 ne sont plus valides, et tout organisme certifié est censé avoir migré vers ISO/IEC 27001:2022, y compris sa Déclaration d'Applicabilité.
Sur le fond, les clauses de management, celles numérotées 4 à 10, évoluent peu. La structure commune aux normes de système de management (la High Level Structure, partagée avec ISO 9001 ou ISO 22301) reste identique, ce qui facilite l'intégration d'un SMSI dans un système de management déjà en place pour la qualité ou la continuité d'activité. Le changement majeur porte sur l'Annexe A, entièrement réorganisée et enrichie de onze mesures qui répondent à des sujets peu ou pas traités en 2013 : renseignement sur les menaces, sécurité des services cloud, préparation des TIC pour la continuité d'activité, surveillance de la sécurité physique, gestion de configuration, suppression de l'information, masquage 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, prévention de la fuite de donnéesfuite de donnéesIAErreur consistant à laisser entrer dans l'entraînement une information qui n'existera pas au moment réel de la prédiction. Le modèle affiche des scores excellents puis s'effondre en production.Voir dans le glossaire, surveillance des activités, filtrage web et codage sécurisé.
Si vous intervenez aujourd'hui sur un SMSI dont la documentation référence encore explicitement l'Annexe A de 2013 (114 mesures réparties en 14 domaines), c'est un signal d'alerte à traiter avant tout audit : la table de correspondance entre les deux versions doit être produite et la Déclaration d'Applicabilité reconstruite sur la base des 93 mesures actuelles.
La structure commune : les clauses 4 à 10
Toutes les normes de système de management ISO récentes partagent la même architecture en dix clauses, ce qui permet de lire un SMSI avec la même grille qu'un système qualité.
| Clause | Intitulé | Ce qu'elle exige concrètement |
|---|---|---|
| 4 | 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 de l'organisme | Périmètre écrit et justifié, parties intéressées identifiées, enjeux internes et externes |
| 5 | Leadership | Politique de sécurité de l'information signée par la direction, rôles et responsabilités assignés |
| 6 | Planification | Méthodologie d'appréciation des risques, objectifs de sécurité mesurables, plan de traitement |
| 7 | Support | Ressources, compétences, sensibilisation, communication interne et externe, documentation maîtrisée |
| 8 | Fonctionnement | Mise en œuvre opérationnelle des mesures, traitement effectif des risques, gestion du changement |
| 9 | Évaluation des performances | Programme d'audit interne, revue de direction périodique, indicateurs de performance |
| 10 | Amélioration | Traitement des non-conformités, actions correctives, amélioration continue du dispositif |
Ces sept clauses forment l'ossature vivante du système. L'Annexe A, elle, constitue la boîte à outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire : un catalogue de mesures dans lequel l'organisme pioche celles qui répondent à ses risques réels, en justifiant chaque choix d'inclusion ou d'exclusion. La clause 7.5, souvent sous-estimée, mérite une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière : elle exige une information documentée maîtrisée — versionnée, revue avant diffusiondiffusionIAFamille de modèles génératifs qui synthétisent une image (ou autre signal) en dénisant progressivement un bruit.Voir dans le glossaire, accessible aux bonnes personnes et protégée contre une modification non autorisée. Un SMSI dont les procédures vivent dans des fichiers Word éparpillés sur des postes individuels, sans contrôle de version ni processus de revue, ne satisfait pas cette exigence même si le contenu des procédures est par ailleurs correct.
L'Annexe A restructurée : 4 thèmes, 93 mesures
L'Annexe A 2013 organisait les mesures en 14 domaines (A.5 à A.18). La version 2022 les regroupe en quatre thèmes seulement, ce qui rend la lecture plus directe et facilite le rattachement de chaque mesure à une fonction de l'organisation.
| Thème | Code | Nombre de mesures |
|---|---|---|
| Organisationnel | A.5 | 37 |
| Personnes | A.6 | 8 |
| Physique | A.7 | 14 |
| Technologique | A.8 | 34 |
Pour les organismes déjà certifiés sous la version 2013, l'exercice de bascule a consisté à produire une table de correspondance entre les 114 anciennes mesures et les 93 nouvelles : certaines mesures ont fusionné (par exemple les anciennes mesures relatives à la gestion des supports amovibles se retrouvent regroupées), d'autres ont simplement changé de numéro sans changement de fond. Cette table de correspondance, bien que non explicitement exigée par la norme, reste le meilleur outil pour démontrer à un auditeur que rien n'a été perdu dans la transition, et pas seulement renommé.
Nouveauté pratique importante : chaque mesure de l'Annexe A 2022 porte désormais cinq attributs normalisés (type de mesure, propriétés de sécurité de l'information, concepts de cybersécurité, capacités opérationnelles, domaines de sécurité). Ces attributs permettent de filtrer et de regrouper les mesures selon des angles différents de la classification par thème — utile, par exemple, pour produire une vue « toutes les mesures liées à la détection » qui traverse les quatre thèmes.
Une PME qui héberge l'intégralité de son système d'information chez un fournisseur cloud externe et n'a plus de datacenter en propre priorisera dans son plan de traitement les mesures A.5.23 (sécurité de l'information pour l'usage des services cloud) et A.8.11 (masquage des données) plutôt que l'essentiel des mesures A.7 sur la sécurité physique des locaux, qui ne concernent alors plus que ses bureaux.
Le cycle PDCA appliqué au quotidien
Le SMSI se pilote selon le cycle Plan-Do-Check-Act, la roue de Deming, qui structure aussi l'ensemble des dix clauses :
- Plan (clauses 4 à 6) — définir le périmètre, la politique, la méthode d'appréciation des risques et les objectifs.
- Do (clauses 7 et 8) — allouer les ressources, former les équipes, mettre en œuvre les mesures retenues, traiter les risques.
- Check (clause 9) — auditer en interne, mesurer les indicateurs, tenir la revue de direction.
- Act (clause 10) — corriger les non-conformités relevées, ajuster les mesures, réviser l'appréciation des risques si le contexte a changé.
Ce cycle ne se déroule pas une fois par an au moment de l'audit de surveillance : il tourne en continu, à des rythmes différents selon les activités. Un audit interne peut être trimestriel sur les processus critiques, une revue de direction semestrielle, et un ajustement de mesure technique peut intervenir dans la semaine suivant un incident. La maturité d'un SMSI se lit précisément à la fréquence et à la traçabilité de ces boucles courtes. Un tableau de bord qui distingue les boucles courtes (revue d'un incident, ajustement d'une règle de pare-feu) des boucles longues (revue de direction, audit de certification) aide à visualiser cette dynamique et à éviter l'écueil du SMSI qui ne vit qu'au moment de l'audit annuel.
La Déclaration d'Applicabilité, clé de voûte du dispositif
La Déclaration d'Applicabilité, ou SoA (Statement of Applicability), est le document que tout auditeur ouvre en premier. Pour chacune des 93 mesures de l'Annexe A, elle indique si la mesure est applicable ou exclue, avec une justification, son état de mise en œuvre, et une référence vers le plan de traitement des risques qui a motivé son inclusion.
Une SoA solide n'est jamais un simple tableau coché « oui » partout : les exclusions doivent être argumentées avec la même rigueur que les inclusions. Exclure A.7.4 (surveillance de la sécurité physique) parce que l'organisme n'a aucun local physique sous sa responsabilité est une justification recevable. Exclure une mesure parce qu'elle est « coûteuse à mettre en œuvre » n'en est pas une : le coût peut justifier un traitement du risque étalé dans le temps, pas une exclusion de la mesure elle-même.
Ne recopiez jamais la Déclaration d'Applicabilité d'une autre organisation, même dans le même secteur d'activité. Un auditeur qui repère une justification générique, du type « bonne pratique du secteur », sans lien explicite avec l'appréciation des risques propre à l'organisme, lève quasi systématiquement une non-conformité sur la clause 6.1.3.
Pièges classiques de mise en œuvre
Quelques erreurs reviennent avec une régularité frappante dans les projets de mise en conformité :
- Périmètre trop large déclaré, trop étroit tenu. Annoncer « l'ensemble du système d'information » en clause 4 puis découvrir en audit que trois applications critiques n'ont jamais été intégrées dans l'appréciation des risques. Cet écart, souvent découvert lors de l'audit de certification plutôt qu'en interne, force une extension de périmètre dans l'urgence, avec toute la charge documentaire que cela suppose.
- Politique de sécurité copiée sans appropriation. Un document signé par la direction mais jamais relié aux risques réels de l'organisme, qui ne sert à rien lors d'un arbitrage budgétaire.
- Appréciation des risques figée. Une analyse réalisée une fois, jamais révisée après un changement d'architecture, l'arrivée d'un nouveau prestataire ou un incident significatif. Un risque évalué comme faible en 2023 sur la base d'une architecture qui n'existe plus n'a aucune valeur probante en 2026.
- Confusion entre ISO 27001 et ISO 27002. La première définit les exigences du système de management et le catalogue de mesures ; la seconde ne fait que détailler la mise en œuvre technique de chaque mesure. On ne se certifie jamais sur 27002.
- Documentation surdimensionnée. Des procédures rédigées pour impressionner l'auditeur plutôt que pour être réellement suivies par les équipes, qui deviennent un fardeau et finissent ignorées.
- Traitement des risques sans propriétaire nommé. Une action inscrite au plan de traitement sans responsable ni échéance a statistiquement de très faibles chances d'être réalisée. La clause 5.3 exige justement des rôles et responsabilités assignés et communiqués ; l'absence de propriétaire sur une action du plan de traitement est souvent le symptôme d'un manquement plus large sur cette clause.
Où ce parcours vous emmène
Ce chapitre pose le cadre général ; les neuf suivants détaillent chaque brique du dispositif dans l'ordre où vous les rencontrerez sur un projet réel :
- Contexte, périmètre et parties intéressées (clause 4)
- Leadership, politique et gouvernance (clause 5)
- Appréciation et traitement des risques (clause 6, en lien avec ISO/IEC 27005)
- Construire la Déclaration d'Applicabilité et le plan de traitement
- Support : ressources, compétences et documentation maîtrisée (clause 7)
- Annexe A, mesures organisationnelles en pratique
- Annexe A, mesures techniques et physiques en pratique
- Évaluation des performances : audit interne et revue de direction (clause 9)
- Amélioration continue et cycle de certification (clause 10)
Ouvrez dès maintenant, même de façon sommaire, un tableur ou un outil GRC pour consigner votre périmètre, vos parties intéressées et vos premiers risques identifiés. Les chapitres suivants s'appuient directement sur ces artefacts : mieux vaut les démarrer dès ce premier chapitre que de les reconstruire en urgence au moment d'aborder l'Annexe A.
L'essentiel à retenir
Ce chapitre présente le Système de Management de la Sécurité de l'Information (SMSI) tel que défini par ISO/IEC 27001:2022, en expliquant pourquoi la norme impose une démarche de gouvernance documentée plutôt qu'une simple liste de mesures techniques. Il détaille les changements apportés par la révision 2022 par rapport à la version 2013, notamment la réorganisation de l'Annexe A en quatre thèmes totalisant 93 mesures et l'ajout de onze nouvelles mesures. Il explique le rôle central de la Déclaration d'Applicabilité et le fonctionnement du cycle PDCA appliqué aux dix clauses de la norme. Le chapitre se termine par une liste des pièges de mise en œuvre les plus fréquents et par la feuille de route des neuf chapitres suivants du parcours.
- SMSI (Système de Management de la Sécurité de l'Information)
- Structure commune HLS et clauses 4 à 10
- Cycle PDCA (Plan-Do-Check-Act)
- Annexe A 2022 : 4 thèmes, 93 mesures
- Déclaration d'Applicabilité (SoA)
- Appréciation et traitement des risques
- Transition ISO 27001:2013 vers 2022
- Audits et amélioration continue
Questions fréquentes
Faut-il être certifié ISO 27001 pour bénéficier de la norme ?
Quelle est la différence entre ISO/IEC 27001 et ISO/IEC 27002 ?
Mon organisme est encore certifié ISO/IEC 27001:2013, que dois-je faire ?
Peut-on exclure des mesures de l'Annexe A ?
Combien de temps prend la mise en place d'un SMSI avant une première certification ?
Le SMSI doit-il couvrir l'intégralité du système d'information de l'organisation ?
Qu'est-ce qu'un audit de surveillance, et diffère-t-il de l'audit de certification initial ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).