Magic Quadrant™ pour la gestion des accès privilégiés 2026 : Netwrix reconnu pour la cinquième année consécutive. Téléchargez le rapport.

Centre de ressourcesBlog

Ce que l'application précoce de NIS2 nous apprend sur les pistes d'audit

Ce que l'application précoce de NIS2 nous apprend sur les pistes d'audit

Oct 16, 2026

Les autorités chargées de NIS2 adressent des mises en demeure à des entreprises qui disposaient de contrôles de sécurité mais ne pouvaient pas prouver qu'ils fonctionnaient. Le règlement d'exécution (UE) 2024/2690 de la Commission transforme les dix mesures générales de l'article 21 en plus de 150 contrôles précis, dont la journalisation et la surveillance. Les journaux d'audit échouent de deux façons : ils sont écrasés avant que quiconque les demande, ou les personnes visées par l'enquête peuvent les modifier. Six tests montrent si vos pistes d'audit tiendraient avant qu'un régulateur ne les vérifie.

La plupart des obligations de conformité commencent comme un exercice de case à cocher. Quelqu'un vérifie que la journalisation est activée, coche la case, et l'équipe passe à autre chose. Mais NIS2 change la donne. Les régulateurs réclament désormais la preuve de vos contrôles. Ils demandent si vous pouvez reconstituer ce qui s'est passé et si l'on peut se fier à vos enregistrements. Car si vous ne pouvez pas montrer qui a fait quoi et quand, ces contrôles pourraient tout aussi bien ne pas exister.

Les régulateurs veulent des preuves

Les montants des amendes sont difficiles à cerner. Les chiffres qui circulent en ligne varient selon les sources, et l'UE n'a pas encore créé de registre central des sanctions. La tendance récente en matière d'application en dit toutefois davantage.

Le BSI allemand a émis des dizaines de mises en demeure formelles. L'ANSSI française a rendu des ordres de correction dans l'énergie et les transports, en privilégiant la remédiation aux sanctions. Aux Pays-Bas, un examen d'entreprises d'infrastructures numériques essentielles a révélé que plus d'un tiers avaient des procédures de signalement des incidents faibles et que plus de la moitié n'avaient aucune politique de sécurité approuvée par la direction au dossier.

Chacun de ces constats se résume à une absence de preuves.

Où se trouvent les véritables exigences

La plupart des articles s'arrêtent à l'article 21, la partie de NIS2 qui énumère dix mesures de sécurité générales. Mais cet article est volontairement général. Le détail dont vous avez besoin figure dans le règlement d'exécution (UE) 2024/2690 de la Commission, en vigueur depuis novembre 2024. Il transforme ces dix mesures en plus de 150 contrôles précis. La journalisation et la surveillance, les contrôles qui sous-tendent votre piste d'audit, sont traitées à la section 3.2 de l'annexe.

Le règlement s'applique directement à un groupe défini d'entreprises, dont les fournisseurs de cloud et de centres de données, les fournisseurs DNS, les fournisseurs de services gérés et les places de marché en ligne. Les entreprises hors de cette liste ne sont pas formellement tenues de le respecter, mais c'est tout de même la référence qu'un régulateur est le plus susceptible d'utiliser. (Notre présentation de la conformité NIS2 détaille les critères permettant de savoir si NIS2 s'applique à vous.)

Les règles disent souvent des choses comme « le cas échéant » ou « dans la mesure du possible », ce qui ressemble à une marge de manœuvre. Mais il y a un piège : si vous décidez qu'une exigence ne s'applique pas à vous, vous devez consigner par écrit pourquoi. Choisir de ne pas journaliser un système est acceptable si vous avez documenté le raisonnement. Sinon, c'est un constat.

La preuve disparaît souvent avant que quiconque ne regarde

Les journaux de sécurité Windows sur les contrôleurs de domaine s'écrasent d'eux-mêmes par conception. Lorsqu'un journal atteint une limite de taille, les événements les plus anciens cèdent la place aux nouveaux. Cette limite, probablement fixée il y a des années par quelqu'un pour économiser de l'espace disque, ne tient pas compte des preuves. Sur un serveur très sollicité, le journal peut se renouveler en quelques minutes.

Mais comme la journalisation est activée et que de nouveaux enregistrements continuent d'arriver, personne ne remarque la perte. Quand un régulateur vous interroge sur un événement survenu il y a quatre mois, répondre que « la journalisation était activée » ne vous aidera pas.

Deux choses rapides à faire :

  • Vérifiez dès aujourd'hui combien de temps vos contrôleurs de domaine et vos serveurs critiques conservent les journaux. Le paramètre réel compte davantage que le document de politique.
  • Déterminez quelle part de votre fenêtre de preuves obligatoire votre plateforme d'audit peut interroger directement. Les données récentes sont généralement rapides à rechercher, tandis que les plus anciennes se trouvent dans une archive qui peut nécessiter une restauration. Testez cette récupération dès maintenant. L'article 23 de NIS2 vous donne 24 heures pour une alerte précoce. C'est un mauvais moment pour découvrir que retrouver une activité vieille de six mois prend des jours.

