Objectif : Votre guide de préparation d’audit NIS2 prêt à l’emploi
Cette checklist est conçue pour les responsables conformité préparant leur organisation à un audit de conformité NIS2. Elle est structurée autour des dix domaines d’exigences spécifiés à l’article 21(2) de la directive NIS2 et fournit, pour chaque domaine, les exigences de contrôle, les preuves à rassembler, où trouver ces preuves et des critères clairs de réussite/échec.
Utilisez ce document comme un outil de travail. Imprimez-le, partagez-le avec vos équipes et utilisez-le pour suivre la progression de la collecte de preuves. Un auditeur évaluera si vos contrôles sont non seulement documentés mais mis en œuvre, efficaces et documentés par des preuves.
Article 21(2)(a) : Analyse des risques et politiques de sécurité des systèmes d’information
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Politique de sécurité de l’information documentée et approuvée par l’organe de direction |
Document de politique signé avec contrôle de version et enregistrement d’approbation |
Système de gestion documentaire ; procès-verbaux des réunions du conseil/de la direction |
Réussite : La politique existe, est à jour (révisée dans les 12 mois) et dispose d’une approbation documentée de la direction. Échec : Pas de politique, politique obsolète ou pas de preuve d’approbation de la direction. |
| Méthodologie d’évaluation des risques définie et appliquée |
Document de méthodologie d’évaluation des risques ; évaluations des risques complétées ; registre des risques |
Plateforme GRC ou système de gestion des risques ; dossiers de l’équipe de sécurité de l’information |
Réussite : La méthodologie est documentée, appliquée de manière cohérente et le registre des risques est à jour. Échec : Pas de méthodologie, application incohérente ou registre des risques obsolète. |
| Plans de traitement des risques avec propriétaires désignés |
Documentation du plan de traitement des risques ; preuves de mise en œuvre des contrôles ; enregistrements d’acceptation du risque résiduel |
Registre des risques ; outils de gestion de projet ; enregistrements d’approbation de la direction |
Réussite : Chaque risque au-dessus du seuil d’appétit a un plan de traitement avec un propriétaire nommé et une date cible. Échec : Risques non traités, plans sans propriétaires ou pas de preuves de progression. |
Article 21(2)(b) : Gestion des incidents
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Plan de réponse aux incidents couvrant la détection, l’analyse, le confinement, l’éradication et la récupération |
Document du plan de réponse aux incidents ; rôles définis et chemins d’escalade ; procédures de communication |
Documentation des opérations de sécurité ; plateforme de gestion des incidents |
Réussite : Un plan complet existe, est à jour et couvre toutes les phases. Échec : Pas de plan, couverture incomplète ou plan non mis à jour après des changements organisationnels. |
| Procédures de classification et de signalement des incidents alignées sur les délais NIS2 |
Document de critères de classification ; procédure de signalement avec workflows d’alerte précoce de 24 heures et de notification de 72 heures |
Procédures de gestion des incidents ; dossiers de contact CSIRT |
Réussite : Des critères de classification clairs existent ; les délais de signalement correspondent aux exigences NIS2 ; les coordonnées du CSIRT sont à jour. Échec : Pas de schéma de classification, délais incorrects ou canaux de signalement inconnus. |
| Preuves de tests de réponse aux incidents |
Enregistrements d’exercices sur table ; résultats de simulations ; documentation des leçons apprises ; actions d’amélioration |
Dossiers de l’équipe de sécurité ; enregistrements de formation ; rapports post-exercice |
Réussite : Au moins un exercice réalisé dans les 12 mois avec des résultats documentés et des actions d’amélioration. Échec : Pas de preuves de test ou tests sans améliorations documentées. |
Article 21(2)(c) : Continuité d’activité et gestion de crise
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Plan de continuité d’activité couvrant la gestion des sauvegardes et la reprise après sinistre |
Documents PCA et PRS ; RTO et RPO définis ; procédures de récupération |
Documentation de l’équipe de continuité d’activité ; dossiers des opérations IT |
Réussite : Les plans existent pour les services critiques avec des RTO/RPO définis et testés. Échec : Pas de plans, plans non testés ou objectifs de récupération non définis. |
| Gestion des sauvegardes avec tests réguliers |
Politiques de sauvegarde ; calendriers et journaux de sauvegarde ; résultats des tests de restauration |
Système de gestion des sauvegardes ; journaux des opérations IT |
Réussite : Sauvegardes régulières avec des tests de restauration documentés et réussis. Échec : Pas de politique de sauvegarde, pas de test de restauration ou échecs de tests sans remédiation. |
| Procédures de gestion de crise |
Plan de gestion de crise ; arbres de communication ; procédures de notification des parties prenantes ; enregistrements d’exercices de crise |
Documentation de gestion de crise de l’entreprise ; dossiers de l’équipe de communication |
Réussite : Le plan existe avec des chemins d’escalade clairs et a été exercé. Échec : Pas de plan de crise ou pas de preuve d’exercice. |
Article 21(2)(d) : Sécurité de la chaîne d’approvisionnement
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Exigences de sécurité dans les contrats fournisseurs |
Clauses contractuelles standard de sécurité ; contrats signés avec provisions de sécurité ; enregistrements d’évaluation de sécurité des fournisseurs |
Dossiers achats/juridiques ; plateforme de gestion des fournisseurs |
Réussite : Les fournisseurs critiques ont des exigences contractuelles de sécurité ; les évaluations sont documentées. Échec : Pas de clauses de sécurité dans les contrats ou pas de programme d’évaluation des fournisseurs. |
| Programme d’évaluation des risques fournisseurs |
Méthodologie d’évaluation des risques fournisseurs ; évaluations complétées pour les fournisseurs critiques ; registre des risques fournisseurs |
Plateforme de gestion des fournisseurs ; dossiers achats ; système de gestion des risques |
Réussite : Les fournisseurs critiques et importants sont évalués avec des résultats documentés et des notations de risque. Échec : Pas d’évaluation des risques fournisseurs ou couverture incomplète des fournisseurs critiques. |
| Contrôles de la chaîne d’approvisionnement logicielle (SBOM, gestion des dépendances) |
Enregistrements de génération SBOM ; résultats d’analyse des dépendances ; listes de composants approuvés ; politiques de composants tiers |
Sorties du pipeline CI/CD ; systèmes de gestion des artefacts ; outils d’analyse de sécurité |
Réussite : Les SBOM sont générés pour les logiciels livrés ; les dépendances sont analysées et gérées. Échec : Pas de visibilité sur la composition logicielle ou dépendances non gérées. |
Article 21(2)(e) : Sécurité des réseaux et des systèmes d’information
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Contrôles de sécurité réseau (segmentation, surveillance, contrôles d’accès) |
Documentation de l’architecture réseau ; politiques de segmentation ; règles de pare-feu ; configuration de surveillance réseau |
Systèmes de gestion réseau ; documentation d’infrastructure ; plateforme SIEM |
Réussite : Le réseau est segmenté de manière appropriée ; la surveillance est active ; les contrôles sont documentés. Échec : Réseau plat, pas de surveillance ou architecture réseau non documentée. |
| Surveillance de sécurité et journalisation |
Politique de journalisation ; configuration de rétention des journaux ; règles de surveillance et alertes ; tableaux de bord SIEM |
Plateforme SIEM ; infrastructure de journalisation ; dossiers du centre d’opérations de sécurité |
Réussite : Les systèmes critiques sont journalisés ; les journaux sont conservés selon la politique ; surveillance active avec des règles d’alerte définies. Échec : Lacunes dans la couverture de journalisation, rétention insuffisante ou pas de surveillance active. |
Article 21(2)(f) : Gestion et divulgation des vulnérabilités
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Programme de gestion des vulnérabilités |
Politique de gestion des vulnérabilités ; calendriers et résultats d’analyse ; SLA de remédiation et suivi ; processus d’exception |
Outils d’analyse des vulnérabilités ; système de gestion des correctifs ; plateforme GRC |
Réussite : Analyse régulière avec des SLA de remédiation définis ; vulnérabilités critiques traitées dans les SLA. Échec : Pas de programme d’analyse, pas de SLA ou violations chroniques des SLA sans escalade. |
| Processus de divulgation coordonnée des vulnérabilités |
Politique de divulgation des vulnérabilités (publiée) ; canal de contact pour les chercheurs ; procédure de traitement de la divulgation |
Site web public ; procédures de l’équipe de sécurité |
Réussite : Politique de divulgation publiée avec un processus clair et des délais de réponse. Échec : Pas de politique de divulgation ou pas de mécanisme pour les signalements externes de vulnérabilités. |
Article 21(2)(g) : Politiques et procédures d’évaluation de l’efficacité
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Évaluation régulière de l’efficacité des mesures de cybersécurité |
Rapports d’audit interne ; résultats de tests de pénétration ; métriques et KPI de sécurité ; enregistrements de revue de direction |
Dossiers de l’équipe d’audit interne ; rapports de tests de sécurité ; tableaux de bord de direction |
Réussite : Évaluations régulières réalisées (au moins annuellement) avec des conclusions documentées et des actions d’amélioration. Échec : Pas d’évaluations d’efficacité ou évaluations sans actions de suivi. |
Article 21(2)(h) : Cryptographie et chiffrement
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Politique de cryptographie couvrant les données en transit et au repos |
Document de politique de cryptographie ; standards d’algorithmes et longueurs de clé approuvés ; procédures de gestion des certificats ; documentation du cycle de vie de gestion des clés |
Bibliothèque de politiques de sécurité de l’information ; système de gestion PKI/certificats ; système de gestion des clés |
Réussite : La politique existe avec des algorithmes approuvés ; les données en transit et au repos sont chiffrées selon la politique ; le cycle de vie de gestion des clés est documenté. Échec : Pas de politique de cryptographie, utilisation d’algorithmes obsolètes ou clés cryptographiques non gérées. |
Article 21(2)(i) : Contrôle d’accès
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Politique de contrôle d’accès basée sur le moindre privilège et le besoin d’en connaître |
Politique de contrôle d’accès ; définitions d’accès basées sur les rôles ; procédures de provisionnement et de déprovisionnement |
Plateforme IAM ; dossiers RH d’intégration/départ ; documentation de contrôle d’accès |
Réussite : La politique existe ; l’accès est basé sur les rôles ; le provisionnement/déprovisionnement est documenté et rapide. Échec : Pas de politique de contrôle d’accès, privilèges excessifs ou déprovisionnement tardif des départs. |
| Revues d’accès régulières |
Calendriers de revue d’accès ; enregistrements de revues complétées ; actions de remédiation issues des revues |
Plateforme IAM ; outil de revue d’accès ; dossiers de conformité |
Réussite : Revues d’accès réalisées au moins trimestriellement pour les accès privilégiés et annuellement pour les accès standards ; la remédiation est suivie. Échec : Pas de revues d’accès ou revues sans suivi de remédiation. |
Article 21(2)(i) : Gestion des actifs
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| Inventaire des actifs couvrant tous les réseaux et systèmes d’information |
Inventaire des actifs/CMDB ; schéma de classification des actifs ; attribution de propriété des actifs |
Système de gestion des actifs/CMDB ; plateforme de gestion des services IT |
Réussite : Un inventaire complet existe avec classification et propriétaires assignés ; l’inventaire est régulièrement mis à jour. Échec : Inventaire incomplet, pas de classification ou propriété non assignée. |
Article 21(2)(j) : Authentification multifacteur et authentification continue
| Exigence de contrôle |
Preuves nécessaires |
Où les trouver |
Critères de réussite/échec |
| MFA déployé pour les accès privilégiés et les accès distants |
Politique MFA ; enregistrements d’inscription MFA ; preuves de configuration d’application du MFA |
Configuration de la plateforme IAM/MFA ; documentation de la politique d’accès |
Réussite : Le MFA est appliqué pour tous les accès privilégiés et distants ; l’inscription est suivie ; les exceptions sont documentées et limitées dans le temps. Échec : MFA non appliqué pour les accès privilégiés, utilisateurs non inscrits significatifs ou exceptions permanentes sans justification. |
| Canaux d’authentification et de communication sécurisés |
Configuration du système d’authentification ; preuves de canaux de communication chiffrés ; politiques de gestion des sessions |
Plateforme IAM ; configuration réseau ; documentation d’architecture de sécurité |
Réussite : Le trafic d’authentification est chiffré ; les contrôles de gestion des sessions sont en place ; les protocoles sécurisés sont appliqués. Échec : Flux d’authentification non chiffrés ou gestion des sessions faible. |
Signaux d’alerte indiquant la non-conformité
Lors de la préparation de l’audit, les responsables conformité doivent activement rechercher les signaux d’alerte suivants et les traiter avant l’arrivée de l’auditeur :
- Politiques sans preuves de mise en œuvre : Les politiques existent sur le papier mais il n’y a aucune preuve qu’elles sont suivies en pratique. Les auditeurs rechercheront des preuves opérationnelles, pas seulement des documents.
- Documentation obsolète : Évaluations des risques, politiques ou procédures non révisées ou mises à jour depuis plus de 12 mois.
- Pas d’implication de l’organe de direction : Aucune preuve que l’organe de direction a approuvé les mesures de cybersécurité, reçu des rapports de risques ou suivi la formation requise (Article 20).
- Réponse aux incidents jamais testée : Un plan de réponse aux incidents qui n’a jamais été exercé par un exercice sur table ou une simulation.
- Revues d’accès non réalisées : Aucune preuve de revues périodiques d’accès, en particulier pour les comptes privilégiés.
- Inventaire des actifs inconnu : Incapacité à produire un inventaire actuel des réseaux et systèmes d’information.
- Pas d’évaluations de sécurité des fournisseurs : Fournisseurs critiques sans évaluation de sécurité enregistrée.
- Preuves manuelles sans contrôles d’intégrité : Preuves qui pourraient facilement être fabriquées ou modifiées, sans horodatages générés par le système ni pistes d’audit.
- Points de défaillance uniques dans les contrôles clés : Fonctions de sécurité critiques dépendant d’un seul individu sans plan de relève ou de succession.
- Pas de métriques sur l’efficacité des contrôles : Incapacité à démontrer que les mesures de sécurité fonctionnent effectivement, pas seulement qu’elles sont déployées.
Exigences d’intégrité des preuves
La qualité de vos preuves compte autant que leur existence. Les auditeurs évalueront si les preuves sont fiables et dignes de confiance. Pour résister à l’examen, vos preuves doivent répondre à ces standards :
- Générées par le système : Dans la mesure du possible, les preuves doivent être générées automatiquement par les systèmes plutôt que créées manuellement. Les journaux, rapports et enregistrements générés par le système sont intrinsèquement plus fiables que les tableurs compilés manuellement.
- Horodatées : Toutes les preuves doivent porter des horodatages précis montrant quand les actions ont eu lieu, quand les revues ont été menées et quand les approbations ont été accordées. Assurez-vous que les horloges système sont synchronisées (NTP) pour maintenir la fiabilité des horodatages.
- Résistantes à la falsification : Les preuves doivent être stockées dans des systèmes où elles ne peuvent pas être facilement modifiées après coup. Les journaux d’audit immuables, le stockage en écriture unique et les vérifications d’intégrité cryptographiques renforcent tous la fiabilité des preuves.
- Attribuables : Les preuves doivent clairement identifier qui a effectué chaque action. La responsabilité individuelle nécessite des comptes individuels — les comptes partagés compromettent l’attribution.
- Conservées de manière appropriée : Les preuves doivent être conservées pendant une période suffisante pour couvrir les cycles d’audit et les exigences réglementaires. Définissez des périodes de rétention et assurez-vous qu’elles sont respectées.
Structure suggérée du pack de preuves
Les responsables conformité doivent organiser leur pack de preuves selon une structure qui correspond directement aux exigences NIS2, facilitant la navigation pour les auditeurs. La structure de modèle suivante est recommandée :
Structure des dossiers
- 01 — Gouvernance et gestion des risques (Art. 21(2)(a))
- Politique de sécurité de l’information (actuelle, signée)
- Méthodologie d’évaluation des risques
- Registre des risques actuel avec plans de traitement
- Enregistrements d’approbation de l’organe de direction
- Enregistrements de formation de l’organe de direction (Article 20)
- 02 — Gestion des incidents (Art. 21(2)(b))
- Plan de réponse aux incidents
- Critères de classification des incidents
- Procédures de signalement et contacts CSIRT
- Enregistrements d’exercices et leçons apprises
- Journal des incidents (expurgé si nécessaire)
- 03 — Continuité d’activité (Art. 21(2)(c))
- Plan de continuité d’activité
- Plan de reprise après sinistre
- Politique de sauvegarde et résultats des tests de restauration
- Procédures de gestion de crise
- Enregistrements d’exercices PCA/PRS
- 04 — Sécurité de la chaîne d’approvisionnement (Art. 21(2)(d))
- Politique de sécurité des fournisseurs
- Registre des fournisseurs critiques
- Enregistrements d’évaluation des fournisseurs
- Clauses contractuelles de sécurité standard
- Échantillons SBOM (pour la livraison logicielle)
- 05 — Sécurité des réseaux et systèmes (Art. 21(2)(e))
- Documentation de l’architecture réseau
- Politiques et preuves de segmentation
- Configuration de surveillance et de journalisation
- Règles d’alerte SIEM et procédures de réponse
- 06 — Gestion des vulnérabilités (Art. 21(2)(f))
- Politique de gestion des vulnérabilités
- Calendriers d’analyse et résultats récents
- SLA de remédiation et métriques de conformité
- Politique de divulgation des vulnérabilités
- 07 — Évaluation de l’efficacité (Art. 21(2)(g))
- Rapports d’audit interne
- Rapports de tests de pénétration
- Métriques de sécurité et tableaux de bord KPI
- Procès-verbaux de revue de direction
- 08 — Cryptographie (Art. 21(2)(h))
- Politique de cryptographie
- Algorithmes approuvés et longueurs de clé
- Procédures de gestion des clés
- Inventaire des certificats
- 09 — Contrôle d’accès et gestion des actifs (Art. 21(2)(i))
- Politique de contrôle d’accès
- Enregistrements de revue d’accès
- Inventaire des actifs / extrait CMDB
- Schéma de classification des actifs
- 10 — Authentification (Art. 21(2)(j))
- Politique MFA et preuves d’application
- Métriques d’inscription MFA
- Preuves de canaux de communication sécurisés
- Registre des exceptions (le cas échéant)
Ressources connexes
Pour des orientations complémentaires sur la préparation d’audit NIS2 et la conformité, consultez :
Ressources connexes pour les auditeurs
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
