Contrôle de conformité NIS2 et KSC : documents, registres et tests à réunir en un dossier de preuves cohérent

Un contrôle de conformité NIS2 et KSC ne se limite pas à la présentation de politiques et de procédures. L’autorité de contrôle peut vérifier si l’organisation a correctement défini le périmètre de ses obligations, attribué les responsabilités, déployé les mesures de sécurité et démontré leur fonctionnement au moyen de registres à jour, de résultats de tests et de décisions de gouvernance. La préparation doit donc suivre une chaîne de preuves complète : de l’obligation et du risque identifié jusqu’au dispositif appliqué, à la trace de son exécution, à l’évaluation de son efficacité et au traitement de tout écart.

Le contrôle porte sur le système en fonctionnement, pas sur un classeur

Le point de départ n’est pas le nombre de politiques ou de procédures disponibles, mais la détermination correcte du périmètre des obligations. L’organisation doit pouvoir préciser quels services, processus, systèmes d’information, sites et dépendances vis-à-vis des fournisseurs relèvent des exigences de la KSC, ainsi que les fondements de cette qualification. Avant de réorganiser la documentation, la direction doit donc confirmer le statut de l’entité et le périmètre des services concernés, puis désigner la personne chargée de coordonner la préparation au contrôle.

Le principal risque probatoire apparaît lorsque la documentation décrit des dispositifs qui ne sont pas réellement appliqués ou dont l’organisation ne peut démontrer l’exécution. Cela concerne notamment les revues des droits d’accès, les analyses de risques, les sauvegardes, la surveillance des fournisseurs et les tests de continuité d’activité. Le dossier doit former une chaîne cohérente : exigence ou risque, décision, mesure de sécurité appliquée, responsabilité, preuve d’exécution, résultat de l’évaluation d’efficacité et réponse apportée à l’écart constaté.

L’autorité peut partir d’un document-cadre, puis examiner un échantillon opérationnel. Si la procédure de gestion des incidents définit les règles de classification et d’escalade, il faut s’attendre à un contrôle des signalements, des délais de réaction, des décisions prises, des communications, de la clôture des dossiers et des enseignements tirés. Le périmètre du système ne se démontre pas uniquement par une description : il doit également être étayé par une cartographie des services et des dépendances, un inventaire des actifs, l’attribution des responsables et la concordance de ces informations avec les registres opérationnels.

Documentation NIS2 et KSC avant un contrôle : quelles politiques, quels registres et quelles preuves faut-il réellement préparer ? La documentation doit refléter un dispositif de management effectivement opérationnel, et non constituer un simple catalogue de modèles. Il convient par ailleurs de distinguer le contrôle effectué par l’autorité de l’audit d’un système de management. Les deux démarches peuvent s’appuyer sur des preuves similaires, mais le contrôle vise à évaluer l’exécution des obligations issues des textes applicables et du périmètre de surveillance, tandis que l’audit apprécie la conformité et l’efficacité du système au regard de critères définis. Le résultat positif de l’une ne se substitue pas à l’autre.

Périmètre et responsabilités sous examen

Le premier ensemble de preuves doit expliquer pourquoi l’organisation est soumise à certaines obligations et où se situent les limites de l’environnement contrôlé. L’autorité peut demander la justification de la qualification de l’entité, l’identification des services couverts par la réglementation et la liste des processus, actifs informationnels, systèmes, sites et fournisseurs associés. Le périmètre ne doit pas être décrit par le seul intitulé de l’activité. Il doit permettre de suivre la fourniture du service depuis le processus métier jusqu’aux actifs qui le soutiennent et aux dépendances externes.

La préparation repose sur une description actuelle du périmètre, approuvée par la direction et complétée par une cartographie des services et des processus, un inventaire des actifs critiques ainsi qu’une structure claire des responsabilités. Les documents attribuant les rôles doivent définir non seulement les fonctions concernées, mais aussi les pouvoirs permettant d’accepter un risque, de déclencher des mesures d’urgence, d’escalader un incident et de prendre des décisions à l’égard des fournisseurs. Les propriétaires des services, des actifs et des risques doivent être désignés conformément à la répartition réelle des compétences.

Une incohérence fréquente apparaît lorsque le registre désigne formellement un propriétaire du risque, mais que l’acceptation de ce risque est décidée par une autre personne, sans habilitation appropriée ni trace de la décision. Le même problème peut concerner les dérogations aux mesures de sécurité, la continuité d’activité ou l’approbation des fournisseurs. Les procès-verbaux de réunion, décisions formelles, validations des analyses de risques, arbitrages budgétaires et revues de direction doivent démontrer que la direction connaît les risques significatifs, statue sur les sujets dépassant les compétences opérationnelles et supervise la mise en œuvre de ses décisions.

