NIS2 et conservation des logs : ce que les organisations régulées doivent traiter

NIS2 est souvent présentée comme un sujet juridique ou de conformité. En pratique, c'est aussi un sujet de direction, d'exploitation et de capacité à prouver ce qui s'est réellement passé. Une organisation peut avoir des politiques, des procédures et des responsabilités bien formalisées. Si elle ne peut pas reconstituer une chronologie d'incident, démontrer des accès, expliquer des changements critiques ou retrouver des éléments de preuve utilisables, sa position reste fragile.

Pour de nombreuses PME et organisations de taille intermédiaire, le défi n'est donc pas seulement de savoir si NIS2 les concerne. Le vrai défi consiste à passer d'un empilement de mesures dispersées à un socle défendable de traçabilité, de préparation aux incidents et de conservation des journaux. C'est là que la centralisation des logs, leur conservation hors des systèmes sources et la qualité de la preuve deviennent des sujets centraux.

Ce contenu ne constitue pas un conseil juridique. Il sert de guide pratique pour les directions, responsables IT, équipes infrastructure, MSP et fonctions sécurité, risque ou conformité qui doivent comprendre les implications opérationnelles de NIS2.

Pour qui cette page est faite

Cette page s'adresse surtout :

aux dirigeants, directeurs généraux et propriétaires d'entreprise,
aux responsables IT et responsables infrastructure,
aux administrateurs externes et MSP,
aux équipes sécurité, risque et conformité,
aux organisations qui ne savent pas encore si elles sont directement concernées ou si la pression viendra surtout de clients régulés.

Ce que vous devez en retenir

Après lecture, vous devriez mieux comprendre :

ce que NIS2 change en pratique,
quels types d'organisations sont généralement concernés,
pourquoi la documentation seule ne suffit pas,
pourquoi les logs sont essentiels pour les audits, les incidents et la traçabilité,
quelles sources de logs doivent être priorisées,
pourquoi les logs stockés uniquement en local sont un point faible en cas de compromission,
quand une approche centralisée ou SaaS devient pertinente.

Ce que NIS2 change concrètement

NIS2 est la directive européenne destinée à élever le niveau commun de cybersécurité dans les États membres. Elle élargit le périmètre des secteurs concernés, renforce les attentes en matière de gestion des risques, rend la responsabilité de la direction plus explicite et accentue les exigences autour du signalement des incidents significatifs.

Le point important est le suivant : NIS2 ne vise pas seulement un petit nombre d'opérateurs considérés comme critiques au sens traditionnel. Elle touche un éventail plus large d'organisations, y compris de nombreuses structures de taille intermédiaire, des opérateurs de services numériques, des acteurs industriels, des organisations de santé, des entités de service public et d'autres structures qui fournissent des services importants.

Pour la direction, cela change la nature du sujet. La cybersécurité ne peut plus être traitée uniquement comme une affaire technique déléguée à l'IT. Elle devient une question de pilotage, de preuve, de capacité à prendre des décisions sous contrainte et de défense de la position de l'organisation face à un auditeur, un client, un assureur ou une autorité.

Pourquoi NIS2 concerne autant la direction que l'IT

Vu de la direction, NIS2 pose des questions très concrètes :

qui porte le sujet au niveau exécutif,
quel niveau de risque l'organisation accepte réellement,
quel budget est alloué à un minimum défendable,
quelle capacité existe pour expliquer un incident ou une défaillance avec des faits.

Vu de l'IT, les questions sont tout aussi concrètes :

quelles sources de logs sont effectivement collectées,
quelles preuves restent disponibles après un incident,
à quelle vitesse une chronologie peut être reconstruite,
si les journaux critiques sont protégés contre la suppression ou la manipulation.

Le sujet devient alors commun à la direction et à l'IT : la direction doit exiger des éléments crédibles, et l'IT doit pouvoir fournir autre chose qu'une déclaration générale du type "le logging est en place".

La responsabilité de la direction est détaillée plus loin sur NIS2 pour la direction.

Quelles organisations sont généralement concernées

