ISO 27001 et NIS 2 : ce que votre SMSI couvre déjà, et ce qui reste

« Nous sommes certifiés ISO 27001, donc NIS 2 est réglé. » La phrase revient dans presque chaque premier échange avec un RSSI d’une entreprise certifiée. Elle est à moitié juste, et l’autre moitié coûte cher — d’autant qu’en France, la question ne se pose pas encore dans les termes où le marché la pose.

Où en est NIS 2 en France

Cela change la manière de lire tout ce qui suit. Une directive européenne ne s’applique pas directement aux entreprises : elle engage les États membres à la transposer. Tant que la loi française n’est pas promulguée, les seuils, les secteurs, les modalités d’enregistrement et les sanctions ne sont pas fixés en droit interne. Les chiffres que vous lisez ailleurs — 24 heures, 72 heures, 2 % du chiffre d’affaires — figurent bien dans la directive, mais les présenter comme du droit français aujourd’hui est inexact. Le détail du calendrier parlementaire est dans notre article NIS 2 en France : où en est la loi Résilience.

Ce qui ne change pas, en revanche : le travail technique demandé par la directive est déjà demandé par ISO 27001, et il est déjà demandé par le RGPD. C’est la partie qui ne se reporte pas.

Deux objets de nature différente

ISO/IEC 27001 est une norme internationale décrivant un système de management de la sécurité de l’information — un SMSI. Vous définissez ce que vous protégez, vous appréciez les risques, vous choisissez des mesures, vous démontrez que le dispositif fonctionne et s’améliore. La certification est délivrée par un organisme de certification accrédité selon ISO/IEC 17021-1 ; en France, cette accréditation relève du COFRAC, seul organisme national d’accréditation. Les règles d’impartialité interdisent par ailleurs à un organisme de certifier un client qu’il a conseillé.

La directive (UE) 2022/2555 est un texte européen. Elle fixe des objectifs aux États membres, qui doivent les traduire en droit national. Son article 21 énumère des mesures de gestion des risques, son article 23 organise la notification des incidents, son article 20 vise les organes de direction.

La ligne qui compte est la deuxième. En ISO 27001, c’est vous qui délimitez le périmètre, et beaucoup de certificats couvrent un découpage soigneusement choisi. Dans la logique de la directive, c’est le service rendu qui détermine le périmètre. Si votre déclaration d’applicabilité porte sur « l’exploitation du centre de données du site de Lille » alors que le service régulé est la plateforme client dans son ensemble, vous détenez un certificat qui ne couvre pas la partie concernée.

Ce que demande l’article 21 de la directive

L’article 21, paragraphe 2, liste dix familles de mesures. Elles vous sont probablement familières : analyse des risques et politiques de sécurité ; gestion des incidents ; continuité d’activité, sauvegardes et gestion de crise ; sécurité de la chaîne d’approvisionnement ; sécurité de l’acquisition, du développement et de la maintenance, y compris le traitement des vulnérabilités ; évaluation de l’efficacité des mesures ; hygiène informatique et sensibilisation ; cryptographie et chiffrement ; sécurité des ressources humaines, contrôle d’accès et gestion des actifs ; authentification multifacteur et communications sécurisées.

Rien, dans cette liste, ne demande une technologie que vous ne connaissez pas. Ce qu’elle demande, c’est que chaque famille soit couverte, documentée et démontrable.

Où l’annexe A répond déjà

La correspondance avec ISO/IEC 27001:2022 est directe sur la quasi-totalité des familles.

Si votre SMSI vit réellement — et pas seulement la semaine de l’audit — l’essentiel du travail est derrière vous. Ce qu’il vous manque n’est pas une nouvelle structure, c’est une table de correspondance : les mêmes preuves, réétiquetées avec les renvois de la directive.

Pourquoi vous ne trouverez pas de pourcentage ici

Vous lirez souvent qu’ISO 27001 couvrirait « environ 70 % » de NIS 2. Ce chiffre circule d’un site à l’autre sans source vérifiable, et il ne veut rien dire : la couverture réelle dépend du périmètre de votre certification et de la maturité effective de vos mesures, pas d’une moyenne de marché. Un certificat étroit sur un périmètre large peut couvrir très peu. Faites la correspondance mesure par mesure, ligne à ligne ; c’est une demi-journée de travail et cela remplace utilement un chiffre emprunté.

Où le SMSI s’arrête

Trois obligations de la directive n’ont aucun équivalent dans la norme, et aucune quantité de certification ne les remplit.

