NIS2 au Luxembourg : votre entreprise est-elle concernée et que devez-vous faire concrètement ?

NIS2 n’est plus un texte européen « qui arrivera un jour ».

Au Luxembourg, la directive a été transposée par la loi du 5 mai 2026 concernant des mesures destinées à assurer un niveau élevé de cybersécurité. Elle élargit fortement le nombre d’organisations concernées, renforce les exigences de gestion des risques et de notification des incidents, et implique directement les organes de direction. ILR

Mais NIS2 pose aussi un problème très pratique : beaucoup d’entreprises ne savent pas encore clairement si elles entrent dans son champ d’application — et, lorsqu’elles le savent, par où commencer.

La première chose à comprendre est simple :

NIS2 n’est pas uniquement un sujet de cybersécurité ou un projet à confier au service IT. C’est un sujet de gestion des risques et de gouvernance de l’entreprise.

Première question : votre entreprise est-elle concernée ?

NIS2 ne s’applique pas à toutes les entreprises de la même manière.

Il faut d’abord regarder l’activité de l’entreprise, puis sa taille.

La loi couvre notamment des organisations actives dans l’énergie, le transport, la santé, l’eau, les infrastructures numériques, les services TIC interentreprises, les services postaux, la gestion des déchets, certaines activités industrielles et manufacturières, la chimie, l’alimentaire, les fournisseurs numériques ou encore la recherche. La liste précise et les sous-secteurs figurent dans les annexes I et II de la loi. ILR

Ensuite intervient ce que l’ILR appelle le « size-cap ».

Une entreprise active dans un secteur concerné entre par défaut dans le champ d’application lorsqu’elle atteint certains critères de taille. L’ILR considère notamment comme moyenne une entité comptant au moins 50 personnes et jusqu’à 249 personnes, ou atteignant certains seuils financiers. Le calcul ne s’arrête pas nécessairement à la société luxembourgeoise : les entreprises liées et partenaires peuvent devoir être prises en compte au niveau du groupe. ILR

Et attention : être en dessous de ces seuils ne suffit pas toujours à exclure NIS2. Certaines catégories sont soumises à des règles particulières, et une organisation peut également être identifiée comme essentielle ou importante indépendamment de sa taille, notamment en raison de sa criticité. ILR

L’ILR a d’ailleurs mis en ligne un simulateur officiel permettant d’effectuer une première évaluation à partir du secteur, de la présence dans l’Union européenne et de la taille de l’organisation. Le résultat reste indicatif et ne remplace pas l’analyse juridique ou l’auto-enregistrement officiel. NIS 2 Simulator

Si vous êtes concerné, l’auto-enregistrement n’est pas facultatif

Les entités entrant dans le champ d’application doivent s’auto-enregistrer auprès de l’autorité compétente.

Au Luxembourg, le délai général fixé après l’entrée en vigueur de la loi était le 10 juillet 2026. L’ILR précise également que l’absence d’auto-enregistrement ne dispense pas une organisation de ses obligations NIS2. ILR

Autrement dit, si votre entreprise est concernée mais que cette étape n’a pas encore été réalisée, ce n’est pas un sujet à remettre au prochain renouvellement de votre infrastructure.

C’est la première chose à clarifier.

Entité essentielle ou entité importante : quelle différence ?

NIS2 distingue principalement deux catégories : les entités essentielles et les entités importantes.

Sur le plan des mesures de cybersécurité, les exigences sont largement similaires. La principale différence porte sur la manière dont elles sont supervisées.

Les entités essentielles font l’objet d’une supervision ex ante et ex post, tandis que les entités importantes sont principalement supervisées ex post, par exemple lorsqu’un élément laisse penser qu’elles ne respectent pas leurs obligations. ILR

Pour les entités essentielles, l’ILR prévoit notamment des livrables réguliers comprenant :

• une description des mesures de cybersécurité en place ;
• une analyse des principaux scénarios de risques cyber ;
• un plan d’action pluriannuel ;
• et, pour certaines entités, une liste de leurs dépendances envers des fournisseurs ou prestataires.

L’ILR a déjà publié en août 2026 des modèles destinés à structurer ces éléments. ILR

Cela donne une bonne indication de l’esprit de NIS2 :

il ne suffit plus d’affirmer que l’entreprise est sécurisée. Il faut pouvoir démontrer comment les risques sont identifiés, traités, suivis et gouvernés.

NIS2 ne se résume pas à installer un antivirus et activer le MFA

Une erreur serait de transformer NIS2 en liste d’achats techniques :

EDR : fait.
MFA : fait.
Firewall : fait.
Backup : fait.

