Cartographie NIS2 2024/2690 vers ISO 27001 pour prestataires cloud

À 08 h 17, un mardi, Maria, RSSI d’un prestataire européen de services gérés, reçoit l’alerte que redoutent tous les MSP. Un compte de gestion à distance à privilèges a déclenché des alertes de déplacement impossible. Deux tenants clients présentent des actions d’administration anormales. Le SOC a déjà ouvert une cellule de crise pour incident critique.

À 09 h 00, le directeur général rejoint l’appel. Les questions changent immédiatement.

Sommes-nous dans le champ d’application de NIS2 ? Le règlement d’exécution (UE) 2024/2690 de la Commission s’applique-t-il à nous ? Devons-nous émettre une alerte précoce sous 24 heures ? Quels clients doivent être notifiés ? Pouvons-nous démontrer que l’authentification multifacteur, la journalisation, la segmentation, la gestion des vulnérabilités, les contrôles fournisseurs et l’escalade des incidents fonctionnaient avant l’incident ?

L’entreprise de Maria est certifiée ISO/IEC 27001:2022. Elle fournit de la gestion cloud, des services de centre de données et du support de sécurité géré à des clients qui incluent un prestataire logistique et une banque régionale. Le certificat compte, mais il ne répond pas à lui seul aux questions opérationnelles. L’équipe juridique dispose d’un projet de processus de notification. Le responsable conformité a une feuille de calcul. L’auditeur a demandé la Déclaration d’applicabilité, les tests de réponse aux incidents, les journaux d’accès à privilèges, les diligences préalables relatives aux fournisseurs, les éléments de preuve relatifs au modèle de responsabilité partagée du cloud et les hypothèses de continuité d’activité.

C’est le moment où NIS2 cesse d’être un texte juridique et devient un problème de contrôle opérationnel.

Pour les fournisseurs de services d’informatique en nuage, les prestataires de services gérés, les prestataires de services de sécurité gérés et les fournisseurs de centres de données, NIS2 et le règlement d’exécution 2024/2690 font passer le niveau d’exigence d’une intention générale de sécurité à des éléments de preuve de contrôle vérifiables. Gouvernance, gestion des risques, contrôle d’accès, gestion des actifs, traitement des vulnérabilités, réponse aux incidents, sécurité des fournisseurs, journalisation, surveillance, chiffrement, continuité d’activité et résilience physique doivent fonctionner comme un système unique.

ISO/IEC 27001:2022 constitue la meilleure ossature pour ce système, à condition que l’organisation cartographie les exigences NIS2 dans le SMSI, le registre des risques, la Déclaration d’applicabilité, les politiques et le modèle d’éléments de preuve. Un certificat affiché au mur ne suffit pas. Le travail réel consiste à construire un fil conducteur auditable entre la réglementation et le risque, du risque à la mesure de sécurité, de la mesure de sécurité à la politique, puis de la politique aux éléments de preuve opérationnels.

Pourquoi NIS2 2024/2690 transforme la discussion sur la conformité des prestataires cloud et MSP

NIS2 utilise un modèle fondé sur le secteur et la taille, mais ses catégories relatives à l’infrastructure numérique et à la gestion des services TIC sont volontairement larges. En vertu de NIS2 Article 2 et Article 3, lus conjointement avec Annexe I et Annexe II, de nombreuses organisations peuvent être qualifiées d’entités essentielles ou importantes, notamment les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les prestataires de services gérés, les prestataires de services de sécurité gérés, les fournisseurs DNS, les registres TLD, les réseaux de diffusion de contenu et les prestataires de services de confiance. Les États membres doivent établir et revoir périodiquement les listes des entités essentielles et importantes, la première échéance étant fixée au 17 avril 2025.

Cet enjeu est déterminant, car les fournisseurs cloud, MSP, MSSP et centres de données se situent dans les chaînes de risque d’autres organisations. Une compromission du plan de contrôle cloud peut affecter des milliers de systèmes clients. Une interruption de centre de données peut se propager à la banque, à la santé, à la logistique et à l’administration publique. Une compromission d’identifiants MSP peut devenir un événement de rançongiciel multi-client. Une défaillance de détection chez un MSSP peut retarder le confinement chez des clients réglementés.

NIS2 Article 20 impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité et d’en superviser la mise en œuvre. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, fondées sur une approche tous risques. Le socle inclut l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition et le développement sécurisés, le traitement et la divulgation des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur ou l’authentification continue, les communications sécurisées et les communications d’urgence.