1. L’enregistrement auprès de l’autorité

La directive prévoit que les entités concernées se fassent connaître de l’autorité nationale et communiquent les informations nécessaires à l’établissement des listes d’entités essentielles et importantes. Une norme ne connaît pas cette démarche, et ne peut pas la connaître : c’est un registre, pas un référentiel. En France, les modalités dépendront de la loi de transposition et de ses textes d’application. L’ANSSI a ouvert un espace en ligne permettant aux organisations de s’y préparer ; à ce stade, il ne s’agit pas d’une formalité légalement exigible.

2. Les délais de notification

L’annexe A 5.24 à 5.26 demande un processus de gestion des incidents : qui qualifie, qui décide, comment on documente. Ce que la norme ne connaît pas, c’est un délai opposable à une autorité.

L’article 23 de la directive prévoit une chaîne en trois temps : alerte précoce sous 24 heures, notification d’incident sous 72 heures, rapport final sous un mois. Votre processus existant est une bonne base, mais il lui manque une branche : qui, en quelques heures et hors horaires de bureau, décide qu’un incident est important, et qui notifie. Ce n’est pas une question de procédure, c’est une question d’horloge et d’astreinte.

3. La responsabilité des organes de direction

L’article 20 de la directive demande aux organes de direction d’approuver les mesures de gestion des risques, d’en superviser la mise en œuvre, et prévoit qu’ils acquièrent des connaissances suffisantes pour identifier les risques et apprécier les pratiques de gestion des risques. Le chapitre 5.1 de la norme demande du leadership et de l’engagement — mais il s’adresse à l’organisation, pas à la personne du dirigeant.

En pratique : l’approbation doit être tracée et s’appuyer sur quelque chose de vérifiable. Un rapport d’audit du SMSI n’y suffit pas toujours, parce qu’il décrit l’état du système de management et non la résistance réelle des systèmes. C’est aussi la raison pour laquelle des sessions de sensibilisation destinées au comité de direction ont un intérêt propre, distinct de la sensibilisation des collaborateurs.

L’écart que personne ne regarde : le périmètre

C’est le plus coûteux, et c’est le plus discret. Comparez, ligne à ligne, la déclaration d’applicabilité de votre certificat avec la description du service que la directive viserait. Les cas fréquents : un certificat qui couvre le siège et pas les filiales ; un certificat qui couvre l’infrastructure et pas l’application exposée ; un certificat hérité d’un éditeur qui couvre son produit et pas votre exploitation.

Cette vérification ne coûte rien et se fait avant toute dépense.

Le dénominateur commun : démontrer que les mesures tiennent

Il existe un point où les deux textes demandent exactement la même chose, et où l’un comme l’autre trébuche le plus souvent.

L’annexe A 8.8 demande la gestion des vulnérabilités techniques : connaître les vulnérabilités des systèmes utilisés, apprécier l’exposition, agir. L’annexe A 8.29 demande des tests de sécurité pendant le développement et à la recette. L’article 21, § 2, e) et f) de la directive demande le traitement des vulnérabilités et des procédures pour évaluer l’efficacité des mesures.

C’est le même travail dans les deux cas : identifier et prioriser les vulnérabilités en continu au moyen d’un audit de vulnérabilités, puis vérifier périodiquement, par un test d’intrusion, que les mesures arrêtent effectivement un attaquant. Un rapport, un plan de remédiation et un contre-audit produisent les deux jeux de preuves en une seule opération — à condition que le rapport rattache chaque constat à l’exigence correspondante. C’est précisément ce que nous livrons pour ISO 27001 et pour NIS 2.

La différence entre un scan outillé et un test manuel est détaillée dans Scan de vulnérabilités ou test d’intrusion.

Et un troisième texte, celui-là applicable aujourd’hui

Pendant que la transposition suit son cours, l’article 32 du RGPD s’applique déjà, directement, à tout traitement de données à caractère personnel. Il demande notamment « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». La CNIL est compétente et sanctionne sur ce fondement. Le même test d’intrusion sert donc trois cadres à la fois : la norme, la directive à venir, et une obligation qui, elle, est en vigueur.

Faut-il un prestataire qualifié par l’ANSSI ?

La question revient systématiquement, et la réponse tient en une phrase de l’ANSSI elle-même, dans sa foire aux questions consacrée à NIS 2 :

« Il peut être pertinent de recourir si besoin aux prestataires ou solutions qualifiés par l’ANSSI mais cela n’est pas une obligation. »

