À retenir. Un audit de préparation NIS 2 vérifie la gouvernance de l’article 20, les mesures de gestion des risques de l’article 21 et l’organisation des notifications de l’article 23 de la directive (UE) 2022/2555. Il part des services, systèmes et risques de l’entité, puis examine les preuves de fonctionnement. Au 27 septembre 2026, le projet français de transposition reste en cours ; l’audit est une préparation documentée, non une attestation de conformité à une loi française NIS 2 déjà promulguée.
Cette checklist est organisée pour l’auditeur interne, le RSSI et la direction. Elle ne décrète ni SIEM obligatoire, ni test mensuel, ni prestataire qualifié universel. Chaque contrôle doit être relié au service protégé et au risque qu’il réduit. Avant de démarrer, tranchez la qualification EE, EI, OIV ou OSE et consignez les incertitudes. Le guide des sanctions distingue directive et droit français actuel.
1. Périmètre de l’audit NIS 2
Définissez la personne morale, les services correspondant aux annexes I ou II, les sites, applications, réseaux, processus métiers et fournisseurs nécessaires. Une cartographie technique seule ne suffit pas : l’auditeur doit comprendre les services aux clients ou citoyens et les conséquences de leur arrêt. Le guide de cartographie SI aide à relier actifs, données et responsables. Lorsque plusieurs filiales partagent un annuaire ou un cloud, notez les frontières juridiques et les dépendances communes.
La première pièce du dossier est une décision de périmètre : services inclus, systèmes contributeurs, exclusions et justifications. La seconde est une analyse d’interfaces avec RGPD, OIV, OSE ou DORA. Ne supposez pas qu’une certification de groupe couvre une filiale ou un service non listé dans son certificat. Vérifiez le périmètre exact, la version et la durée de validité de chaque preuve externe.
Exemple hypothétique : un prestataire gère le système de sauvegarde de cinq hôpitaux, mais sa société sœur développe un outil RH sans accès à la production. L’audit doit expliquer quelles personnes morales et quels systèmes fournissent le service géré. Étendre sans analyse toute la checklist à la société sœur gaspillerait du temps ; exclure l’annuaire partagé masquerait un risque critique.
2. Article 20 : gouvernance et formation
Demandez la preuve que l’organe de direction a examiné et approuvé les mesures de gestion du risque, puis qu’il suit leur mise en œuvre. La PSSI sert de base, mais un compte rendu doit montrer les risques majeurs, options, décisions, responsables, budget et échéances. Vérifiez que les dirigeants comprennent les scénarios qui menacent la fourniture du service et ont suivi une formation pertinente. L’article 20 ne fixe pas une périodicité annuelle identique pour chaque formation ou une forme obligatoire de procès-verbal.
Interrogez séparément direction, RSSI et responsable d’un service critique. Peuvent-ils expliquer qui décide de couper une application compromise, qui accepte un risque résiduel et comment une lacune remonte au comité ? Comparez leurs réponses au plan de gestion de crise. Si personne n’a le pouvoir de financer une restauration, la politique signée ne suffit pas.
L’audit documente les points satisfaisants, les écarts et les décisions en attente. Il distingue défaut de document, absence de contrôle et contrôle existant sans preuve conservée. Ces situations n’appellent pas le même correctif.
3. Article 21 §2(a) : politiques et analyse des risques
Contrôlez l’existence d’une méthode de risque, d’un inventaire et de décisions d’acceptation. La méthode peut s’appuyer sur EBIOS Risk Manager lorsque le contexte s’y prête ; la directive n’impose pas cette méthode à toutes les organisations. L’essentiel est que les scénarios soient plausibles, que les services menacés soient identifiés et que les traitements soient suivis. Vérifiez aussi les règles de sécurité des systèmes et de leur environnement physique, car l’article 21 adopte une approche « tous risques ».
Pour un service de paiement, demandez comment une panne du fournisseur d’identité affecte les opérations. Pour un industriel, examinez une indisponibilité des automates ou de l’accès de maintenance. Comparez les risques avec les incidents réellement observés et les changements d’architecture. Une analyse jamais revue après migration cloud peut être formellement présente mais matériellement périmée.
La preuve attendue inclut l’analyse, la décision, l’action choisie et un résultat de test. L’auditeur note les hypothèses non vérifiées, par exemple « le fournisseur restaure en quatre heures », puis demande un contrat ou un exercice démontrant cette capacité.
4. Article 21 §2(b) : gestion des incidents
Vérifiez comment un événement devient un incident, qui le qualifie, qui peut contenir la propagation et comment les preuves sont préservées. La procédure doit fonctionner hors des heures ordinaires si le service l’exige. Examinez un incident passé ou jouez un scénario court : compte administrateur compromis, courriel de rançon, panne simultanée de plusieurs sites. Demandez l’heure de détection, les décisions et la trace des actions.
Un SOC ou un service MDR peut être utile pour certains risques, mais l’article 21 ne rend pas ces achats universels. Une petite entité peut organiser une surveillance et une astreinte adaptées, avec un fournisseur si nécessaire. L’auditeur vérifie si les alertes utiles atteignent une personne capable d’agir. La méthode de gestion de crise précise le passage de l’incident technique aux décisions de direction.
Consultez également la rétention de journaux : est-elle suffisante pour comprendre les scénarios identifiés et compatible avec la protection des données ? « Douze mois obligatoires » serait une affirmation trop générale. Testez la capacité à retrouver un événement précis sur un système choisi, puis notez ce que les journaux ne permettent pas encore de voir.
5. Article 21 §2© : continuité, sauvegardes et reprise
L’audit rapproche l’analyse d’impact métier, les objectifs de reprise et les tests. Les sauvegardes doivent être récupérables avec les clés, identités et procédures nécessaires. Un rapport d’exécution « vert » ne démontre pas la restauration. Choisissez un service critique, demandez le dernier essai de reprise et comparez le délai obtenu à celui promis par le PCA.
Exemple hypothétique : une société sauvegarde chaque nuit une base de production, mais le serveur de restauration dépend du même annuaire compromis par un rançongiciel. Le test en environnement isolé révèle cette dépendance. Le correctif peut combiner comptes d’urgence, documentation hors ligne et restauration de l’annuaire ; acheter davantage d’espace de sauvegarde ne répondrait pas au problème.
La périodicité des essais suit la criticité et la vitesse de changement du service. Un test mensuel peut être pertinent pour un service très dynamique, mais n’est pas un seuil imposé indistinctement par NIS 2. Conservez les incidents de test, les décisions de correction et le prochain exercice prévu.
6. Article 21 §2(d) : chaîne d’approvisionnement
Établissez la liste des fournisseurs directs qui ont accès aux systèmes, hébergent des données, maintiennent un composant ou soutiennent la continuité du service. Classez-les selon l’impact d’une défaillance, leur substituabilité, leurs accès privilégiés et la concentration du risque. La fiche de criticité fournisseur donne une méthode pour distinguer ces dimensions. Le guide NIS 2 fournisseurs traite clauses et suivi.
Pour un fournisseur critique, vérifiez les garanties réellement obtenues : périmètre d’une certification, rapport de test récent, notification d’incident, continuité, sous-traitants, droit de contrôle. Un questionnaire coché sans preuve ne démontre rien. À l’inverse, imposer un audit sur place annuel à tous les fournisseurs n’est pas écrit dans l’article 21. Les tests doivent être proportionnés au risque et aux droits contractuels disponibles.
Exemple hypothétique : l’unique fournisseur de DNS d’une plateforme n’a aucun accès aux données personnelles, mais sa panne rend le service inaccessible. Il peut être plus critique pour la continuité qu’un cabinet RH disposant de données sensibles et sans accès à la production. Les deux demandent des contrôles différents.
7. Article 21 §2(e) et (f) : acquisition, développement et efficacité
Pour les systèmes développés ou acquis, vérifiez que les exigences de sécurité existent avant mise en production, que les vulnérabilités peuvent être signalées et corrigées, et que les changements sensibles sont revus. Un test de pénétration peut être adapté à une application exposée, mais l’article 21 n’impose pas partout un test annuel. Les composants tiers et les comptes de déploiement demandent une attention spécifique.
L’évaluation de l’efficacité est distincte de la politique : mesurez si un contrôle marche. Échantillonnez des comptes sortis pour vérifier leur révocation, des correctifs urgents pour mesurer la réaction, et des sauvegardes pour confirmer la restauration. Si l’organisation suit un indicateur « 100 % MFA », l’auditeur doit contrôler le périmètre : administrateurs, prestataires, comptes de service, chemins de secours. Un tableau de bord sans définition du dénominateur peut tromper la direction.
8. Article 21 §2(g) : hygiène et sensibilisation
La sensibilisation doit rejoindre les tâches réelles : reconnaissance d’une demande de changement de RIB, signalement d’un lien suspect, utilisation d’un appareil nomade, maintien d’un mot de passe de secours. Examinez les supports, les publics couverts et surtout le comportement observé lors d’un exercice ou d’un incident. Une simulation trimestrielle de phishing ou un quiz annuel ne sont pas des exigences universelles de la directive.
Pour les équipes techniques, l’hygiène comprend inventaire, configurations, comptes privilégiés et gestion des mises à jour. Le guide de télétravail sécurisé traite les postes hors des locaux. Comparez les règles écrites aux configurations d’un échantillon ; notez les exceptions et leur approbation. La formation n’est pas un substitut au contrôle technique d’un accès trop large.
9. Article 21 §2(h) : cryptographie et clés
La directive demande des politiques et procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement. Auditez donc les usages qui comptent : disques nomades, sauvegardes, communications administratives, stockage de données sensibles, gestion des clés et révocation. Ne présentez pas AES-256, TLS 1.3, RSA-3072 ou un HSM comme paramètres légaux NIS 2 obligatoires pour toute entité. Le choix doit répondre au risque et aux recommandations techniques applicables.
Un contrôle pratique consiste à demander qui peut récupérer une clé de sauvegarde après départ de l’administrateur, comment un certificat expiré est détecté et si un appareil volé était chiffré. Pour les données personnelles, rapprochez l’analyse de la sécurité RGPD article 32. Une politique cryptographique complète mais sans inventaire des clés ne protège pas la disponibilité du service.
10. Article 21 §2(i) et (j) : accès et communications
Testez le cycle des identités et la politique de mots de passe : création approuvée, droits accordés, mobilité, retrait et revue des comptes inactifs. Vérifiez les accès des prestataires et les comptes d’urgence. L’article 21 mentionne les politiques de sécurité des ressources humaines, le contrôle d’accès et la gestion des actifs, puis l’authentification multifactorielle ou continue et les communications vocales, vidéo et textuelles sécurisées lorsqu’il y a lieu. Il ne prescrit pas une marque de messagerie ni une architecture Active Directory particulière.
Exemple hypothétique : un prestataire de maintenance conserve un compte administrateur après la fin de son contrat. L’audit cherche le processus qui aurait dû fermer le compte, les traces d’usage et la possibilité de retirer l’accès sans interrompre la production. La correction combine contrat, identité et système ; un rappel général des mots de passe serait insuffisant.
11. Article 23 : notification d’incident significatif
La directive prévoit une alerte précoce sous 24 heures après connaissance, une notification sous 72 heures et un rapport final dans le mois suivant cette notification, pour les incidents significatifs définis par le texte. Elle prévoit aussi des cas particuliers et des informations évolutives. En France, vérifiez aujourd’hui les obligations OIV, OSE, RGPD ou sectorielles applicables ; la transposition NIS 2 n’est pas achevée dans les sources officielles consultées.
Auditez la capacité à décider : qui qualifie « significatif », qui contacte l’autorité, qui consolide les faits et comment un message est validé hors horaires ? Jouez un scénario hypothétique où l’impact est inconnu à la première heure. Une procédure qui attend une enquête complète avant d’ouvrir la chronologie risque de manquer les délais. Le guide de notification RGPD aide à tenir en parallèle l’analyse des données personnelles.
12. Méthode d’audit blanc et rapport exploitable
Préparez une liste de pièces courte, puis échantillonnez les services et les contrôles les plus exposés. Conduisez des entretiens contradictoires : direction, métiers, exploitation, achats, DPO et fournisseur critique. Testez quelques chemins complets, par exemple du signalement d’un compte compromis à sa révocation, ou de la demande de restauration au retour du service. Notez pour chaque constat la source, le risque, le propriétaire, la mesure temporaire et la preuve à obtenir. Ne convertissez pas un défaut documentaire en « non-conformité légale » sans texte applicable.
Priorisez les écarts selon l’impact sur le service et la facilité d’exploitation, plutôt que selon un nombre de cases vides. Faites valider le rapport par les responsables qui ont fourni les faits, puis présentez les arbitrages à la direction. Un plan d’action se termine seulement quand une preuve de fonctionnement est obtenue. Un audit ultérieur peut reprendre les constats antérieurs et vérifier leur fermeture réelle.
Avant de conclure sur quelques dossiers, rédigez une note de sélection d’échantillon avec population, strates, cas ciblés et limites de couverture ; un nombre de dossiers seul n’établit pas la représentativité.
Après le rapport, une fiche de clôture des écarts relie cause, correction, retest et acceptation du risque restant, au lieu d’assimiler ticket fermé et contrôle rétabli.
Prestataires qualifiés ANSSI et référentiels
Le guide des audits PASSI décrit le contexte ; l’ANSSI explique les qualifications de prestataires ; une qualification PASSI porte sur un prestataire et des activités précises, à vérifier dans la liste officielle actuelle. NIS 2 ne rend pas automatiquement tout audit interne obligatoire par un PASSI. Des règles OIV ou contractuelles peuvent imposer des exigences particulières sur un périmètre donné. Choisissez un intervenant selon la compétence requise et la base applicable, puis vérifiez son indépendance et son périmètre de qualification.
Le ReCyF de l’ANSSI, version de travail publiée le 17 mars 2026 aide à organiser la préparation. ISO/IEC 27001:2022 et NIST CSF 2.0 peuvent aider à structurer des contrôles, mais une certification ISO ou un alignement NIST ne prouvent pas, seuls, le respect de toutes les obligations de la future loi française. Évitez les promesses du type « 90 % conforme » et les prix forfaitaires d’audit non sourcés : le périmètre et les tests déterminent l’effort.
Questions fréquentes
Quel est le premier document à demander ?
La fiche de qualification et de périmètre, puis la cartographie des services critiques. Sans elle, les preuves techniques risquent de porter sur le mauvais système ou la mauvaise personne morale.
Un PASSI est-il obligatoire pour tout audit NIS 2 ?
La directive ne pose pas cette règle générale. Vérifiez les obligations françaises effectivement applicables, les clauses contractuelles et le type d’audit demandé.
Comment prouver l’implication des dirigeants ?
Montrez les risques présentés, la décision prise, les ressources accordées, la formation et le suivi d’exécution. Un procès-verbal purement formel ne remplace pas la supervision de mesures réelles.