NIS2 et ISO 27001 : réutiliser les mesures, examiner les écarts

Un programme ISO 27001 peut fournir une structure opérationnelle solide pour NIS2 : appréciation des risques, responsables désignés, mesures, preuves et amélioration. L’étape suivante consiste à évaluer, exigence par exigence, ce que cette structure couvre réellement.

Pour un directeur technique, la question utile n’est pas de savoir si les référentiels se recoupent. Elle est de savoir si une mesure mise en œuvre protège le service concerné, satisfait à l’obligation applicable et produit des preuves qui étayent cette conclusion. Réutilisez la mise en œuvre lorsque ces conditions sont remplies ; préservez les différences juridiques et opérationnelles lorsqu’elles ne le sont pas.

Comprendre ce qu’établit chaque référentiel

L’ISO/IEC 27001 spécifie les exigences applicables à un système de management de la sécurité de l’information (SMSI) au périmètre défini. Les articles 4 à 10 traitent de sa structure de management, y compris le traitement des risques, l’évaluation des performances et l’amélioration. L’annexe A contient 93 mesures de référence réparties entre les catégories organisationnelle, humaine, physique et technologique. L’applicabilité des mesures est fondée sur les risques ; il ne s’agit pas d’une obligation de mettre en œuvre chaque mesure de manière identique. L’ISO 27002 fournit des recommandations de mise en œuvre.

NIS2 est une directive de l’UE mise en œuvre par le droit national. L’applicabilité dépend du secteur, de la taille, du service et de règles d’inclusion spécifiques. Les annexes I et II identifient les secteurs concernés, mais le secteur ne détermine pas à lui seul si une organisation est une entité essentielle ou importante. Certaines entités sont couvertes quelle que soit leur taille.

Les différences pratiques sont les suivantes :

La certification est réalisée par des organismes de certification indépendants, et non par l’ISO. Elle n’établit pas la conformité à NIS2, et NIS2 n’exige généralement pas de certification ISO 27001. Le contrôle du respect peut comprendre des mesures de supervision et des sanctions ; la certification ISO poursuit une finalité d’assurance différente.

Commencer par faire coïncider les périmètres

Comparez le périmètre certifié du SMSI avec les entités juridiques et les services soumis à NIS2. Un certificat couvrant une équipe de développement peut laisser hors de son périmètre l’exploitation de la production, une autre filiale ou des sites supplémentaires.

Établissez une comparaison des périmètres consignant :

• Les entités juridiques, pays et services couverts, ainsi que le fondement de leur inclusion.
• Les systèmes, réseaux, sites et fournisseurs de soutien pertinents.
• Le périmètre du SMSI, le périmètre du certificat et les exclusions.
• Les exigences nationales, règles sectorielles et autorités responsables applicables, y compris les obligations d’enregistrement, les informations requises sur l’entité, les canaux de soumission et les obligations de mise à jour.
• Qui a approuvé l’évaluation d’applicabilité et quand elle doit être réexaminée.

Distinguez un écart de périmètre d’un écart de mesures. Un environnement de production hors du SMSI peut déjà disposer de bonnes mesures de contrôle d’accès, mais ces mesures ont toujours besoin d’un responsable, d’une évaluation et de preuves dans le cadre du chantier NIS2.

Vérifiez la législation sectorielle avant de dupliquer des obligations. L’article 4 traite de l’articulation avec les actes juridiques sectoriels de l’Union. Pour les entités financières, l’articulation avec DORA exige une analyse propre au rôle. Pour les activités en Allemagne, consultez les informations du BSI sur NIS2 plutôt que de supposer que les obligations KRITIS existantes et les obligations NIS2 sont identiques.

Mettre en correspondance les mesures mises en œuvre, pas des intitulés concordants

L’article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. Ses dix domaines de mesures minimales constituent un point de départ pour la mise en correspondance, mais une formulation similaire est une piste utile, et non une preuve d’équivalence.

Utilisez ce qui suit comme points de revue, et non comme des déclarations de couverture automatiques :

