ISO 27002 : le guide des 93 contrôles de sécurité, thème
par thème

"ISO 27002, c'est ISO 27001 en moins bien." On l'entend en comité de pilotage, on le lit dans des appels d'offres, et c'est faux dans les deux sens. Moins bien, non : le document est nettement plus épais, parce qu'il contient tout ce que l'Annexe A de 27001 se contente de nommer. Et ce n'est pas un sous-produit non plus : ISO 27002 est le texte dans lequel les 93 contrôles ont été écrits, numérotés et annotés, puis recopiés en une ligne chacun dans l'annexe de la norme certifiable. La dépendance va dans ce sens-là. Quiconque a tenté de mettre en oeuvre "A.8.8 Gestion des vulnérabilités techniques" à partir de son seul intitulé sait ce qui manque : le texte de 27002 consacre plusieurs pages à ce contrôle, l'Annexe A quelques mots.

Le document a l'épaisseur d'un annuaire et personne ne le lit d'une traite. On y entre par un numéro, le jour où un auditeur pointe du doigt le 8.28 ou bien où un client réclame la preuve derrière le 8.8. Le coût de la certification et le cycle d'audit sur trois ans ne sont pas repris ici, ils ont leur propre article sur la certification ISO 27001. Autre chose à poser d'emblée : own2pwn n'est pas organisme de certification, n'anime pas de SMSI et ne vend aucun outil de conformité. Il fabrique des artefacts techniques sur une poignée de contrôles numérotés, et rien d'autre.

ISO 27002 et ISO 27001 : un catalogue, deux documents

ISO/IEC 27001 fixe des exigences : les clauses 4 à 10 décrivent ce qu'un système de management de la sécurité de l'information doit contenir (contexte, leadership, planification, support, fonctionnement, évaluation, amélioration), et l'Annexe A liste les contrôles parmi lesquels l'organisation choisit, dans sa déclaration d'applicabilité, ceux qu'elle retient et ceux qu'elle écarte avec justification. C'est ce texte qu'un organisme accrédité audite, et le seul qui débouche sur un certificat. ISO/IEC 27002 reprend les mêmes 93 contrôles, avec la même numérotation (le 5.7 de 27002 est le A.5.7 de l'annexe), et donne pour chacun un objectif, les cinq attributs, des recommandations de mise en oeuvre et des informations complémentaires. Elle ne contient aucune exigence de management, donc rien à certifier. On ne demande pas "une certification ISO 27002", ça n'existe pas.

Les deux textes ont été révisés à la suite : 27002 en février 2022, 27001 en octobre 2022 avec une Annexe A réalignée sur le nouveau catalogue. La période de transition fixée par l'IAF pour les organismes certifiés était de 36 mois à compter de la fin du mois de publication, soit jusqu'au 31 octobre 2025 selon l'IAF MD 26. Depuis cette date, il n'y a plus de certificat 2013 valide, et tout audit se fait sur les 93 contrôles décrits ici. Si un consultant vous parle encore de "A.12.6.1", il lit une vieille édition.

Reste la question qu'on esquive souvent : d'où viennent les contrôles retenus ? De l'analyse de risques, pas de l'annexe. La clause 6.1.3 de 27001 impose de comparer les mesures issues du traitement des risques avec l'Annexe A pour vérifier qu'on n'a rien oublié ; l'annexe sert de filet, on ne part pas d'elle. La méthode d'appréciation, elle, est décrite dans un troisième texte de la famille, la norme ISO 27005 sur la gestion des risques. Et l'ensemble s'inscrit dans une démarche de gouvernance dont le vocabulaire est posé par le pilier sur la GRC en cybersécurité.

La révision de 2022 : de 114 contrôles en 14 domaines à 93 en 4 thèmes

