Demandez à une équipe infrastructure à quoi ressemblent les preuves de conformité NIS2, et vous obtiendrez généralement un dossier de politiques : une politique de sécurité de l'information, un plan de réponse aux incidents, un questionnaire fournisseur, le tout signé et versionné. Ces documents comptent, mais ce ne sont pas des preuves. Ils décrivent ce que vous avez l'intention de faire. La preuve, c'est l'enregistrement de ce que vous avez réellement fait - qui a changé la règle de pare-feu, quand, sous quelle autorité, et quelle était la configuration avant. Les évaluateurs demandent la seconde chose, et c'est dans l'écart entre les deux que la plupart des équipes commencent à être mal à l'aise.

Un rapide rappel de ce dont il s'agit. NIS2, formellement la directive (UE) 2022/2555, avait une échéance de transposition au 17 octobre 2024, et les lois nationales atterrissent depuis selon leur propre calendrier. Elle a élargi le périmètre bien au-delà des anciennes catégories NIS, a explicitement intégré les chaînes d'approvisionnement, et a attaché les obligations aux organes de direction personnellement plutôt qu'à une organisation abstraite. Si vous fournissez quoi que ce soit à une entité dans le périmètre, attendez-vous à ce que ses obligations arrivent sur votre bureau sous forme de clauses contractuelles, que vous soyez ou non directement concerné.

Ce que la directive demande réellement

L'article 21 liste les mesures de gestion des risques : politiques d'analyse des risques et de sécurité des systèmes d'information, gestion des incidents, continuité d'activité et sauvegarde, sécurité de la chaîne d'approvisionnement, sécurité dans l'acquisition et le développement, procédures d'évaluation de l'efficacité, hygiène cyber de base et formation, cryptographie, contrôle d'accès et gestion des actifs, et authentification multifacteur. Lisez cette liste comme un ensemble de questions auxquelles on vous demandera de répondre avec des enregistrements. Chaque point se termine par la même relance de la part d'un évaluateur : montrez-moi. Montrez-moi la sauvegarde que vous avez restaurée, l'accès que vous avez révoqué, le changement que vous avez approuvé.

L'article 23 est celui qui change l'ingénierie plutôt que la paperasse. Une alerte précoce dans les 24 heures suivant la prise de conscience d'un incident significatif. Une notification plus complète dans les 72 heures, incluant une évaluation initiale de la gravité et de l'impact. Un rapport final dans un délai d'un mois. Ces horloges démarrent au moment où vous en prenez conscience, ce qui fait de votre chronologie de détection une partie de la preuve elle-même. Si vous ne pouvez pas dire quand vous saviez, vous ne pouvez pas démontrer que vous avez notifié à temps - et une chronologie d'incident reconstituée de mémoire une semaine plus tard ne convainc personne.

Les preuves de conformité NIS2 sont des enregistrements

Voici la forme pratique de ce que demande un évaluateur. Une liste des systèmes dans le périmètre et de qui possède chacun d'eux. Un enregistrement des changements de configuration pertinents pour la sécurité sur une période donnée. La preuve que les accès ont été accordés, revus et retirés, avec des dates. La preuve que les sauvegardes n'ont pas seulement été prises mais aussi restaurées. Et pour chaque incident significatif, une chronologie que vous pouvez défendre : détection, escalade, confinement, notification. Le tout daté, attribuable à une identité nommée, et produit à partir d'autre chose que du souvenir d'une personne.

La vérité gênante, c'est que presque tout cela existe déjà quelque part dans chaque entreprise. C'est dans un système de tickets, un canal de chat, trois consoles, l'historique de terminal d'un ingénieur et une feuille de calcul. Le travail de conformité devient alors de l'archéologie : deux semaines pendant lesquelles quelqu'un reconstitue ce qui s'est passé à partir d'artefacts qui n'ont jamais été conçus pour être des preuves. C'est coûteux, c'est démoralisant, et ça produit un document auquel personne ne fait entièrement confiance - y compris la personne qui l'a assemblé.

La propriété qui fait d'un log une preuve

Un log devient une preuve quand il est append-only et infalsifiable de façon détectable. La distinction compte plus qu'il n'y paraît. Une table qu'un administrateur peut modifier est un enregistrement de ce que cet administrateur veut vous faire croire. Ce qu'un évaluateur veut, c'est une séquence dans laquelle toute modification d'une entrée antérieure est détectable, sans avoir à faire confiance à quiconque opère le système - nous y compris. C'est cette propriété qui transforme « voici nos logs » en quelque chose sur lequel un tiers peut s'appuyer plutôt que simplement recevoir.

La piste d'audit de Sencai est append-only et chaînée par hachage. Chaque entrée porte son propre hash et le hash de l'entrée qui la précède, de sorte que les enregistrements forment une chaîne plutôt qu'un tas. L'export CSV inclut les deux valeurs, entry_hash et prev_hash, ce qui signifie que votre auditeur n'a à nous croire sur parole pour rien. Il peut recalculer la chaîne lui-même, hors ligne, avec un script qu'il a écrit, et voir si elle tient. Si une seule entrée avait été modifiée ou supprimée, le recalcul cesse de correspondre à partir de ce point.

Les questions sur la chaîne d'approvisionnement qu'on vous posera

L'article 21 place la sécurité de la chaîne d'approvisionnement dans la liste, et l'article 20 rend la direction personnellement responsable de l'approbation et de la supervision de ces mesures, ce qui explique pourquoi ces questions arrivent désormais avec un vrai poids derrière elles. Attendez-vous à ce qu'on vous demande quels sous-traitants touchent à vos données, dans quelles juridictions ils opèrent, comment vous détecteriez une compromission provenant de l'un d'eux, et à quelle vitesse vous pourriez en retirer un. Si vous ne pouvez pas énumérer vos fournisseurs aujourd'hui, vous ne pouvez répondre à rien de tout cela - et un inventaire incomplet est le moyen le plus rapide d'échouer sur cette section.

C'est là que l'isolation par organisation et un vrai modèle de rôles cessent d'être des fonctionnalités produit et deviennent des réponses d'audit. Qui peut créer de l'infrastructure, qui peut seulement la consulter, qui a invité qui et quand, et lesquelles de ces invitations ont réellement été acceptées plutôt que simplement envoyées - ce sont des questions avec des dates attachées. La même chose s'applique à la configuration qui vous protège réellement : règles de pare-feu, limites réseau et enregistrements DNS, chacun avec un enregistrement de qui les a changés chez le fournisseur, et quand.

Comment se préparer sans département conformité

Commencez par écrire les questions auxquelles vous auriez du mal à répondre dans une pièce face à un évaluateur. Il y en a généralement quatre : qu'est-ce qu'on fait tourner, qui peut y toucher, qu'est-ce qui a changé le trimestre dernier, et comment prouve-t-on tout ça. Ensuite, corrigez l'enregistrement, pas le reporting. Un système qui capture les réponses au fil du travail ne coûte presque rien sur le moment ; les reconstituer après coup coûte des semaines, à chaque fois. NIS2 n'a pas créé cet écart - elle l'a juste rendu coûteux à conserver.

Rien de tout cela ne rend la conformité agréable. Ça en change la forme. Une preuve que vous pouvez exporter, remettre à un auditeur et le laisser vérifier de façon indépendante, c'est une conversation très différente d'un dossier de captures d'écran et d'une promesse que rien n'a été modifié. C'est la barre pour laquelle nous avons construit : votre parc en un seul endroit, les changements enregistrés au fil de l'eau, et un export conçu pour être vérifié par quelqu'un dont le métier entier est d'en douter.