La déclaration d’applicabilité consigne les mesures nécessaires et la justification de leur inclusion ou exclusion. Elle n’est pas interchangeable avec le plan de traitement des risques, les constats d’audit interne ou les comptes rendus de revue de direction. Utilisez ces documents ensemble pour expliquer à la fois la conception et le fonctionnement.

Une politique établit des attentes. Un export de configuration peut montrer la mise en œuvre. Les résultats des revues des accès, les tickets de remédiation et les comptes rendus de tests peuvent montrer le fonctionnement. Ne réutilisez des preuves que lorsque le système, la période et l’objectif de l’évaluation concordent.

Évitez les pourcentages de recoupement figés. La couverture dépend de la mise en œuvre et du périmètre juridique ; un chiffre universel ne peut pas établir l’état de préparation.

Construire un circuit de notification des incidents capable de fonctionner sous pression

Un plan de réponse aligné sur l’ISO peut soutenir la détection, le confinement, l’investigation et la reprise sans définir de notification réglementaire. L’article 23 de NIS2 ajoute des obligations de notification pour les incidents importants.

Les étapes de notification de la directive comprennent généralement :

• Une alerte précoce, dans les meilleurs délais et dans les 24 heures suivant la prise de connaissance d’un incident important.
• Une notification d’incident, dans les meilleurs délais et dans les 72 heures, qui met à jour l’alerte précoce et fournit une évaluation initiale.
• Un rapport final, en général dans un délai d’un mois après la présentation de la notification d’incident. Pour un incident en cours, un rapport d’avancement est requis à ce moment-là, le rapport final étant dû dans un délai d’un mois après le traitement de l’incident.

Un rapport intermédiaire doit également être fourni à la demande du CSIRT ou de l’autorité compétente.

Vérifiez les règles nationales et sectorielles applicables : la directive prévoit un délai de notification différent pour les prestataires de services de confiance. N’utilisez pas un seuil générique d’indisponibilité en lieu et place des critères d’importance applicables.

À titre de recommandation pratique de mise en œuvre, créez une procédure de notification précisant le responsable de l’évaluation, la voie d’escalade, la personne habilitée à soumettre, les suppléants, le canal de l’autorité et les informations nécessaires à chaque étape. Consignez distinctement les horodatages de détection, de prise de connaissance, d’évaluation de l’importance et de soumission.

Exercez le processus avec des informations incomplètes. L’équipe doit pouvoir soumettre le premier rapport requis sans attendre la fin d’une investigation forensique. Conservez les versions soumises, les accusés de réception, les faits à l’appui et les décisions sur le franchissement du seuil.

Lorsqu’un autre régime de notification s’applique également, coordonnez l’investigation mais évaluez chaque obligation de notification séparément. Un enregistrement d’incident commun ne rend pas identiques les destinataires, les déclencheurs ou les délais.

Rendre la gouvernance et la résilience démontrables

L’article 20 exige que les organes de direction approuvent les mesures de gestion des risques en matière de cybersécurité et supervisent leur mise en œuvre. Il traite aussi de la formation des membres des organes de direction. Une revue de direction existante est une preuve utile, mais vérifiez si elle consigne explicitement les approbations, la supervision, les décisions et le suivi pertinents.

Donnez à la direction une vue permettant de décider : services concernés, risques significatifs, options de traitement, exceptions non résolues et résultats d’efficacité. Des procès-verbaux indiquant simplement « sécurité abordée » ne prouvent guère une supervision effective. Attribuez à chaque action approuvée un responsable et une date de revue.

La continuité exige un traitement tout aussi concret. L’article 21 inclut les sauvegardes, la reprise après sinistre et la gestion de crise ; il n’impose pas de certification ISO 22301 universelle. Déterminez le niveau de profondeur nécessaire à partir du service, des risques et des règles applicables.

Testez la restauration et la reprise du service, et pas seulement l’achèvement des tâches de sauvegarde. Incluez des dépendances telles que les services d’identité, le DNS, le support des fournisseurs, les identifiants à privilèges et les communications lorsque l’environnement habituel est indisponible. Consignez les résultats de reprise obtenus et les blocages non résolus par rapport aux objectifs convenus.