Les modalités de qualification, d’inscription sur le registre compétent et les pouvoirs de l’autorité doivent être déterminés au cas par cas, au regard du droit en vigueur et de la situation de l’entité. Cette question est développée dans l’article NIS2 : autoévaluation et inscription au registre KSC – que doit faire une entreprise industrielle ? Si l’organisation a le statut d’entité essentielle, l’analyse du périmètre doit également être rapprochée du contenu Audit KSC obligatoire : quelles entités essentielles doivent se préparer à leur première évaluation de conformité ? Le statut ne prouve toutefois pas, à lui seul, que la direction a approuvé les limites des responsabilités et organisé leur réexamen périodique.

Les registres révèlent les pratiques réelles

Un registre ne constitue la preuve d’un management continu que s’il reflète les décisions et les opérations réellement exécutées dans les processus. Il ne doit pas être un simple appendice de procédure, mis à jour ponctuellement. Avant de choisir un outil, il convient de définir les champs obligatoires, les sources de données, les responsables des enregistrements et les règles d’approbation des modifications. Une feuille de calcul peut suffire si elle assure la maîtrise des accès, la traçabilité des changements, une responsabilité sans ambiguïté et une protection contre les modifications non autorisées. À l’inverse, un outil sophistiqué ne garantit pas la fiabilité des données si personne ne sait qui met à jour le registre, à quel moment et à partir de quel événement.

Le registre des risques doit relier les scénarios de menace aux services et aux actifs, identifier le propriétaire, les mesures existantes, le résultat de l’évaluation, la décision de traitement et l’état d’avancement des actions. L’autorité peut vérifier qu’un risque déclaré comme devant être réduit est associé à une action, une échéance et une preuve de réalisation, et qu’un risque accepté a bien été validé par une personne disposant de l’autorité nécessaire. Le nombre de risques ouverts, d’actions non terminées et de décisions en attente de réexamen constitue un ensemble d’indicateurs de pilotage utiles. Il s’agit d’indicateurs choisis par l’organisation, et non de seuils réglementaires.

Le registre des incidents et événements doit permettre de reconstituer toutes les étapes : détection, qualification de l’incident, escalade, décision de notification, communication, rétablissement du fonctionnement et clôture formelle avec retour d’expérience. Les éléments associés comprennent notamment les registres des vulnérabilités, des correctifs et des dérogations acceptées, des revues des droits d’accès, de l’exécution et de la restauration des sauvegardes, des changements de configuration, des opérations réalisées par les administrateurs, des formations et des exercices.

Le report d’un correctif doit être traçable depuis la vulnérabilité identifiée jusqu’à la confirmation de clôture, en passant par l’analyse d’impact, la décision de dérogation, la mise en place de mesures compensatoires et la date de réévaluation. Une simple liste de correctifs en attente ne permet pas de démontrer que le retard est maîtrisé.

La même cohérence est requise pour la surveillance de la chaîne d’approvisionnement. Une liste de contrats ne remplace ni la classification des fournisseurs, ni l’évaluation des dépendances des services et des actifs vis-à-vis de tiers, ni la définition des exigences de sécurité, ni les comptes rendus de revue et les décisions relatives aux insuffisances non acceptées. Le registre doit montrer qui a approuvé le fournisseur, quelles dérogations ont été validées et à quelle date la prochaine évaluation aura lieu. Il convient notamment de suivre les fournisseurs qui ne disposent pas d’une évaluation à jour ainsi que les actions non réalisées à l’issue des revues. Ce sujet reste également déterminant dans le cadre du programme Mise en œuvre de NIS2 après l’inscription au registre KSC – plan d’action jusqu’au 3 avril 2027.

Les règles de conservation, d’accès et d’approbation des modifications doivent être adaptées à la nature de chaque enregistrement, à sa valeur probatoire, aux exigences légales et contractuelles ainsi qu’aux besoins d’analyse des incidents. Il ne convient pas d’appliquer une durée de conservation unique à tous les registres sans procéder à cette analyse. Les délais de notification des incidents et les modalités de préservation des preuves doivent être systématiquement vérifiés au regard des textes applicables et des lignes directrices de l’autorité compétente. Un catalogue plus large est présenté dans Documentation NIS2 et KSC avant un contrôle : quelles politiques, quels registres et quelles preuves faut-il réellement préparer ? La maturité opérationnelle repose toutefois sur les enregistrements produits au quotidien et sur la traçabilité entre l’exigence définie, le résultat du contrôle et l’action corrective.

Chaque test doit déboucher sur une décision