Des journaux qu'un administrateur peut modifier ne sont pas des preuves

NIS2 attend de vous que vous protégiez vos journaux contre les accès et modifications non autorisés.

Pensez à qui vous seriez amené à enquêter : généralement, un compte disposant de droits d'administrateur. Si vos données d'audit résident sur des systèmes que ce compte contrôle, l'un de ses premiers gestes peut être d'effacer les journaux. Et si Windows consigne qu'un journal a été effacé, il écrit cette entrée dans le journal même qui vient d'être vidé. Vous apprenez que l'historique a été effacé, mais pas ce qu'il contenait.

C'est pourquoi « combien de temps le conservons-nous ? » est la mauvaise première question. Une archive de sept ans qu'un administrateur peut modifier est plus fragile qu'une archive de six mois qu'il ne peut pas toucher. Un enregistrement fiable repose sur trois conditions :

  1. Un système extérieur à l'environnement surveillé collecte et stocke les données.
  2. Les personnes qui exploitent ces systèmes ne peuvent pas modifier l'historique stocké.
  3. Le magasin d'audit enregistre chaque modification qui lui est apportée.

C'est la deuxième condition que les entreprises respectent le moins. Le compte qui collecte les données d'audit est souvent un administrateur de domaine parce que c'était le plus simple à configurer. Ainsi, un attaquant qui prend le contrôle d'un identifiant d'administrateur accède aussi aux preuves. Vérifiez dès aujourd'hui qui dispose d'un accès en écriture à votre base de données et à votre archive d'audit.

La troisième exigence est la plus facile à négliger. Votre plateforme doit vous indiquer quand les journaux d'audit ont été effacés, quand les paramètres d'audit ont changé et qui a consulté le magasin. Si elle ne le peut pas, vos preuves n'ont aucune preuve derrière elles.

Six tests à réaliser avant qu'un régulateur ne le fasse

Bloquez deux heures, prenez un chronomètre et essayez de produire la preuve de chacun de ces cas dans votre environnement réel :

  1. Un compte privilégié est compromis. Pouvez-vous voir tout ce qu'il a fait, sur tous les systèmes, dans l'ordre ?
  2. Quelqu'un obtient des autorisations qu'il ne devrait pas avoir. Pouvez-vous dire qui les a accordées et quand, même à travers des groupes imbriqués ?
  3. Un paramètre critique change. Pouvez-vous montrer ce qu'il était avant et ce qu'il est maintenant ?
  4. Un compte suspect apparaît. Pouvez-vous dire qui l'a créé et ce qu'il a fait ensuite ?
  5. Un incident touche plusieurs systèmes. Pouvez-vous construire une chronologie claire assez vite pour appuyer l'alerte précoce de 24 heures de l'article 23 ?
  6. Quelqu'un a effacé un journal de sécurité mardi dernier. Le sauriez-vous, et pourriez-vous montrer comment vous le savez ?

Attribuez-vous une note et consignez la période testée. Les équipes réussissent souvent pour la semaine dernière mais échouent pour le trimestre dernier. C'est cet écart que l'exercice met en évidence. Et « oui, mais il a fallu trois jours et cinq équipes » est un échec. Le compte à rebours de 24 heures ne se soucie pas du nombre de personnes dont vous avez eu besoin.

Où Netwrix Auditor trouve sa place

Les six tests se ramènent à une seule capacité : un historique fiable de qui a modifié quoi, quand, et de ce que c'était avant, stocké dans un endroit que l'environnement surveillé ne peut pas réécrire discrètement.

Netwrix Auditor collecte l'activité de modification, d'accès et d'administration d'Active Directory, d'Entra ID, de Microsoft 365, des serveurs de fichiers, de SQL Server et d'autres sources dans son propre magasin d'audit. Votre historique ne dépend plus de la durée pendant laquelle un contrôleur de domaine conserve ses journaux.

Il existe aussi un pack de rapports NIS2 qui correspond étroitement aux six tests. Par exemple, Administrative Group Membership Changes couvre le test 1 et Account Permissions Reports couvre le test 2. Audit Log Clearing et Local Audit Policy Changes couvrent le test 6, et Access to Archive Data montre qui a consulté les preuves elles-mêmes. Un guide de correspondance des exigences NIS2 vous aide à montrer à un régulateur le lien entre chaque exigence et un rapport.

Aucun outil d'audit ne vous rend conforme à NIS2 à lui seul. L'article 21 couvre bien plus que la surveillance, mais chacune de ses mesures doit finalement être prouvée, et la preuve vient des éléments d'audit. Sans eux, un contrôle qui fonctionne et un contrôle absent se ressemblent aux yeux d'un régulateur.

À retenir

L'application précoce est un signal de la direction que prennent les régulateurs européens. La conformité passe de ce que dit votre politique à ce que vous pouvez démontrer.

Faites donc les six tests, en les visant sur une date remontant à quatre mois. Si l'un d'eux échoue, faites de sa correction la priorité de cette semaine, avant qu'un régulateur ne rende cette même correction plus coûteuse.

Partager sur

En savoir plus

À propos de l'auteur

Asset Not Found

Evan Anandappa