L’ISO 27001 n’est pas une norme informatique

Une intervention improvisée, glissée dans la session de rumps de BarbHack 2026, sur un sujet qui pouvait sembler déplacé dans une conférence de sécurité offensive : la norme ISO/IEC 27001. Deux affirmations en quelques minutes, et toutes deux méritent d’être développées. D’abord, cette norme n’est pas un standard informatique. Ensuite, son usage le plus précieux au quotidien est de permettre à un responsable sécurité de justifier ses moyens auprès de sa direction.

Quinzième volet de notre couverture de BarbHack. Le compte-rendu d’origine tenait en trois paragraphes, nous l’avons étoffé avec le contenu réel de la norme.

L’idée reçue, et ce que contient vraiment la norme

Dans la plupart des esprits, « ISO 27001 » évoque des pare-feux, du chiffrement et des sauvegardes. C’est une lecture qui ne résiste pas à l’ouverture du document.

La norme se compose de deux parties. D’un côté, les chapitres 4 à 10, qui portent les exigences obligatoires et dont pas une seule n’est technique : le contexte de l’organisation, le rôle de la direction, la planification, les ressources et les compétences, le fonctionnement, l’évaluation des performances, et l’amélioration. De l’autre, l’annexe A et son catalogue de mesures de sécurité.

Or, depuis la révision de 2022, cette annexe compte 93 mesures réparties en quatre thèmes :

• 37 mesures organisationnelles : politiques, rôles et responsabilités, séparation des tâches, sécurité dans les relations fournisseurs et le cloud, gestion des incidents, continuité.
• 8 mesures liées aux personnes : tout le cycle de vie d’un collaborateur, du contrôle avant embauche aux obligations qui survivent à son départ.
• 14 mesures physiques : locaux, zones sécurisées, équipements, supports.
• 34 mesures technologiques.

Autrement dit, un peu plus d’un tiers seulement des mesures relève de la technique. Les deux autres tiers se jouent en comité de direction, aux ressources humaines, aux achats, au juridique et aux services généraux.

C’est la raison pour laquelle un projet ISO 27001 confié à la seule direction informatique échoue si régulièrement. Non par incompétence, mais parce que les deux tiers du sujet ne sont pas dans son périmètre d’action.

Ce que la norme exige réellement

Les chapitres obligatoires demandent, en langage clair :

• De savoir où l’on est : quel est le contexte de l’organisation, qui sont les parties intéressées, et surtout quel périmètre on décide de couvrir.
• Que la direction s’engage, nommément. Pas un parrainage de façade : une politique, des rôles attribués, des arbitrages assumés.
• D’identifier et de traiter les risques, avec une méthode écrite, des critères d’acceptation décidés à l’avance, et un plan de traitement.
• De donner les moyens : compétences, sensibilisation, communication, documentation.
• De vérifier : indicateurs, audit interne, revue de direction à intervalles planifiés.
• De corriger et d’améliorer en continu, non-conformité par non-conformité.

Nulle part il n’est écrit quel produit acheter. La norme ne prescrit pas une solution, elle exige que les décisions soient prises, justifiées et tracées.

Le vrai levier : transformer un budget refusé en décision assumée

C’est le point le plus juste de l’intervention, et il mérite d’être pris au sérieux par tous les responsables sécurité qui se heurtent à un mur budgétaire.

Sans cadre, la demande de moyens est une opinion : « il nous faudrait une solution de sauvegarde hors site ». Elle entre en concurrence avec toutes les autres opinions de l’entreprise, et elle perd souvent, parce qu’elle est la seule à parler d’un événement qui n’a pas encore eu lieu.

Avec le cadre de la norme, la même demande devient autre chose. Le risque est nommé, son impact est évalué selon des critères que la direction a elle-même validés, le traitement est décidé, et l’ensemble est écrit et signé. Le responsable sécurité ne demande plus un budget : il expose une décision que la direction a déjà prise et en chiffre la mise en œuvre.

Et si les moyens sont refusés, le refus devient lui aussi une décision explicite, datée, portée par ceux dont c’est la responsabilité. Ce déplacement paraît bureaucratique. Il est en réalité profondément protecteur, pour l’organisation comme pour la personne qui porte le sujet.