Article 23 ajoute un signalement progressif des incidents significatifs, comprenant une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures, des rapports intermédiaires sur demande et un rapport final dans un délai d’un mois après la notification ou après la gestion de l’incident lorsque l’incident est toujours en cours.

Le règlement d’exécution 2024/2690 rend ces attentes plus concrètes pour les prestataires numériques concernés. En pratique, les autorités, les clients et les auditeurs ne demanderont pas seulement si des politiques existent. Ils demanderont si les contrôles sont cartographiés, attribués, testés et étayés par des éléments de preuve.

ISO/IEC 27001:2022 transforme NIS2 en contexte opérationnel du SMSI

Une erreur courante de préparation à NIS2 consiste à partir d’une longue liste de contrôle et à répartir les tâches entre l’informatique, le juridique, le SOC, l’infrastructure, la gestion des fournisseurs et la conformité. Cela peut générer de l’activité, mais échoue souvent en audit, car personne ne peut démontrer pourquoi les contrôles ont été retenus, comment ils se rattachent au risque, qui a accepté le risque résiduel et quels éléments de preuve démontrent leur efficacité.

ISO/IEC 27001:2022 fournit aux prestataires la structure nécessaire pour éviter cet échec.

Les clauses 4.1 à 4.4 exigent que l’organisation détermine les enjeux internes et externes, identifie les parties intéressées et leurs exigences, décide quelles exigences seront prises en compte dans le SMSI et définisse le périmètre du SMSI, y compris les interfaces et dépendances. Pour un fournisseur cloud ou MSP, le périmètre doit explicitement prendre en compte NIS2, le règlement d’exécution 2024/2690, les annexes de sécurité client, les exigences client issues de DORA, les régions cloud, les sous-traitants, les dépendances de centres de données, les plateformes de gestion à distance, les chemins d’accès à privilèges et les obligations de notification des incidents.

Les clauses 5.1 à 5.3 exigent le leadership, l’alignement des politiques, les ressources, la communication, les responsabilités attribuées et la responsabilité de la direction. Cela soutient directement NIS2 Article 20.

Les clauses 6.1.1 à 6.1.3 exigent l’appréciation des risques, le traitement des risques, les propriétaires de risques, l’analyse de la vraisemblance et des conséquences, la sélection des mesures de sécurité, la comparaison avec Annexe A, une Déclaration d’applicabilité, un plan de traitement des risques et l’acceptation formelle du risque résiduel. C’est à ce niveau que NIS2 devient opérationnelle. Chaque exigence réglementaire devient un facteur de risque, une obligation de conformité, une exigence de contrôle ou une exigence d’éléments de preuve.

Clarysec amorce ce travail avec Zenith Blueprint : la feuille de route en 30 étapes de l’auditeur Zenith Blueprint, en particulier la phase Gestion des risques.

À partir de l’étape 13, Planification du traitement des risques et Déclaration d’applicabilité, Zenith Blueprint demande aux équipes d’établir la traçabilité entre les risques, les contrôles et les facteurs réglementaires :

« Référencer les réglementations : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez l’indiquer soit dans le registre des risques, soit dans les notes de la SoA. Par exemple, le contrôle 8.27 (effacement sécurisé des données) peut être très pertinent pour l’exigence GDPR relative à l’élimination des données à caractère personnel ; vous pourriez indiquer “Applicable – soutient GDPR Art.32 (sécurité du traitement)”. Cela n’est pas exigé par ISO, mais contribue à démontrer que vous avez pris ces référentiels en compte. »

L’étape 14, Politiques de traitement des risques et références croisées réglementaires, ajoute la discipline pratique de cartographie :

« Pour chaque réglementation, le cas échéant, vous pouvez créer un tableau de cartographie simple qui répertorie les principales exigences de sécurité de la réglementation et les contrôles/politiques correspondants dans votre SMSI. Ce n’est pas obligatoire dans ISO 27001, mais c’est un exercice interne utile pour s’assurer que rien n’a été oublié. »

C’est la différence entre affirmer « nous sommes certifiés ISO » et prouver « notre SMSI ISO/IEC 27001:2022 couvre le règlement d’exécution NIS2 2024/2690 ».

Cartographie unifiée NIS2 vers les contrôles ISO/IEC 27001:2022