L’autorité de contrôle peut demander non seulement un plan de continuité d’activité, une procédure de réponse aux incidents ou la confirmation que des sauvegardes sont réalisées, mais aussi les preuves que ces dispositifs ont été testés dans des conditions représentatives des services, des technologies et des dépendances vis-à-vis des fournisseurs. Le programme de tests doit découler de l’analyse des risques, de la criticité des services, des évolutions de l’environnement et des exigences légales et contractuelles. Il n’existe pas de fréquence universelle adaptée à toutes les mesures de sécurité. Les contrôles doivent être plus fréquents pour les domaines à fort impact, qui évoluent rapidement ou dans lesquels des tests antérieurs ont révélé des écarts significatifs.

Avant chaque test, il faut en définir l’objet et les critères de réussite. L’enregistrement doit préciser le périmètre, le scénario, les participants, l’environnement, les critères d’acceptation et les tolérances admises. Après exécution, il doit consigner le résultat, les écarts ainsi que leur impact réel ou potentiel sur le service. En cas d’insuffisance, le dossier de preuves doit identifier les actions correctives, leurs responsables, les échéances et la date de la nouvelle vérification.

Les indicateurs utiles comprennent le temps réel de reprise, le point de reprise effectivement atteint, le délai d’escalade et le pourcentage d’actions clôturées après le test. L’erreur organisationnelle la plus grave consiste à répéter les tests sans critères de réussite ou sans clôturer les non-conformités détectées.

Les essais essentiels comprennent la restauration des données à partir des sauvegardes, le basculement vers les dispositifs de secours, les exercices de réponse aux incidents, les tests de communication de crise, les revues des droits d’accès, la restauration des configurations et les contrôles techniques des vulnérabilités, notamment les analyses automatisées et, selon le niveau de risque, les tests d’intrusion. Le résultat produit par un prestataire peut constituer une partie de la preuve, mais il ne remplace pas un test réalisé du point de vue de l’organisation s’il ne couvre pas ses processus, ses intégrations, ses responsabilités et ses conditions d’exploitation.

À l’issue de chaque test, le propriétaire du service doit prendre une décision documentée : accepter le résultat, mettre en œuvre une correction, instaurer une mesure compensatoire, répéter le test ou accepter le risque conformément aux pouvoirs qui lui ont été attribués.

La réussite d’une sauvegarde de base de données ne prouve pas encore la capacité à rétablir le service. Le test peut révéler que l’application dépend d’une version de configuration non documentée, que le mécanisme d’identité ne fonctionne pas dans l’environnement de secours, que les clés sont inaccessibles ou que la seule personne connaissant l’ordre de démarrage des composants ne participe pas à la restauration. Seul un test couvrant l’ensemble de la chaîne de dépendances permet de comparer le temps et le point de reprise réels aux critères retenus, d’évaluer l’impact sur le service et de décider si l’organisation est prête ou si des améliorations sont nécessaires.

Cette méthode de documentation des tests s’applique à tous les secteurs, notamment lors de l’analyse du sujet NIS2 pour les entreprises industrielles : entités concernées, obligations introduites et préparation de l’organisation sans réduire le sujet à l’informatique. Le périmètre des preuves attendues doit être rapporté aux obligations applicables à l’organisation, à ses services et au droit en vigueur. La chaîne essentielle reste la même : risque identifié, test planifié, critère mesurable, résultat documenté, décision du propriétaire et confirmation de la clôture efficace des actions.

Les incohérences augmentent le coût du contrôle

Une documentation formellement complète perd sa valeur lorsqu’elle ne correspond pas à la situation réelle. L’autorité peut comparer les déclarations des politiques avec la configuration des systèmes, les tickets, les contrats, les listes d’accès, les résultats d’analyses, les comptes rendus de tests et les explications des propriétaires de processus. Il ne s’agit pas d’obtenir une cohérence purement rédactionnelle, mais de pouvoir suivre la décision depuis l’obligation et le risque identifiés jusqu’à la mesure de sécurité appliquée, à la preuve de son fonctionnement et à la réaction apportée à un écart.

Le contrôle à blanc réalisé avant l’intervention de l’autorité doit reposer sur un échantillon ciblé de services, d’incidents, de fournisseurs et de droits d’accès, puis remonter de la documentation vers les données sources. Cette démarche permet de détecter un inventaire d’actifs obsolète, des désignations différentes pour un même service, des risques sans propriétaire, des incidents absents du registre, des fournisseurs sans évaluation documentée ou des actions correctives clôturées sans vérification d’efficacité. Les divergences doivent être corrigées en établissant la situation réelle et le propriétaire de l’enregistrement, et non par une harmonisation ponctuelle des documents.