Le document qui décide de tout : la déclaration d’applicabilité

L’exigence 6.1.3 d) impose de produire une déclaration d’applicabilité. Ce document reprend les 93 mesures de l’annexe A, une par une, et pour chacune : est-elle retenue, pourquoi, où en est sa mise en œuvre, et si elle est écartée, pour quel motif.

C’est le premier document qu’ouvre un auditeur, avant tous les autres, parce qu’il constitue la carte du système de management. Pour une organisation, c’est aussi le seul document qui dise honnêtement ce qu’elle fait et ce qu’elle a choisi de ne pas faire. À ce titre, il a de la valeur même sans viser la certification.

Le piège du périmètre, et les trois questions à poser

Voici la partie qui vous servira demain matin. Le périmètre du système de management est choisi par l’organisation elle-même. Une entreprise peut parfaitement certifier un seul centre de données, une seule filiale ou une seule ligne de produit, et communiquer ensuite « certifiée ISO 27001 » sans autre précision. Ce n’est pas un mensonge, c’est une omission, et elle est courante.

Quand un fournisseur vous annonce sa certification, trois questions suffisent :

• Le certificat lui-même, et son énoncé de périmètre. Il y figure noir sur blanc. Lisez-le : couvre-t-il le service que vous achetez ?
• La déclaration d’applicabilité, et ses exclusions. Les mesures écartées et leurs motifs vous en diront plus sur la maturité réelle que n’importe quelle plaquette.
• La validité et l’organisme certificateur. Un certificat vaut trois ans, avec des audits de surveillance entre-temps. Vérifiez la date, et que l’organisme est bien accrédité.

Cinq minutes, et vous savez si la certification qu’on vous oppose couvre votre sujet ou celui du voisin.

Ce que la certification ne dit pas

Par honnêteté, et parce que c’est la contrepartie du paragraphe précédent : un certificat atteste qu’un système de management existe et fonctionne. Il n’atteste pas qu’une organisation est sûre.

Une entreprise certifiée peut avoir identifié un risque, l’avoir formellement accepté, et vous trouveriez cette acceptation déraisonnable. À l’inverse, une organisation non certifiée peut être remarquablement bien tenue. La norme garantit la rigueur de la démarche, pas le niveau des arbitrages. Confondre les deux est l’erreur la plus fréquente, des deux côtés de la table.

Ce qu’on en retient chez Humanix

• Si votre projet ISO 27001 vit entièrement à la DSI, il est déjà mal parti. Deux tiers des mesures se décident ailleurs. Le premier travail n’est pas technique, il consiste à réunir la direction, les ressources humaines, les achats, le juridique et les services généraux autour de la même table.
• Utilisez la norme comme un levier, pas comme une contrainte. Son sous-produit le plus utile pour un responsable sécurité est un registre des risques validé par la direction. Il vaut plus que bien des outils, et il coûte beaucoup moins cher.
• À l’achat, lisez le périmètre avant le logo. Trois questions, cinq minutes, et cela devrait figurer dans votre processus d’homologation fournisseur au même titre que les assurances.
• Une norme appliquée sans être comprise produit du papier, pas de la sécurité. C’est exactement pourquoi nous ne pratiquons pas l’audit-couperet. Nous expliquons le pourquoi de chaque exigence, nous la mettons en situation, et l’organisation décide ensuite en connaissance de cause. C’est le sens de notre accompagnement en gouvernance et conformité et de notre méthode immersive.

Note. Compte-rendu, à visée pédagogique, d’une intervention improvisée de la session de rumps de BarbHack 2026. Le format très court de l’original nous a conduits à l’étoffer à partir du contenu de la norme elle-même, ISO/IEC 27001:2022, dont la répartition des mesures de l’annexe A et les exigences documentaires citées ici sont issues. Cet article ne remplace ni la lecture de la norme ni l’avis d’un organisme certificateur. Quinzième volet de notre couverture de l’événement. Une démarche ISO 27001 à cadrer, ou un fournisseur dont la certification vous laisse perplexe ? Contactez-nous.