NIS2 s'applique à des organisations opérant dans des secteurs considérés comme importants pour l'économie, la société ou les services essentiels. On retrouve notamment :

l'énergie,
les transports,
la santé,
les infrastructures numériques,
certaines administrations publiques,
certains services numériques,
l'eau, les eaux usées et les déchets,
certaines activités industrielles et de fabrication.

En pratique, le périmètre ne dépend presque jamais d'un seul critère. Il faut généralement tenir compte :

de la nature du service réellement fourni,
du secteur d'activité,
de la taille de l'organisation,
de son appartenance éventuelle à un groupe,
de son importance opérationnelle dans une chaîne de service ou de sous-traitance.

Autrement dit, la question "sommes-nous une infrastructure critique ?" est souvent trop grossière pour être utile. Une meilleure première question consiste à déterminer si l'organisation fournit un service relevant d'un secteur visé et si la combinaison secteur, taille et rôle la place vraisemblablement dans le périmètre.

Pour une première analyse structurée, poursuivez avec Votre organisation relève-t-elle de NIS2 ?.

Des niveaux d'obligations différents, pas seulement une nuance juridique

Toutes les organisations concernées ne feront pas l'objet du même niveau d'attente, de supervision et de charge de preuve. Pour un public francophone international, il est plus juste de parler de niveaux d'obligations, de degré de supervision ou d'intensité des attentes, plutôt que de reprendre mécaniquement des catégories propres à un cadre national particulier.

Sur le plan opérationnel, cette distinction a des conséquences réelles :

le niveau de formalisation attendu de la gouvernance change,
la profondeur de la preuve demandée varie,
la capacité à reconstituer des accès, des changements et des incidents devient plus ou moins critique,
la discipline de conservation et de restitution des éléments probants prend plus ou moins de poids.

Cela n'efface pas la nécessité des logs dans les organisations soumises à des attentes plus légères. Cela signifie seulement que la profondeur, la rigueur et la vitesse de restitution attendues ne seront pas identiques partout.

Le sujet est développé sur Les différents niveaux d'obligations NIS2.

Ce que NIS2 ne signifie pas automatiquement

NIS2 suscite souvent deux mauvaises lectures opposées.

La première consiste à minimiser le sujet : quelques documents, quelques contrôles de base et le problème serait réglé. La seconde consiste à imaginer qu'il faut immédiatement construire un SOC complet, acheter un SIEM d'entreprise et collecter tous les logs possibles dès le premier jour.

Dans la majorité des cas, aucune de ces deux approches n'est la bonne. NIS2 ne signifie pas automatiquement :

qu'il faut bâtir son propre SOC,
qu'un SIEM complet est obligatoire avant toute action utile,
qu'un pack documentaire suffit à rendre la position défendable,
que des logs locaux dispersés constituent une base de preuve acceptable,
qu'il suffit d'externaliser l'exploitation à un prestataire pour externaliser la responsabilité.

Pour beaucoup d'organisations, un minimum réaliste et robuste vaut plus qu'une architecture ambitieuse qu'elles ne sauront pas faire vivre dans la durée.

Pourquoi la documentation seule ne suffit pas

Les politiques, procédures, rôles et plans de réponse sont nécessaires. Mais ils décrivent surtout l'intention. Ils ne répondent pas, à eux seuls, aux questions qui apparaissent lors d'un audit ou après un incident :

qui a accédé au système concerné,
quand l'activité suspecte a commencé,
quels changements ont précédé l'événement,
quels comptes et quels systèmes ont été impliqués,
sur quelles données l'organisation s'est appuyée pour qualifier l'incident,
ce qu'elle peut démontrer de manière rétroactive.

Sans journaux exploitables et sans éléments conservés hors des systèmes concernés, la réponse bascule rapidement dans la reconstruction manuelle, les captures d'écran, les souvenirs d'administrateurs et les hypothèses incomplètes. C'est une faiblesse pour l'IT, mais aussi pour la direction, qui doit pouvoir justifier des arbitrages et démontrer une réaction proportionnée.

Pourquoi les logs comptent pour l'audit, les incidents et la traçabilité