Disons-le clairement de notre côté : Haxoris n’est pas un prestataire qualifié PASSI. La qualification PASSI est une démarche volontaire délivrée par l’ANSSI au titre du décret n° 2015-350 du 27 mars 2015. Elle n’est pas requise pour un test d’intrusion commandé par une entreprise privée. En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations.

Il faut ajouter une réserve honnête : la loi de transposition et ses textes d’application pourront préciser ce point pour certains secteurs. Nous suivons ce point et mettons cette page à jour.

Le cas des entités financières

Une précision que le marché confond souvent. Le règlement (UE) 2022/2554 (DORA) constitue un régime distinct pour les entités financières, avec ses propres exigences de test. La directive NIS 2 prévoit d’ailleurs qu’un acte sectoriel de l’Union imposant des exigences au moins équivalentes prend le pas sur elle.

Les tests d’intrusion fondés sur la menace prévus par DORA relèvent d’un dispositif spécifique, encadré en France dans le cadre TIBER-FR porté par la Banque de France, avec des critères propres quant à qui peut réaliser le test. Ce n’est pas notre offre, et nous le disons plutôt que de laisser l’ambiguïté : vendre de la « conformité NIS 2 » à une banque ou à un assureur, c’est désigner le mauvais régime.

Si vous détenez déjà le certificat

1. Comparez les périmètres. Votre déclaration d’applicabilité couvre-t-elle le service qui serait visé ? C’est l’écart le plus fréquent et le plus lourd de conséquences.
2. Construisez la table de correspondance. Article 21 en colonne de gauche, annexe A en colonne de droite. Pour l’essentiel, vous n’aurez qu’à reporter la référence d’une preuve existante.
3. Complétez les trois manques. Chaîne de notification avec les délais de l’article 23, préparation de l’enregistrement, approbation tracée par la direction.
4. Démontrez l’efficacité. Le test d’intrusion que vous réalisez de toute façon pour 8.29 couvre aussi le f) de l’article 21, si le rapport le dit.

Pour une organisation dont le SMSI fonctionne, l’effort réaliste se compte en semaines, et il est majoritairement documentaire.

Si vous ne l’avez pas

Il n’existe aucune obligation de certification : la directive demande des mesures, pas une norme. L’annexe A reste malgré tout le plan de construction le plus praticable, parce qu’elle traduit des objectifs en mesures que quelqu’un a déjà rédigées et éprouvées.

Deux chemins, tous deux défendables :

• Avec certification, si vous avez de toute façon besoin de la preuve pour les questionnaires fournisseurs et les appels d’offres. Le cycle de certification s’étend habituellement sur trois ans, avec des audits de surveillance annuels.
• Sans certification, en utilisant l’annexe A comme structure. Vous économisez l’audit et vous perdez l’argument commercial.

Dans les deux cas, la partie technique est identique, et c’est celle qui ne se reporte pas : il faut pouvoir montrer que les mesures tiennent.

Ce que nous faisons, et ce que nous ne faisons pas

Nous ne sommes pas un organisme de certification. Un certificat ISO/IEC 27001 est délivré par un organisme de certification accrédité ; en France, l’accréditation relève du COFRAC et la liste des organismes accrédités est publique. Nous ne délivrons aucun certificat et ne réalisons aucun audit de certification.

Ce que nous apportons est la matière technique : un test d’intrusion orienté sur les mesures de l’annexe A — 8.8 et 8.29 en particulier — avec un rapport exploitable par votre auditeur, un audit interne ISO 27001 ou un audit à blanc avant le passage de l’organisme certificateur, et un contre-audit inclus, sans surcoût qui démontre que les constats ont été corrigés. Pour le volet réglementaire, la preuve est la même : voir préparation à NIS 2. Et si l’exercice doit porter sur l’organisation autant que sur la technique, c’est l’objet d’un audit de sécurité informatique.

Haxoris est un prestataire européen : vos données et vos rapports restent dans l’Union européenne, et vous savez nommément qui réalise le test.

ISO 27001 et NIS 2 — questions fréquentes

Vous souhaitez savoir où s’arrête votre certificat et où commencerait la directive ? Décrivez-nous votre périmètre et demandez un devis.

Nos services associés : tests d’intrusion pour préparer la certification ISO 27001 · tests d’intrusion pour préparer la directive (UE) 2022/2555 (NIS 2) · tests d’intrusion sur vos applications et vos infrastructures · audit de vulnérabilités de vos systèmes et de vos applications