L'édition 2013 alignait 114 contrôles dans 14 domaines numérotés de A.5 à A.18, avec des sous-niveaux à trois chiffres (A.12.6.1, A.14.2.8) que personne ne retenait. L'édition 2022 aplatit tout : quatre thèmes, un numéro à deux niveaux, et un regroupement par nature du contrôle plutôt que par sujet. Un contrôle organisationnel est un contrôle qui se décide et se documente ; un contrôle technologique est un contrôle qui se configure, se teste ou se mesure. Ce critère de tri, en apparence anodin, est ce qui rend la nouvelle édition lisible par un RSSI et par un DSI en même temps.

Ces vingt et un contrôles de moins ne correspondent à aucune suppression. D'après le décompte publié par les auditeurs de Schellman, 24 des 93 contrôles de 2022 résultent de la fusion de plusieurs contrôles de 2013, 58 en reprennent un seul avec un texte remanié, et 11 sont des créations. Le compte tombe juste : 24 + 58 + 11 = 93. Les fusions concernent surtout des paires qui se recouvraient (la politique de sécurité et sa revue, les différentes facettes de la gestion des supports). Les créations, elles, disent quelque chose de l'époque : la veille sur les menaces, le cloud, la configuration, la surveillance et le codage sécurisé n'avaient aucune ligne dédiée en 2013.

Les cinq attributs, ou comment filtrer 93 contrôles selon qui les lit

C'est la partie de l'édition 2022 la moins exploitée, et à mon avis la plus utile. Chaque contrôle porte cinq étiquettes, écrites sous forme de mots-dièse dans le texte, qui permettent de le retrouver par une autre entrée que son numéro. Le principe est celui d'un tableau à filtres : on ne lit pas 93 contrôles, on extrait la dizaine qui concerne l'équipe de développement, ou ceux de nature détective, ou ceux qui portent sur la disponibilité. L'attribution est indicative et la norme dit elle-même qu'une organisation peut redéfinir les valeurs ou ajouter ses propres attributs.

L'usage le plus rentable consiste à filtrer sur la capacité opérationnelle "sécurité applicative" : il sort l'essentiel de la série 8.25 à 8.34 plus quelques contrôles organisationnels, soit à peu près le périmètre qu'on peut confier à une équipe produit sans lui faire lire les 80 autres. Le filtre "détectif" est plus cruel, parce qu'il fait apparaître à quel point le catalogue est préventif par construction. La colonne détective est courte (5.7, 7.4, 8.15, 8.16 et quelques autres), et c'est précisément là que les organisations sont les plus faibles à l'audit, puisqu'un contrôle détectif ne se prouve pas avec une politique mais avec des alertes traitées et horodatées. Le cinquième attribut, les quatre domaines, parlera aux lecteurs français : gouvernance et écosystème, protection, défense, résilience, c'est à un mot près le modèle en quatre piliers (gouvernance, protection, défense, résilience) sous lequel le ReCyF répartit ses vingt objectifs.

ISO 27002 thème par thème : ce que chaque famille demande

Organisationnel (5.1 à 5.37) : la charpente, et deux contrôles vivants

Trente-sept contrôles, la plupart documentaires. On y trouve les politiques et leur revue (5.1), les rôles (5.2 à 5.4), les contacts avec les autorités et les groupes d'intérêt (5.5, 5.6), l'inventaire et la classification des actifs (5.9 à 5.13), les règles d'accès et d'identité (5.15 à 5.18), les quatre contrôles fournisseurs (5.19 à 5.22) plus le cloud (5.23), la gestion des incidents de la planification à la collecte de preuves (5.24 à 5.28), la continuité (5.29, 5.30), et le bloc conformité qui va des exigences légales à la revue indépendante et aux procédures d'exploitation (5.31 à 5.37). La règle d'usage acceptable (5.10) est le contrôle que matérialise une charte informatique opposable, ce qui suppose qu'elle ait été annexée au règlement intérieur ou signée.