Tenir un registre des écarts visible

Pour chaque exigence, consignez sa source et sa version, les mesures mises en correspondance, le périmètre, les références des preuves, le réviseur et la justification de la réutilisation. Distinguez la couverture étayée, la couverture partielle, la mise en œuvre manquante, les preuves manquantes et une décision motivée de non-applicabilité. L’absence d’un document ne signifie pas toujours l’absence d’une mesure, mais elle exige une investigation.

Chaque écart nécessite un responsable, une modification requise, une attente en matière de preuves, une échéance et un réviseur de clôture. Donnez la priorité aux défaillances qui menacent les services ou empêchent une notification urgente plutôt que de traiter chaque tâche documentaire comme également urgente.

Parmi les erreurs courantes figurent la mise en correspondance de la seule annexe A en négligeant les exigences de gouvernance, l’acceptation d’un certificat de fournisseur sans vérifier son périmètre, le fait de considérer les preuves de l’année précédente comme actuelles et la clôture d’une tâche lorsqu’une politique est publiée alors que le processus n’a pas été testé. Un enregistrement ou une certification ne doit jamais être considéré comme une preuve de mise en œuvre opérationnelle.

Exemple concret : étendre un SMSI existant

Hypothèses illustratives : un prestataire de services gérés dispose d’un SMSI certifié ISO 27001 couvrant son équipe opérationnelle principale. Son évaluation d’applicabilité conclut qu’un service exploité par une entité juridique supplémentaire est soumis à NIS2. Cette entité utilise la même plateforme d’identité et la même équipe de gestion des incidents, mais des dispositifs de reprise distincts.

L’équipe compare d’abord les limites des services. Les configurations d’authentification existantes peuvent soutenir les deux périmètres, mais le réviseur vérifie si les administrateurs, comptes d’urgence et comptes de service de l’entité supplémentaire sont inclus. Un export de revue des accès couvrant uniquement l’équipe d’origine ne peut pas prouver une couverture complète.

Ensuite, le responsable des incidents conserve la procédure de réponse établie et y ajoute une évaluation des incidents importants et un circuit de notification à l’autorité. Un exercice sur table simule une panne d’un fournisseur dont l’impact sur les clients est incertain. Les participants consignent le moment où ils ont pris connaissance des faits pertinents, qui a décidé de l’importance de l’incident et comment une alerte précoce serait soumise.

Enfin, le responsable de l’infrastructure organise un exercice de reprise pour le service de l’entité supplémentaire. Le test révèle que les identifiants de reprise dépendent de la plateforme d’identité indisponible. Le registre des écarts attribue une action corrective et exige un nouveau test réussi avant la clôture.

Les livrables qui en résultent sont une comparaison des périmètres, des correspondances revues, des preuves de revue des accès étendues, des comptes rendus d’exercice de notification, des résultats de reprise et l’approbation par la direction des actions de traitement en suspens. Les mesures communes restent communes ; les preuves et décisions propres à l’entité restent visibles.

Transformer l’évaluation en travail entretenu

Le modèle d’exigences et de preuves reliées de Secani offre aux équipes une structure pour préserver le travail commun et les décisions propres à chaque référentiel. Modélisez les services et les dépendances, rattachez les preuves existantes aux mesures pertinentes et transformez la couverture manquante en tâches attribuées. Gardez une validation humaine explicite pour les correspondances et les conclusions tirées des preuves, y compris pour les suggestions assistées par l’IA. Notre guide sur la mise en correspondance traçable entre référentiels explique comment conserver la justification de la réutilisation.

Commencez par un service réglementé. Réunissez son périmètre, son traitement des risques, sa déclaration d’applicabilité, sa procédure de gestion des incidents et ses preuves de tests récentes dans une revue conjointe technique et conformité. Produisez un registre des écarts revu, puis utilisez les cycles de revue habituels du SMSI pour le tenir à jour à mesure que les services, les fournisseurs et les exigences évoluent.