La cartographie suivante ne constitue pas un conseil juridique et ne remplace pas l’analyse de transposition nationale. Il s’agit d’une architecture de contrôle pratique pour les prestataires qui ont besoin d’un chemin ISO/IEC 27001:2022 auditable vers la préparation à NIS2.

Cette cartographie devient puissante lorsqu’elle est intégrée au registre des risques et à la Déclaration d’applicabilité. Par exemple, un prestataire peut créer un scénario de risque intitulé « La compromission d’une plateforme de gestion à distance entraîne des actions non autorisées dans les environnements clients ». Les contrôles incluent l’authentification multifacteur, la gestion des accès à privilèges (PAM), la segmentation, la journalisation, la gestion des vulnérabilités, la sécurité des fournisseurs, la planification des incidents et les procédures de notification client. Les notes de la SoA peuvent référencer NIS2 Article 21, Article 23, le règlement d’exécution 2024/2690, les contrats clients et les exigences de diligences préalables clients liées à DORA, le cas échéant.

Gouvernance cloud : le contrôle ISO 5.23 comme ancrage NIS2

Pour les prestataires cloud et les MSP qui utilisent des services cloud afin de fournir des services à leurs clients, le contrôle 5.23 de l’Annexe A ISO/IEC 27001:2022, Sécurité de l’information pour l’utilisation des services cloud, est l’un des ancrages les plus importants.

Zenith Controls : le guide de conformité croisée Zenith Controls résume le contrôle 5.23 comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, lié à la sécurité des relations fournisseurs, à la gouvernance, au risque d’écosystème et à la protection. Il couvre la gouvernance des services cloud, la responsabilité partagée, l’évaluation des prestataires, les inventaires, la localisation des données, la journalisation, le chiffrement, les rôles d’identité, la surveillance, les clauses contractuelles, le risque fournisseur, la sortie du cloud et la planification de la résilience.

La phase Controls in Action de Zenith Blueprint, étape 23, explique la raison opérationnelle :

« Le cloud n’est plus une destination, c’est le mode par défaut. Le contrôle 5.23 reconnaît cette réalité et exige que la sécurité de l’information soit explicitement traitée dans la sélection, l’utilisation et la gestion des services cloud, non pas comme une réflexion a posteriori, mais comme un principe de conception dès le départ. »

Pour un MSP, chaque plateforme de surveillance et d’administration à distance, portail client, outil de ticketing, plateforme de télémétrie de sécurité, service de sauvegarde, annuaire cloud et console d’administration SaaS doit être gouverné. Pour un fournisseur de centre de données, la gouvernance cloud peut s’appliquer aux plateformes de surveillance, systèmes de gestion des visiteurs, intégrations de contrôle d’accès physique, systèmes de gestion à distance et infrastructures de portail client.

La Politique d’utilisation du cloud Enterprise de Clarysec Politique d’utilisation du cloud rend obligatoire la diligence préalable avant activation :

« Toute utilisation du cloud doit faire l’objet de diligences préalables fondées sur les risques avant activation, incluant l’évaluation du fournisseur, la validation de la conformité juridique et les revues de validation des contrôles. »

Extrait de la section « Exigences de gouvernance », clause de politique 5.2.

Pour les prestataires de plus petite taille, la Cloud Usage Policy-sme Cloud Usage Policy-sme - PME crée un modèle d’approbation allégé :

« Toute utilisation de services cloud doit être revue et approuvée par le directeur général (DG) avant mise en œuvre ou souscription. »

Extrait de la section « Exigences de gouvernance », clause de politique 5.1.

Les deux approches soutiennent la même attente NIS2 : le risque de dépendance au cloud doit être compris avant que le service n’entre dans la chaîne de fourniture.

Réponse aux incidents : l’horloge de 24 heures démarre avant la rédaction du rapport

NIS2 Article 23 est strict, car le délai de signalement commence à compter de la prise de connaissance d’un incident significatif, et non au moment où une analyse parfaite de la cause racine est disponible. Le défi pour les prestataires consiste à déterminer rapidement si un événement est significatif, quels clients sont affectés, si des données à caractère personnel sont concernées, s’il existe un impact transfrontalier sur les services et quels délais contractuels ont commencé à courir.