Les logs ne sont pas seulement des traces techniques. Ce sont la matière première de la preuve.

Pour l'audit

Les auditeurs et les fonctions de contrôle veulent généralement voir si l'organisation peut retracer des faits importants :

tentatives de connexion,
changements de privilèges,
actions administratives,
changements de configuration,
événements de sécurité sur une période donnée.

Sans cette capacité, l'organisation peut affirmer qu'un contrôle existe, mais peine à montrer qu'il a réellement fonctionné.

Pour la gestion d'incident

Lorsqu'un incident survient, il faut reconstituer rapidement :

ce qui s'est passé,
quand cela a commencé,
quels systèmes ont été touchés,
quelles identités ont été utilisées,
si l'événement est encore en cours.

Si les preuves n'existent que sur les systèmes compromis, la reconstruction devient immédiatement plus fragile.

Pour la traçabilité interne

Tous les cas ne sont pas des incidents majeurs déclarables. Les organisations doivent aussi enquêter sur :

des accès inhabituels,
des changements non expliqués,
des erreurs d'administration,
des signes d'usage abusif de comptes,
des désaccords avec un prestataire ou un administrateur externe.

Les logs permettent de distinguer l'hypothèse du fait.

Pour la défendabilité réglementaire

Lorsqu'une organisation doit qualifier un incident et expliquer ses premières décisions, elle doit pouvoir s'appuyer sur une base probante crédible. Une preuve conservée en dehors du système attaqué renforce fortement cette position.

Quelles sources de logs prioriser

Un minimum utile commence rarement par "tout collecter". Il commence plutôt par quelques couches à forte valeur probante.

Identité et accès

Les systèmes d'identité, comme Active Directory, Entra ID ou tout autre IAM, font souvent partie des sources les plus précieuses. Sans historique d'authentification, de privilèges et d'actions administratives, une grande partie des scénarios d'enquête reste faible.

Serveurs Windows clés et endpoints sélectionnés

Tout poste utilisateur n'a pas besoin d'entrer dans la première vague. En revanche, les contrôleurs de domaine, serveurs de rebond, postes d'administration, serveurs critiques et systèmes à privilèges élevés doivent généralement être couverts tôt.

Firewalls, VPN et contrôles réseau

L'accès distant, les mouvements réseau et les changements de règles sont essentiels pour comprendre l'étendue et la chronologie d'un incident.

Hyperviseurs, NAS et appliances d'infrastructure

Ces couches sont souvent sous-collectées alors qu'elles contiennent des éléments très utiles sur les accès administratifs, les changements de configuration et l'activité sur des services critiques.

Cloud et SaaS

Pour beaucoup d'organisations, la preuve ne se limite plus à l'on-premise. Les événements d'administration, d'identité et de sécurité provenant de Microsoft 365, Google Workspace, d'IaaS, de PaaS ou de solutions SaaS métiers sont souvent indispensables.

Le détail pratique est couvert sur Quels logs faut-il pour l'audit et NIS2 ?.

À quoi ressemble un minimum réaliste

Pour une PME ou une organisation de taille intermédiaire, un minimum réaliste comprend souvent :

une collecte centralisée en dehors des systèmes sources,
une couverture des identités, serveurs clés, firewalls, VPN et services cloud critiques,
une conservation alignée sur les besoins d'audit et de gestion d'incident,
des vérifications régulières pour confirmer que la collecte fonctionne réellement,
la capacité à retrouver rapidement des éléments probants en cas d'enquête.

Ce minimum n'est pas un renoncement à la maturité. C'est un point de départ exploitable. Une fois cette base stabilisée, il devient logique d'élargir la couverture, d'ajouter des corrélations, des alertes ou des analyses plus poussées.

Pourquoi les logs locaux sont un point faible

C'est l'un des messages les plus importants de tout le sujet. Les logs conservés uniquement sur le serveur, l'équipement ou l'application d'origine sont vulnérables en cas de compromission.

Les attaquants cherchent souvent à :