Deux contrôles de ce thème refusent de rester sur le papier. L'inventaire des actifs (5.9) est faux dès qu'il est figé : un sous-domaine oublié ou une instance cloud montée par un prestataire y manque par définition, et un auditeur qui compare l'inventaire avec ce qu'il voit depuis Internet trouve l'écart en dix minutes. La veille sur les menaces (5.7) est l'autre : elle demande que l'information collectée soit analysée et suivie d'effet, donc un lien traçable entre un bulletin d'alerte et une action sur le SI.

Personnes (6.1 à 6.8) : du recrutement au signalement

Huit contrôles qui suivent la vie d'un collaborateur : vérification avant embauche (6.1), clauses de sécurité dans le contrat (6.2), sensibilisation et formation (6.3), processus disciplinaire (6.4), responsabilités qui survivent au départ (6.5), engagements de confidentialité (6.6), télétravail (6.7) et signalement des événements de sécurité (6.8). Le thème est court mais c'est celui où les preuves sont les plus faciles à fabriquer et les plus faciles à démonter : une feuille d'émargement de sensibilisation prouve une présence, pas un apprentissage. Un auditeur sérieux demandera plutôt le taux de signalement des campagnes de phishing simulées, parce que 6.8 se mesure là.

Physique (7.1 à 7.14) : le thème que le pentester web ne voit jamais

Périmètres (7.1), contrôle des entrées (7.2), protection des locaux (7.3), la nouvelle surveillance physique (7.4), menaces environnementales (7.5), travail en zone sécurisée (7.6), bureau propre et écran verrouillé (7.7), positionnement et protection des équipements (7.8), actifs hors site (7.9), supports de stockage (7.10), services support comme l'électricité (7.11), câblage (7.12), maintenance (7.13) et mise au rebut ou réemploi (7.14). Pour une organisation dont tout le SI est chez un hébergeur, la plupart de ces contrôles se traitent par transfert : c'est le rapport d'audit du prestataire, ou sa propre certification, qui fait foi, et c'est le contrôle 5.22 (suivi des services fournisseurs) qui oblige à aller le chercher chaque année. Le 7.14 reste à la charge de l'organisation quoi qu'il arrive : un disque de portable revendu sans effacement est une fuite de données au sens plein du terme.

Technologique (8.1 à 8.34) : là où la preuve est un artefact

Trente-quatre contrôles et le coeur du sujet pour quiconque produit ou exploite du logiciel. Le thème s'ouvre sur les terminaux (8.1), les accès privilégiés (8.2), la restriction d'accès à l'information et au code source (8.3, 8.4), l'authentification (8.5) et la capacité (8.6). Suivent la protection contre les codes malveillants (8.7), la gestion des vulnérabilités techniques (8.8), la configuration (8.9), les trois contrôles sur le cycle de vie de la donnée (suppression 8.10, masquage 8.11, prévention des fuites 8.12), la sauvegarde et la redondance (8.13, 8.14), puis la journalisation, la surveillance et la synchronisation des horloges (8.15 à 8.17), qui vont ensemble parce qu'un journal sans horodatage fiable ne prouve rien. Les contrôles 8.18 et 8.19 encadrent les utilitaires à privilèges et l'installation de logiciels, 8.20 à 8.23 le réseau (sécurité, services, cloisonnement, filtrage web), 8.24 la cryptographie.

La série 8.25 à 8.34 est un mini-référentiel de développement sécurisé à elle seule : cycle de vie (8.25), exigences de sécurité applicative (8.26), principes d'architecture et d'ingénierie (8.27), codage sécurisé (8.28), tests de sécurité en développement et recette (8.29), développement externalisé (8.30), séparation des environnements (8.31), gestion des changements (8.32), données de test (8.33) et protection des systèmes pendant les tests d'audit (8.34). Ce dernier est celui qu'on invoque pour cadrer un test d'intrusion sur la production : fenêtre, comptes dédiés, sauvegarde préalable, et c'est une bonne chose que la norme le nomme.

Les contrôles ISO 27002 qui exigent une preuve technique