Le contrôle 5.24 de l’Annexe A ISO/IEC 27001:2022, Planification et préparation de la gestion des incidents de sécurité de l’information, est le contrôle de planification. Zenith Controls le résume comme un contrôle correctif soutenant la confidentialité, l’intégrité et la disponibilité, lié aux concepts Respond and Recover, à la gouvernance, à la gestion des événements et à la défense. Il inclut les rôles, responsabilités, circuits d’escalade, protocoles de communication, préparation aux notifications réglementaires, alignement avec la journalisation et la surveillance, intégration avec la continuité d’activité et la reprise après sinistre, apprentissage post-incident et cartographie vers NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 et COBIT 2019.

La Politique de réponse aux incidents-sme de Clarysec Incident Response Policy-sme - PME transforme la première décision en exigence bornée dans le temps :

« Le directeur général, avec les contributions du prestataire informatique, doit classifier tous les incidents par gravité dans l’heure suivant la notification. »

Extrait de la section « Exigences de gouvernance », clause de politique 5.3.1.

Cette classification en une heure soutient la discipline opérationnelle nécessaire à l’analyse d’alerte précoce NIS2 sous 24 heures, à l’évaluation des violations de données à caractère personnel au titre de GDPR, à l’escalade client DORA et au triage des notifications contractuelles.

L’arbre de décision incident d’un prestataire doit répondre à quatre questions :

1. Existe-t-il une compromission confirmée ou suspectée de la confidentialité, de l’intégrité ou de la disponibilité ?
2. L’événement affecte-t-il la fourniture de service, les environnements clients, des clients réglementés, des données à caractère personnel ou des fonctions critiques ?
3. Peut-il causer une perturbation opérationnelle grave, une perte financière ou un dommage matériel ou immatériel ?
4. Quelles obligations de notification s’appliquent : NIS2, GDPR, obligations client DORA, SLA contractuels ou attentes de l’autorité nationale de régulation ?

L’arbre de décision doit être testé lors d’exercices sur table avant un incident réel.

Gestion des vulnérabilités : prouver la réduction du risque avant l’impact

NIS2 exige le traitement et la divulgation des vulnérabilités. Pour les clients et les autorités de régulation, la gestion des vulnérabilités est l’un des domaines de contrôle les plus faciles à mesurer, car elle produit des éléments de preuve clairs : couverture des scans, délais de correction, approbations d’exceptions, analyse des vulnérabilités exploitées et enregistrements de remédiation.

Le contrôle 8.8 de l’Annexe A ISO/IEC 27001:2022, Gestion des vulnérabilités techniques, est résumé dans Zenith Controls comme un contrôle préventif couvrant la confidentialité, l’intégrité et la disponibilité, lié à Identify and Protect, à la gestion des menaces et des vulnérabilités, à la gouvernance, à l’écosystème, à la protection et à la défense. Il inclut l’identification, l’évaluation, la priorisation des vulnérabilités, l’application des correctifs, les contrôles compensatoires, l’intégration du renseignement sur les menaces, la divulgation des vulnérabilités, les responsabilités relatives aux vulnérabilités cloud et applicatives, les éléments probants d’audit et les délais de remédiation.

La Politique de gestion des vulnérabilités et des correctifs Enterprise de Clarysec Politique de gestion des vulnérabilités et des correctifs donne aux auditeurs un modèle concret à tester :

« L’organisation doit classifier toutes les vulnérabilités détectées selon une méthodologie normalisée (p. ex. CVSS v3.x) et appliquer des délais de remédiation alignés sur la criticité métier : 5.2.1 Critique (CVSS 9.0-10.0) : revue immédiate ; délai maximal d’application du correctif de 72 heures. 5.2.2 Élevée (7.0-8.9) : réponse dans les 48 heures ; délai d’application du correctif de 7 jours calendaires. 5.2.3 Moyenne (4.0-6.9) : réponse dans les 5 jours ; délai d’application du correctif de 30 jours calendaires. 5.2.4 Faible (<4.0) : réponse dans les 10 jours ; délai d’application du correctif de 60 jours calendaires. »

Extrait de la section « Exigences de gouvernance », clause de politique 5.2.

Pour un fournisseur cloud, cela doit couvrir les composants d’hyperviseur, les images de conteneurs, les couches d’orchestration, les interfaces de programmation (API) exposées aux clients, les pipelines CI/CD, les consoles d’administration et les bibliothèques tierces. Pour un MSP, la question clé est de savoir si les vulnérabilités internes sont séparées des vulnérabilités gérées par les clients et si les contrats définissent les responsabilités. Pour un fournisseur de centre de données, le périmètre peut inclure les systèmes de gestion technique du bâtiment, les systèmes de contrôle d’accès, les plateformes de surveillance, les outils d’intervention à distance et l’infrastructure réseau.