modifier les traces locales,
les supprimer,
les faire disparaître par écrasement,
réduire ou désactiver le logging,
rendre le système indisponible avant l'extraction des preuves.

Quand la preuve est conservée en dehors du système touché, l'organisation réduit fortement le risque de perdre précisément les données dont elle aura le plus besoin. La collecte et la conservation centralisées hors des systèmes sources ne sont donc pas un confort d'architecture : c'est une mesure concrète pour l'audit, l'enquête et la défendabilité réglementaire.

Ce point est approfondi sur Audit, traçabilité et preuve.

Quel lien avec le signalement d'incident

NIS2 renforce la pression sur la qualification et le signalement rapides des incidents significatifs. Sans entrer ici dans le détail de chaque transposition nationale, une organisation doit généralement pouvoir expliquer dans des délais courts :

si l'événement est réellement significatif,
quels services ou systèmes sont affectés,
quelle peut être la chronologie probable,
sur quelles données reposent ses premières conclusions.

Sans logs centralisés et conservés hors des systèmes touchés, ce travail devient un exercice d'estimation. Avec une base de preuve centralisée, l'organisation peut construire plus vite un récit factuel, l'affiner au fil du temps et justifier ses décisions initiales.

Quand une approche centralisée ou SaaS est pertinente

Une pile de gestion de logs auto-hébergée peut convenir à des organisations disposant de ressources internes solides. Mais pour beaucoup de structures intermédiaires, le besoin immédiat est plus simple :

mettre en place rapidement une conservation fiable,
protéger la preuve en dehors des systèmes sources,
limiter la charge d'exploitation,
éviter de lancer trop tôt un programme SOC/SIEM surdimensionné.

Une approche centralisée ou SaaS a donc du sens lorsque l'objectif est d'établir rapidement une base défendable pour l'audit, l'investigation et la traçabilité, sans transformer le sujet en grand chantier d'infrastructure.

Sources officielles et lectures complémentaires

Pour évaluer vos obligations, appuyez-vous autant que possible sur des sources primaires et sur la guidance officielle :

le texte de la directive NIS2 sur EUR-Lex,
les pages officielles de la Commission européenne,
la guidance des autorités nationales compétentes,
les outils officiels d'évaluation du périmètre lorsqu'ils existent.

Dans ce hub, les pages les plus utiles ensuite sont :

FAQ

Faut-il collecter les logs de tous les systèmes ?

Non. Pour la plupart des organisations, une priorisation claire a plus de valeur qu'une collecte indiscriminée. Il faut commencer par les identités, les serveurs clés, les firewalls, les VPN, certains services cloud et les systèmes à forte valeur probante.

NIS2 signifie-t-elle qu'il faut un SIEM immédiatement ?

Pas nécessairement. Il faut surtout de la preuve, de la traçabilité et une conservation exploitable. Pour certaines organisations, cela conduira ensuite vers un SIEM. Pour d'autres, la bonne première étape sera une centralisation fiable des journaux.

Les logs locaux suffisent-ils s'ils sont conservés longtemps ?

Non. Une rétention longue sur un système compromis ne règle pas le problème de fond : ces données restent exposées à la suppression, à la manipulation ou à la perte d'accès.

Ce sujet n'est-il utile que si nous sommes déjà certains d'être dans le périmètre ?

Non. Les mêmes principes comptent aussi pour les fournisseurs d'organisations régulées et pour les structures qui effectuent encore une première analyse interne.

Existe-t-il une durée de rétention unique imposée par NIS2 ?

Non. La bonne durée dépend des exigences d'audit, des besoins d'investigation, du profil de risque et de la réalité opérationnelle. Ce qui compte, c'est que cette durée soit défendable et que les données restent réellement utilisables.

Prochaine étape

Si vous voulez transformer cela en point de départ concret :

Télécharger la checklist pour une première revue interne de la pertinence NIS2 et du niveau actuel de logging.
Demander une consultation initiale pour définir à quoi ressemble un socle de preuve réaliste dans votre environnement.
S'inscrire aux préinscriptions / actualités autour d'un standard minimal de logging pour l'audit, les incidents et la traçabilité.