Sur 93 contrôles, la majorité se démontre avec un document signé, un registre ou un compte rendu de revue. Une minorité demande qu'une action ait été menée, datée et tracée, et c'est celle-là qui met un dossier de certification en difficulté, parce qu'on ne la produit pas la semaine de l'audit. Le tableau qui suit est volontairement restreint aux contrôles où l'auditeur, s'il fait son travail, demandera l'artefact et pas la politique.

Le 8.28 est le contrôle qu'on traite le plus mal, parce qu'il est récent et qu'une page de wiki intitulée "guide de codage sécurisé" a l'air de suffire. Ce n'est pas ce que la norme décrit : elle attend des principes appliqués avant, pendant et après le codage, y compris pour les bibliothèques tierces, et un auditeur qui a lu le texte demandera comment on vérifie l'application. La réponse qui tient est un outillage d'analyse statique (SAST) branché sur le dépôt, avec des résultats horodatés par version, et une analyse de composition (SCA) pour la partie composants externes, qui recoupe le 5.21 sur la chaîne d'approvisionnement. C'est le périmètre de SecAI, l'outil SAST et SCA d'own2pwn, avec une limite qu'il vaut mieux annoncer que laisser découvrir : il ne teste pas l'application en cours d'exécution, ce n'est pas un DAST, et il ne remplace en rien le 8.29.

Le 8.29, justement, est le contrôle du pentest. Le texte parle de tests de sécurité définis dans le cycle de développement et exécutés avant la mise en production, ce qui inclut des tests automatisés mais aussi des tests d'intrusion pour les systèmes exposés. Un rapport de pentest web en boîte noire daté, avec un périmètre écrit et un retest des correctifs, est l'artefact que l'auditeur versera au dossier. Un rapport de deux ans sur une application qui a connu vingt releases depuis n'en est plus un.

Les contrôles fournisseurs (5.19 à 5.22) sont contractuels à trois quarts, et techniques pour le quart qui compte. La sélection (5.19) et les clauses (5.20) relèvent des achats et du juridique. Le 5.21, sur la chaîne d'approvisionnement TIC, bascule côté technique dès qu'on demande une nomenclature des composants (SBOM) ou une preuve que les dépendances sont suivies. Le 5.22, suivi et revue, est celui qu'on oublie : il exige de revenir sur chaque prestataire périodiquement, avec un compte rendu. La mécanique complète, et ce que NIS2 et DORA y ajoutent, occupe l'article sur la gestion des risques tiers (TPRM).

ISO 27002, NIS2 article 21 et ReCyF : la table de correspondance

L'article 21 de la directive (UE) 2022/2555 impose aux entités essentielles et importantes des mesures "techniques, opérationnelles et organisationnelles" fondées sur une approche tous risques, et son paragraphe 2 en liste dix familles, de (a) à (j). Le paragraphe 1 précise que ces mesures tiennent compte des normes européennes et internationales applicables : c'est la porte par laquelle ISO 27002 entre dans NIS2, sans jamais y être nommée. En France, l'ANSSI décline ces dix familles en vingt objectifs de sécurité dans le ReCyF version 2.5 du 17 mars 2026, dont les tableaux de correspondance en annexe relient chaque point de l'article 21.2 aux objectifs. La colonne ISO 27002 ci-dessous est mon interprétation, pas un mapping publié par l'ISO ou l'ANSSI ; les deux autres colonnes sont celles des textes.

La famille (e) est la plus large des deux côtés : elle absorbe toute la série développement d'ISO 27002 et neuf objectifs du ReCyF, dont l'audit (17) et la configuration (18) réservés aux entités essentielles. Le ReCyF, lui, est plus précis qu'ISO 27002 sur les délais et les périmètres : la mesure 5.B.4 demande d'appliquer les correctifs "sans retard injustifié" sur les ressources exposées à des systèmes tiers et sur les postes de travail, là où le 8.8 parle de délais appropriés ; et la mesure 18.4-EE impose une revue annuelle de configuration appuyée sur des outils, dont le scan de ports et de vulnérabilités, quand le 8.9 reste sur le principe. Le référentiel reconnaît en revanche un SMSI certifié ISO 27001:2022 comme moyen acceptable de conformité pour l'objectif 2 (cadre de gouvernance) et, pour les entités essentielles, l'objectif 16 (approche par les risques), sur les systèmes couverts par le certificat. Pas pour les dix-huit autres. Le détail objectif par objectif se lit dans l'article consacré au ReCyF, le référentiel de cybersécurité de l'ANSSI.