Le modèle de responsabilité partagée doit être documenté. Un prestataire ne maîtrise pas nécessairement tous les correctifs, mais il doit tout de même gérer le risque, notifier le client lorsque cela est approprié et prouver que les limites de responsabilité sont comprises.

Journalisation, surveillance et segmentation rendent les incidents investigables

Lorsqu’un incident fournisseur a un impact client, les premières questions relatives aux éléments de preuve sont simples : qui s’est connecté, depuis où, avec quel privilège, vers quel tenant, qu’est-ce qui a changé, quels journaux existent et les chemins d’administration étaient-ils segmentés ?

La Politique de journalisation et de surveillance Enterprise de Clarysec Politique de journalisation et de surveillance exige que les systèmes couverts génèrent les journaux nécessaires aux intervenants et aux auditeurs :

« Tous les systèmes couverts doivent générer des journaux capturant : 6.1.1.1 Les tentatives d’authentification et d’accès utilisateur 6.1.1.2 Les activités des utilisateurs à privilèges 6.1.1.3 Les modifications de configuration 6.1.1.4 Les tentatives d’accès échouées ou événements système 6.1.1.5 Les détections de logiciels malveillants et alertes de sécurité 6.1.1.6 Les communications externes et déclencheurs de règles de pare-feu »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.

Pour les PME qui s’appuient sur des prestataires externes, la Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - PME ajoute une exigence contractuelle :

« Les contrats doivent exiger des prestataires qu’ils conservent les journaux pendant au moins 12 mois et fournissent l’accès sur demande. »

Extrait de la section « Exigences de gouvernance », clause de politique 5.5.1.3.

La segmentation est tout aussi importante. La Network Security Policy-sme Network Security Policy-sme - PME stipule :

« Les réseaux internes doivent être segmentés par fonction (p. ex., finances, invité, IoT, systèmes administratifs). »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.

La phase Controls in Action de Zenith Blueprint, étape 20, fournit la procédure d’audit pratique pour l’architecture réseau et la segmentation. Elle demande aux équipes de revoir et documenter l’architecture réseau, de vérifier les règles de pare-feu, les configurations IPS/IDS et d’accès à distance, de confirmer que les groupes de sécurité cloud et les règles VPC ou de sous-réseaux correspondent à l’architecture prévue, de lister les services réseau internes et externes et de valider que les systèmes sensibles ne sont pas accessibles depuis les VLAN utilisateurs généraux ou les réseaux invités.

Pour un MSP, les outils de gestion à distance ne doivent pas être placés à plat sur le réseau bureautique. Pour un fournisseur de centre de données, les interfaces de gestion de l’alimentation, du refroidissement, du contrôle d’accès et des services réseau clients doivent être isolées et surveillées. Pour un fournisseur cloud, l’accès au plan de contrôle doit être restreint par l’identité, le réseau, le niveau de sécurité des équipements et des contrôles de flux de travail à privilèges.

Sécurité des fournisseurs : le prestataire est aussi un client

Les fournisseurs cloud, MSP, MSSP et centres de données sont des fournisseurs pour des clients réglementés, mais ils sont aussi clients d’éditeurs logiciels, d’opérateurs télécoms, de fournisseurs d’identité, de plateformes SaaS, de fournisseurs matériels, de sous-traitants et d’opérateurs d’infrastructure.

NIS2 fait de la sécurité de la chaîne d’approvisionnement une exigence centrale. DORA, applicable à compter du 17 janvier 2025, place la gestion des risques liés aux tiers TIC au cœur des obligations des entités financières. NIS2 Article 4 et le considérant 28 reconnaissent DORA comme l’acte juridique sectoriel spécifique de l’Union pour les entités financières lorsque les exigences se recoupent. Cela ne réduit pas la pression sur les fournisseurs cloud et MSP. Cela l’augmente, car les clients financiers intègrent des exigences contractuelles de niveau DORA, des droits d’audit, des tests de résilience, des stratégies de sortie et des attentes de signalement des incidents dans les contrats fournisseurs.

La Politique de sécurité des tiers et des fournisseurs Enterprise de Clarysec Politique de sécurité des tiers et des fournisseurs exige un accès tiers contrôlé :

« Tout accès des tiers doit être journalisé et surveillé et, lorsque cela est faisable, segmenté au moyen de bastions d’administration, de VPN ou de passerelles Zero Trust. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.3.2.

La Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - PME exprime le moindre privilège en termes directs :

« Les fournisseurs ne doivent se voir accorder l’accès qu’aux systèmes et données minimaux nécessaires à l’exercice de leur fonction. »

Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.2.1.

Ces clauses se cartographient naturellement vers les contrôles 5.19, 5.20, 5.21 et 5.22 de l’Annexe A ISO/IEC 27001:2022. Elles soutiennent également la gouvernance des sous-traitants de traitement de données et des sous-traitants ultérieurs au titre de GDPR, les revues de risque tiers DORA et les questionnaires d’audit client.

Continuité d’activité et résilience des centres de données : prouver les hypothèses

NIS2 Article 21 inclut la continuité d’activité, la gestion des sauvegardes, la reprise après sinistre et la gestion de crise. DORA Articles 11 à 14 exigent, pour les entités financières, des politiques de continuité d’activité TIC, des plans de réponse et de rétablissement, une analyse d’impact sur l’activité, des politiques de sauvegarde, des procédures de restauration, des objectifs de reprise, des tests, des revues post-incident et des communications de crise.

Pour les fournisseurs cloud et centres de données, la continuité n’est pas un classeur. Elle correspond à l’architecture, à la capacité, aux contrats, aux dépendances, aux éléments de preuve de restauration et aux hypothèses testées.

La Politique de continuité d’activité et de reprise après sinistre Enterprise de Clarysec Politique de continuité d’activité et de reprise après sinistre exige une BIA annuelle et une revue après les changements significatifs :

« L’analyse d’impact sur l’activité (BIA) doit être réalisée au moins une fois par an pour toutes les unités métier critiques et revue en cas de changements significatifs des systèmes, processus ou dépendances. Les résultats de la BIA doivent définir : 5.2.1. Durée maximale admissible d’interruption (MTD) 5.2.2. Objectifs de temps de reprise (RTO) 5.2.3. Objectifs de point de reprise (RPO) 5.2.4. Dépendances critiques (systèmes, fournisseurs, personnel) »

Extrait de la section « Exigences de gouvernance », clause de politique 5.2.

Dans un scénario de centre de données, la BIA doit couvrir les alimentations électriques, les UPS, les groupes électrogènes, les contrats de carburant, le refroidissement, l’extinction incendie, les opérateurs réseau, les systèmes d’accès physique, les interventions à distance, la surveillance, le matériel de rechange et les canaux de communication client. Dans un scénario cloud, elle doit couvrir les régions, les zones de disponibilité, la réplication, l’immutabilité des sauvegardes, les dépendances d’identité, DNS, les autorités de certification, les passerelles API et les systèmes de support. Dans un scénario MSP, elle doit couvrir les outils de gestion à distance, les coffres-forts d’accès à privilèges, les consoles EDR, les outils de ticketing, les référentiels documentaires et les communications d’urgence.

ISO 22301 peut renforcer la discipline de gestion de la continuité d’activité, tandis qu’ISO/IEC 27005:2022 soutient les critères de risque, la planification du traitement, la surveillance, les éléments de preuve et l’amélioration continue. C’est utile, car la préparation à NIS2 exige que l’organisation consolide les facteurs juridiques, contractuels, opérationnels, fournisseurs, technologiques, financiers, procéduraux et humains dans un processus unique de gestion des risques.

Traçabilité pratique des risques pour une violation d’accès à distance MSP

Un atelier pratique peut commencer par un scénario unique :

« La compromission d’un accès à distance à privilèges entraîne un accès non autorisé aux systèmes clients, une interruption de service, une possible exposition de données à caractère personnel et des obligations de notification réglementaire. »

Créez une ligne dans le registre des risques et complétez la traçabilité.

Mettez ensuite à jour la Déclaration d’applicabilité. Pour chaque contrôle Annexe A pertinent, expliquez pourquoi il s’applique et quel thème NIS2 il soutient. Enfin, collectez les éléments de preuve avant l’audit : rapports d’application de la MFA, listes de comptes à privilèges, paramètres de conservation des journaux, statut d’application des correctifs RMM, alertes SIEM, enregistrements de classification des incidents, approbations d’accès fournisseur et résultats d’exercices sur table.

Comment différents auditeurs testeront le même environnement de contrôle

Un SMSI intégré doit satisfaire différents angles d’assurance sans créer de dossiers de preuve séparés pour chaque référentiel.