Ces éléments peuvent évidemment être nécessaires, mais la logique de NIS2 est plus large.

Les mesures doivent reposer sur une approche de gestion des risques et couvrir notamment la gouvernance, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le contrôle des accès, la cryptographie et d’autres mesures organisationnelles et techniques. ILR

Prenons un exemple simple.

Une entreprise peut disposer :

• d’un excellent firewall ;
• de Microsoft Defender ;
• de MFA ;
• de sauvegardes quotidiennes.

Mais si personne ne sait :

• quels systèmes sont réellement critiques ;
• combien de temps l’entreprise peut fonctionner sans eux ;
• qui décide en cas d’incident ;
• qui doit être appelé ;
• si les sauvegardes ont déjà été restaurées ;
• quels fournisseurs sont nécessaires à la continuité du service ;

alors le problème n’est plus uniquement technique.

C’est précisément la dimension que NIS2 cherche à structurer.

La direction est directement concernée

C’est probablement l’un des changements les plus importants par rapport à la manière dont certaines entreprises abordaient historiquement la cybersécurité.

NIS2 responsabilise les organes de direction : ils doivent approuver les mesures de gestion des risques cyber, superviser leur mise en œuvre et acquérir une compréhension suffisante des risques pour pouvoir prendre les décisions nécessaires. Eur-Lex

Cela ne signifie pas qu’un dirigeant doit devenir ingénieur sécurité.

L’ILR le dit d’ailleurs très clairement dans ses lignes directrices : NIS2 ne demande pas aux dirigeants de devenir des experts techniques, mais d’être informés, impliqués et responsables en matière de cybersécurité. ILR

En pratique, une direction devrait donc être capable de répondre à des questions comme :

Quels sont nos principaux risques cyber ?

Quels systèmes sont critiques pour notre activité ?

Quelle serait la conséquence d’une indisponibilité de 4 heures, 24 heures ou plusieurs jours ?

Nos sauvegardes permettent-elles réellement de reconstruire l’environnement ?

Quels prestataires externes représentent une dépendance critique ?

Quelles actions de sécurité restent à mettre en œuvre et avec quelle priorité ?

Si ces réponses n’existent que dans la tête de l’administrateur système ou du prestataire informatique, la gouvernance n’est probablement pas encore suffisamment mature.

La chaîne de fournisseurs fait partie du problème

NIS2 ne s’arrête pas à la porte de l’entreprise.

Les risques liés aux fournisseurs et prestataires de services font partie intégrante de l’approche attendue. L’ILR peut d’ailleurs demander à certaines entités essentielles de communiquer leurs dépendances envers leurs fournisseurs directs et prestataires de services. ILR

Cela concerne évidemment les prestataires IT, mais aussi potentiellement :

• les fournisseurs cloud ;
• les éditeurs d’applications métiers ;
• les prestataires de sauvegarde ;
• les datacenters ;
• les sociétés de télécommunications ;
• les fournisseurs de services de sécurité ;
• ou tout prestataire dont l’indisponibilité pourrait bloquer une activité critique.

La question n’est donc plus seulement :

« Mon fournisseur est-il fiable ? »

mais aussi :

« Que se passe-t-il pour mon entreprise si ce fournisseur devient indisponible ? »

C’est une différence importante.

En cas d’incident, les délais sont courts

Une organisation soumise à NIS2 doit également être capable de reconnaître un incident important et de déclencher rapidement son processus de notification.

Au Luxembourg, la procédure prévoit notamment :

-> dans les 24 heures : une notification préliminaire ;

-> dans les 72 heures : une notification formelle mise à jour ;

-> dans le mois suivant la notification : un rapport final, sous réserve des dispositions applicables lorsque l’incident est toujours en cours. ILR

Ces délais commencent à courir alors que l’équipe technique est généralement déjà occupée à comprendre et contenir l’incident.

Ce n’est donc pas le moment de découvrir :

• qui doit décider si l’incident est significatif ;
• quelle autorité contacter ;
• qui rassemble les informations ;
• qui communique avec les clients ;
• où se trouve la procédure ;
• ou qui dispose des accès nécessaires.

Un processus de gestion d’incident qui n’existe que le jour de l’incident est déjà en retard.

Et DORA dans tout ça ?

Pour les acteurs du secteur financier, il faut distinguer NIS2 du règlement DORA, applicable depuis le 17 janvier 2025 aux entités financières relevant de son champ d’application. DORA encadre notamment la gestion des risques TIC, les incidents, les tests de résilience opérationnelle et les risques liés aux prestataires TIC tiers. CSSF