Dans une entreprise industrielle, la revue ne doit pas s’arrêter à l’environnement informatique de bureau. Pour un service donné, elle peut couvrir la maintenance, les automatismes, les accès distants des prestataires, la gestion des configurations et les dépendances entre les systèmes de production. L’inventaire des accès peut, par exemple, omettre un compte utilisé par un technicien externe alors que le contrat, la journalisation de la connexion et la configuration de l’équipement en confirment l’existence. L’importance de ces dépendances est présentée plus en détail dans NIS2 pour les entreprises industrielles : entités concernées, obligations introduites et préparation de l’organisation sans réduire le sujet à l’informatique.

La certification d’un système de management peut structurer le management des risques, la maîtrise documentaire, les audits et les actions correctives. Elle ne remplace toutefois ni l’analyse du périmètre juridique ni les preuves d’exécution des obligations propres à la KSC. Cette distinction est examinée dans NIS2 et NF EN ISO 27001 : ce que la certification apporte et ce qui reste nécessaire pour démontrer la conformité à la KSC. L’absence d’un enregistrement isolé ne permet pas nécessairement de conclure automatiquement à une non-conformité. Elle impose cependant d’évaluer l’importance de la preuve manquante, la cause de la lacune et la possibilité de démontrer le fonctionnement du dispositif au moyen d’autres éléments fiables.

Le coût du contrôle augmente surtout lorsque les preuves sont dispersées, les délégations peu claires et qu’aucune personne ne coordonne les réponses ni l’approbation des éléments transmis. Les équipes doivent alors rapprocher manuellement des données contradictoires pendant le contrôle. La désignation préalable d’un coordinateur, des responsables de chaque preuve et des règles de traitement des divergences réduit la charge de travail ainsi que le risque de fournir à l’autorité des explications incohérentes.

La préparation passe par un contrôle à blanc

Le contrôle interne à blanc doit commencer par la confirmation du statut de l’entité, du périmètre des services soumis aux obligations ainsi que des responsabilités de la direction et des propriétaires de processus. Le coordinateur des échanges avec l’autorité doit ensuite préparer une matrice de conformité reliant chaque obligation à son responsable et aux preuves correspondantes. Ce n’est qu’à partir de cette base qu’il convient d’examiner des échantillons d’enregistrements, d’interroger les personnes responsables et de reconstituer le déroulement d’un incident ou d’un test sélectionné. Le rôle de coordinateur doit de préférence être confié à une personne ayant accès à la direction et capable d’arbitrer les divergences, sans se substituer aux propriétaires opérationnels des preuves.

Chaque responsable d’une obligation doit être capable de présenter :

• le document-cadre qui définit les modalités d’exécution,
• l’enregistrement démontrant que l’obligation a été exécutée,
• l’indicateur permettant d’évaluer l’efficacité du dispositif,
• la dernière décision issue de la revue.

L’absence de l’un de ces éléments crée une rupture dans la chaîne de preuves. Une procédure de réponse aux incidents ne suffit pas si l’organisation ne peut pas présenter l’enregistrement de l’événement, le délai de réaction, l’évaluation des conséquences, le résultat de l’analyse des causes et la décision de modifier les mesures de sécurité. La reconstitution d’un cas permet aussi de vérifier si les explications des collaborateurs concordent avec les enregistrements et le déroulement réel des opérations.

Le contrôle à blanc doit également couvrir la logistique de l’inspection : réception et enregistrement de la demande, définition de l’échéance et du responsable de la réponse, approbation des pièces, protection des informations sensibles, identification des versions transmises et traçabilité des échanges avec l’autorité. Il est utile de simuler le cas où l’enregistrement demandé contient des données dépassant l’objet du contrôle ou nécessite une explication contextuelle. L’organisation peut ainsi déterminer qui décide du périmètre de communication et comment la transmission des éléments est tracée.

Le plan de remédiation doit hiérarchiser les lacunes selon leur impact sur les services, l’exposition juridique, la probabilité de détection et le temps nécessaire pour obtenir une preuve fiable d’efficacité — et non selon la facilité avec laquelle une nouvelle procédure peut être rédigée. La direction approuve les priorités, les ressources et le niveau de risque acceptable. Une action ne peut être clôturée qu’après une nouvelle vérification du dispositif.

Le calendrier doit être établi à partir du statut réel de l’entité, des échanges avec l’autorité et des dispositions actuellement applicables. Une fois le statut déterminé, l’analyse peut être complétée par NIS2 : autoévaluation et inscription au registre KSC – que doit faire une entreprise industrielle ? ainsi que Mise en œuvre de NIS2 après l’inscription au registre KSC – plan d’action jusqu’au 3 avril 2027. Les dates et obligations mentionnées dans ces contenus doivent être systématiquement confirmées au regard du droit en vigueur.