C’est là que Zenith Controls est utile comme guide de conformité croisée. Pour des contrôles tels que 5.23, 5.24 et 8.8, il relie les attentes de contrôle ISO/IEC 27001:2022 aux thèmes NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF et ISO 22301. L’objectif n’est pas de créer des programmes de conformité séparés. L’objectif est une architecture unique d’éléments de preuve, étiquetée par contrôle, risque, facteur réglementaire et propriétaire.

Le modèle de mise en œuvre Clarysec

Pour les fournisseurs cloud, MSP, MSSP et centres de données, les travaux doivent progresser en cinq couches.

Premièrement, confirmer le champ d’application. Déterminez si l’organisation et les services sont dans le champ de NIS2, quelles règles des États membres s’appliquent, si le règlement d’exécution 2024/2690 s’applique à la catégorie du prestataire et si les clients imposent DORA, GDPR, NIST ou des obligations sectorielles.

Deuxièmement, construire le contexte du SMSI. Au titre des clauses 4 et 5 d’ISO/IEC 27001:2022, identifiez les parties intéressées, les obligations légales, les engagements clients, les dépendances fournisseurs, les limites des services et les responsabilités de direction.

Troisièmement, réaliser l’appréciation et le traitement des risques selon les principes d’ISO/IEC 27005:2022. Consolidez NIS2, DORA, GDPR, les contrats, les politiques internes et les risques de service dans un registre de référence des exigences. Définissez les critères de risque, les propriétaires, la vraisemblance, l’impact, les options de traitement, les choix de contrôles et les approbations du risque résiduel.

Quatrièmement, cartographier les contrôles dans la Déclaration d’applicabilité. Utilisez les étapes 13 et 14 de Zenith Blueprint pour relier les risques aux contrôles Annexe A et aux attentes réglementaires. Utilisez Zenith Controls pour comprendre comment les contrôles 5.23, 5.24, 8.8, 5.20 et 5.30 se cartographient entre les référentiels et les angles d’audit.

Cinquièmement, opérationnaliser les éléments de preuve. Les politiques ne suffisent pas. La bibliothèque de politiques Clarysec fournit des exigences opposables pour l’approbation du cloud, l’accès fournisseur, la journalisation, la remédiation des vulnérabilités, la segmentation réseau, la classification des incidents et la planification de la continuité. Le dossier de preuve démontre que ces exigences fonctionnent.

Prochaine étape : transformer la pression NIS2 en résilience adaptée à l’audit

Le règlement d’exécution NIS2 2024/2690 n’exige pas le chaos. Il exige la traçabilité, la responsabilité attribuée et la preuve.

Si vous êtes fournisseur de services cloud, MSP, MSSP ou opérateur de centre de données, commencez par vos services, clients, dépendances, scénarios d’incident et obligations d’éléments de preuve. Exécutez ensuite un exercice structuré de cartographie NIS2 vers ISO/IEC 27001:2022 :

1. Confirmez si votre entité et vos services sont dans le champ d’application.
2. Cartographiez les thèmes NIS2 et du règlement d’exécution dans le périmètre de votre SMSI.
3. Mettez à jour le registre des risques et la Déclaration d’applicabilité.
4. Appliquez les politiques Clarysec relatives à l’utilisation du cloud, à la sécurité des fournisseurs, à la journalisation, à la gestion des vulnérabilités, à la réponse aux incidents, à la sécurité réseau et à la continuité.
5. Utilisez les étapes 13, 14, 20 et 23 de Zenith Blueprint Zenith Blueprint pour créer la traçabilité et les éléments de preuve opérationnels.
6. Utilisez Zenith Controls Zenith Controls pour cartographier de façon croisée les contrôles ISO/IEC 27001:2022 par rapport aux attentes NIS2, DORA, GDPR, NIST et COBIT 2019.
7. Testez les éléments de preuve au moyen d’une simulation d’audit avant qu’un client, une autorité de régulation ou un auditeur de certification ne les demande.

Clarysec peut vous aider à dépasser la conformité par liste de contrôle et à construire un SMSI intégré capable de résister à la pression de NIS2, DORA, GDPR et des audits clients. Téléchargez les kits d’outils Clarysec pertinents, réservez un atelier de cartographie ou demandez une évaluation de préparation à l’audit afin de transformer la complexité réglementaire en gouvernance de la sécurité défendable et en résilience opérationnelle.