DORA constitue, pour les exigences qu’il couvre de manière équivalente, un régime sectoriel spécifique par rapport à NIS2. Cela évite en principe d’appliquer deux fois des obligations équivalentes de gestion des risques ou de notification. Eur-Lex

Pour une entité financière, la bonne question n’est donc pas :

« Dois-je choisir entre DORA et NIS2 ? »

mais plutôt :

« Quelles obligations relèvent de DORA, lesquelles restent éventuellement applicables sous NIS2, et quelle autorité supervise mon activité ? »

Cette analyse doit être réalisée au cas par cas.

Par où commencer concrètement ?

La bonne nouvelle est qu’une démarche NIS2 ne commence pas nécessairement par un projet complexe.

Elle commence par obtenir une vision claire de la situation.

1. Confirmer le périmètre réglementaire

Secteur d’activité, taille de l’organisation, structure du groupe et éventuelles exceptions.

Le simulateur de l’ILR constitue un bon premier filtre, mais une situation complexe peut nécessiter une validation juridique ou réglementaire. NIS 2 Simulator

2. Identifier les actifs et services critiques

Quels systèmes permettent réellement à l’entreprise de fonctionner ?

Serveurs, Microsoft 365, applications métiers, données, réseau, identités, cloud, fournisseurs…

On ne peut pas protéger correctement ce que l’on ne connaît pas.

3. Réaliser une analyse de risques

Pour chaque scénario pertinent :

• quelle est la probabilité ?
• quel serait l’impact ?
• quelles protections existent déjà ?
• quel risque reste-t-il ?
• ce risque est-il acceptable ?

L’ILR précise d’ailleurs que les modèles de supervision qu’il fournit ne remplacent pas l’analyse de risques propre à l’entreprise. ILR

4. Vérifier les fondamentaux techniques

Par exemple :

• comptes administrateur ;
• MFA ;
• contrôle des accès ;
• protection des postes et serveurs ;
• segmentation ;
• mises à jour ;
• sauvegardes ;
• restauration ;
• chiffrement ;
• supervision ;
• journalisation.

Mais toujours en fonction des risques réellement identifiés.

5. Vérifier la continuité

Une sauvegarde n’est pas encore un plan de continuité.

Il faut savoir :

• ce qui doit redémarrer en priorité ;
• dans quel délai ;
• avec quelles données ;
• avec quelles personnes ;
• et avec quelles dépendances externes.

Et surtout : tester.

6. Préparer la gestion des incidents

Qui décide ?

Qui intervient ?

Qui notifie ?

Qui communique ?

Quelles informations doivent être disponibles dans les 24 premières heures ?

Ces réponses doivent exister avant l’incident.

7. Cartographier les fournisseurs critiques

Pour chaque dépendance importante :

• quel service fournit-elle ?
• quelles données traite-t-elle ?
• existe-t-il une alternative ?
• quelles garanties contractuelles existent ?
• que se passe-t-il si le fournisseur devient indisponible ?

8. Documenter et construire un plan d’action

Tous les risques ne seront pas corrigés en une semaine.

Ce n’est d’ailleurs pas l’objectif.

Une organisation mature doit pouvoir dire :

Voilà où nous en sommes, voilà les risques identifiés, voilà ceux que nous avons traités, et voilà notre plan pour les autres.

C’est nettement plus crédible qu’une checklist remplie une fois puis oubliée.

NIS2 est avant tout une démarche de maîtrise des risques

La conformité n’est finalement qu’une partie du sujet.

Une entreprise qui sait précisément quels sont ses actifs critiques, ses dépendances, ses risques, ses sauvegardes, ses procédures et ses priorités est aussi une entreprise mieux préparée à faire face à un ransomware, une panne majeure ou la défaillance d’un fournisseur.

Chez Mensialis, nous abordons donc NIS2 de la même manière que nos autres sujets de cybersécurité : commencer par comprendre l’environnement et les risques avant de proposer des outils ou des changements techniques.

Un audit IT et cybersécurité permet notamment de cartographier l’existant, identifier les écarts, vérifier les fondamentaux techniques et transformer les constats en un plan d’action priorisé.

Vous ne savez pas encore si votre environnement IT est prêt pour NIS2 ? Commençons par faire le point.

Un audit permet de cartographier l’existant, d’identifier les principaux écarts et de construire un plan d’action priorisé.

Cet article présente les principaux aspects opérationnels de NIS2 au Luxembourg et ne constitue pas un avis juridique. La détermination du champ d’application et l’interprétation des obligations réglementaires doivent être validées selon la situation propre à chaque organisation.