ISO/IEC 27001:2022
ISO 27001 et les tests d'intrusion
La question revient à chaque projet de certification : faut-il un pentest pour obtenir ISO 27001 ? La norme ne prononce jamais le mot. Elle exige en revanche des choses qu'on ne sait pas démontrer autrement.
ou laissez vos coordonnées :
Faisons le point sur votre situation
Trente minutes pour cadrer ce qui vous concerne réellement et par quoi commencer. Sans engagement.
La réponse courte
Non, ISO/IEC 27001 n'impose pas explicitement de test d'intrusion. Oui, en pratique, la plupart des organismes certificateurs en attendent un — parce que trois exigences de la norme n'ont pas d'autre preuve raisonnable.
Autrement dit : vous pouvez être certifié sans pentest si vous démontrez autrement l'efficacité de vos mesures. Peu d'organisations y parviennent, et celles qui essaient y passent plus de temps qu'à commander le test.
Les trois exigences qui mènent au test
- Clause 9.1 — évaluation des performances : vous devez déterminer ce qui doit être surveillé et mesuré, et démontrer l'efficacité du système de management. Un test extérieur est la mesure la plus lisible pour un auditeur.
- Annexe A 8.8 — gestion des vulnérabilités techniques : il faut obtenir l'information sur les vulnérabilités des systèmes utilisés et évaluer l'exposition. Un scan y répond partiellement, l'exploitation prouve la criticité réelle.
- Annexe A 8.29 — tests de sécurité en développement et en acceptation : les processus de test doivent être définis et mis en œuvre. Pour une application exposée, cela signifie des tests offensifs avant mise en production.
Ce que regarde l'auditeur
Un rapport de test ne suffit pas à lui seul. Ce qui emporte la décision, c'est la boucle complète.
| Ce qui est présenté | Ce que l'auditeur en fait |
|---|---|
| Un rapport de test daté | Vérifie la couverture : le périmètre testé correspond-il au périmètre certifié ? |
| La liste des vulnérabilités | Cherche leur intégration au registre des risques du système de management |
| Le plan de correction | Contrôle les délais annoncés et les décisions d'acceptation de risque, tracées |
| Le retest | Constate que les corrections critiques ont été vérifiées, pas seulement déclarées |
Le rythme attendu
La certification se déroule sur un cycle de trois ans, avec des audits de surveillance annuels. Un test annuel sur le périmètre certifié, complété après tout changement majeur — refonte applicative, migration, nouvelle exposition — couvre confortablement l'attente.
Faire un test unique la veille de l'audit initial et plus rien ensuite est le schéma qui pose problème au premier audit de surveillance.
Le lien avec NIS 2
Une organisation certifiée ISO 27001 part avec une avance considérable sur NIS 2 : la gouvernance, l'analyse de risques, la gestion des incidents et la chaîne d'approvisionnement sont déjà structurées. La certification ne vaut pas conformité NIS 2 pour autant — les délais de notification et le périmètre d'entités relèvent de la directive, pas de la norme.
Ce qu'on vous répond avant que vous demandiez.
Un scan de vulnérabilités suffit-il ?
Pour A.8.8, un scan régulier documenté peut suffire. Pour A.8.29 et pour la démonstration d'efficacité de la clause 9, un auditeur exigeant demandera une vérification manuelle : un scan ne teste ni la logique métier ni les droits.
Le test doit-il être réalisé par un tiers ?
La norme ne l'impose pas, mais elle exige l'objectivité et l'impartialité de l'évaluation. Une équipe interne qui teste ses propres développements pose une question d'indépendance que l'auditeur soulèvera.
Quel périmètre tester ?
Celui de la déclaration d'applicabilité. Un test qui couvre le site vitrine alors que le périmètre certifié porte sur la plateforme client ne prouve rien.
Un doute sur ce qui s'applique à votre situation ?
Trente minutes pour démêler ce qui vous concerne réellement — NIS 2, DORA, ISO 27001 — et par quoi commencer. Sans engagement.
Cette page est informative et ne constitue pas un conseil juridique. Les textes de référence font foi.