Se servir d'ISO 27002 sans viser le certificat

La plupart des lecteurs de 27002 ne seront jamais certifiés, et c'est très bien ainsi. Le texte s'achète seul, se lit sans SMSI, et sert à trois choses même quand on n'a pas d'auditeur en vue. Il donne un vocabulaire commun avec les clients qui envoient des questionnaires de sécurité : quand la question 42 demande "décrivez votre gestion des vulnérabilités", répondre par le périmètre du 8.8 évite d'inventer une réponse différente à chaque client. Il donne une liste de contrôle pour prioriser, à condition de partir des risques et non de la première page : les attributs sont là pour ça. Et il donne un point d'arrivée à un audit technique : un rapport de test qui rattache chaque constat à un contrôle numéroté se lit par un RSSI, un DSI et un assureur avec la même grille.

Le pire usage qu'on puisse en faire, et je l'ai croisé plus d'une fois, consiste à transformer le catalogue en tableau de 93 lignes avec une colonne "conforme" et une colonne "preuve" remplie de liens vers des documents Word. Ce tableau-là existe dans toutes les organisations qui ont raté leur premier audit, et il y sert surtout à repousser le moment où il faudra ouvrir un ticket. Le bon usage commence par la question inverse : sur ces 93 contrôles, lesquels changeraient concrètement le résultat d'une attaque contre nous ? La réponse tient rarement en plus de vingt lignes, et ce sont ces vingt-là qu'il faut prouver avec des artefacts plutôt qu'avec des politiques.

À retenir

• ISO 27002 est le guide de mise en oeuvre des 93 contrôles de l'Annexe A d'ISO 27001, avec la même numérotation. Seule 27001 se certifie ; 27002 explique comment faire.
• L'édition 2022 est passée de 114 contrôles en 14 domaines à 93 en 4 thèmes (37 organisationnels, 8 personnes, 14 physiques, 34 technologiques), avec 11 contrôles créés, dont la veille sur les menaces (5.7), la configuration (8.9), la surveillance (8.16) et le codage sécurisé (8.28). La transition des certificats s'est achevée le 31 octobre 2025.
• Les cinq attributs (type, propriété CIA, concept de cybersécurité, capacité opérationnelle, domaine) servent à filtrer le catalogue par lecteur : la vue "sécurité applicative" isole la série 8.25 à 8.34.
• Une minorité de contrôles se prouve par un artefact daté et non par un document : 8.8, 8.29, 8.28, 8.9, 8.16 et le 5.21 côté composants logiciels. C'est là que les dossiers échouent.
• Les dix familles de l'article 21.2 de NIS2 se projettent sur ISO 27002 et sur les 20 objectifs du ReCyF v2.5 ; le ReCyF reconnaît un SMSI certifié ISO 27001:2022 pour ses objectifs 2 et 16 seulement, et reste plus précis que la norme sur les délais de correction et la revue de configuration.

Le 8.28 et le 8.8 sont les deux contrôles qui bloquent le plus souvent un dossier, et leur preuve se fabrique dans le dépôt de code et sur la surface exposée, pas dans la PSSI. L'analyse statique et de composition de SecAI produit des findings datés par version, et un pentest en boîte noire fournit le rapport et le retest qu'attend le 8.29. Le reste du catalogue se joue entre votre SMSI et votre certificateur, et aucun prestataire technique ne le portera à votre place.

Questions fréquentes sur ISO 27002