NIS2 in Luxembourg: Is Your Company Affected and What Do You Need to Do in Practice?

NIS2 is no longer a European text that will “arrive one day”.

In Luxembourg, the directive was transposed by the law of 5 May 2026 concerning measures intended to ensure a high level of cybersecurity. It significantly broadens the number of organizations concerned, strengthens requirements around risk management and incident reporting, and directly involves management bodies. ILR

But NIS2 also raises a very practical issue: many companies still do not clearly know whether they fall within its scope — and, when they do, where to start.

The first thing to understand is simple:

NIS2 is not just a cybersecurity topic or a project to hand over to the IT department. It is a matter of risk management and corporate governance.

First question: is your company affected?

NIS2 does not apply to every company in the same way.

You first need to look at the company’s activity, and then at its size.

The law covers, among others, organizations active in energy, transport, healthcare, water, digital infrastructure, B2B ICT services, postal services, waste management, certain industrial and manufacturing activities, chemicals, food production, digital providers and research. The exact list of sectors and sub-sectors is set out in Annexes I and II of the law. ILR

The next factor is what the ILR refers to as the “size cap”.

A company operating in a covered sector generally falls within the scope when it reaches certain size criteria. The ILR considers, in particular, an entity with at least 50 and up to 249 employees to be medium-sized, or an entity that meets certain financial thresholds. The assessment does not necessarily stop at the Luxembourg company itself: linked and partner enterprises may also need to be taken into account at group level. ILR

And importantly: being below these thresholds does not always mean that NIS2 does not apply. Some categories are subject to specific rules, and an organization may also be identified as essential or important regardless of its size, particularly because of the critical nature of its services. ILR

The ILR also provides an official simulator that allows organizations to perform an initial assessment based on their sector, presence in the European Union and company size. The result is indicative and does not replace legal analysis or the official self-registration process. NIS2 Simulator

If you are affected, self-registration is mandatory

Organizations falling within the scope must self-register with the competent authority.

In Luxembourg, the general deadline following the entry into force of the law was 10 July 2026. The ILR also makes it clear that failure to self-register does not exempt an organization from its NIS2 obligations. ILR

In other words, if your company is affected but has not yet completed this step, this should not be postponed until the next infrastructure renewal.

It is the first thing to clarify.

Essential entity or important entity: what is the difference?

NIS2 mainly distinguishes between two categories: essential entities and important entities.

In terms of cybersecurity measures, the requirements are broadly similar. The main difference lies in the way they are supervised.

Essential entities are subject to both ex ante and ex post supervision, while important entities are mainly supervised ex post, for example when there are indications that they may not be complying with their obligations. ILR

For essential entities, the ILR may require regular deliverables including:

• a description of the cybersecurity measures in place;
• an analysis of the main cyber risk scenarios;
• a multi-year action plan;
• and, for certain entities, a list of their dependencies on suppliers or service providers.

The ILR already published templates in August 2026 to help structure these elements. ILR

This gives a good indication of the spirit of NIS2:

it is no longer enough to say that the company is secure. You must be able to demonstrate how risks are identified, managed, monitored and governed.

NIS2 is not just about installing antivirus and enabling MFA

A common mistake would be to turn NIS2 into a technical shopping list:

EDR: done.
MFA: done.
Firewall: done.
Backups: done.

These elements may of course be necessary, but the logic behind NIS2 is broader.

The measures must be based on a risk management approach and cover areas such as governance, incident management, business continuity, supply chain security, access control, cryptography and other organizational and technical measures. ILR

Take a simple example.

A company may have:

• an excellent firewall;
• Microsoft Defender;
• MFA;
• daily backups.

But if nobody knows:

• which systems are actually critical;
• how long the company can operate without them;
• who makes decisions in the event of an incident;
• who must be contacted;
• whether backups have ever actually been restored;
• which suppliers are essential to service continuity;

then the issue is no longer purely technical.

That is precisely the dimension NIS2 is intended to structure.

Management is directly involved

This is probably one of the most important changes compared with the way some companies historically approached cybersecurity.

NIS2 places direct responsibility on management bodies: they must approve cyber risk management measures, oversee their implementation and acquire sufficient understanding of the risks to make the necessary decisions. Eur-Lex

This does not mean that company directors need to become security engineers.

The ILR makes this very clear in its guidance: NIS2 does not require management to become technical experts, but it does require them to be informed, involved and accountable when it comes to cybersecurity. ILR

In practice, management should therefore be able to answer questions such as:

What are our main cyber risks?

Which systems are critical to our operations?

What would be the impact of an outage lasting 4 hours, 24 hours or several days?

Can our backups actually restore the environment?

Which external providers represent a critical dependency?

Which security improvements are still required, and with what priority?

If these answers only exist in the head of the system administrator or IT provider, governance is probably not yet mature enough.

The supply chain is part of the risk

NIS2 does not stop at the company’s own perimeter.

Risks associated with suppliers and service providers are an integral part of the expected approach. The ILR may also require certain essential entities to provide information about dependencies on direct suppliers and service providers. ILR

This can obviously include IT providers, but also potentially:

• cloud providers;
• business application vendors;
• backup providers;
• datacenters;
• telecommunications providers;
• security service providers;
• or any supplier whose failure could block a critical activity.

The question is therefore no longer simply:

“Is my supplier reliable?”

but also:

“What happens to my business if this supplier becomes unavailable?”

That is an important distinction.

In the event of an incident, the deadlines are short

An organization subject to NIS2 must also be able to identify a significant incident and trigger its notification process quickly.

In Luxembourg, the process includes:

→ within 24 hours: an early warning;

→ within 72 hours: a formal notification with updated information;

→ within one month after the notification: a final report, subject to the applicable provisions if the incident is still ongoing. ILR

These deadlines start running while the technical team is usually already trying to understand and contain the incident.

That is not the time to discover:

• who decides whether the incident is significant;
• which authority needs to be contacted;
• who gathers the required information;
• who communicates with customers;
• where the procedure is documented;
• or who has the required access.

An incident response process that only exists on the day of the incident is already too late.

And what about DORA?

For organizations in the financial sector, NIS2 must be distinguished from the DORA Regulation, which has applied since 17 January 2025 to financial entities within its scope. DORA covers, among other things, ICT risk management, incident management, digital operational resilience testing and risks associated with third-party ICT service providers. CSSF

For requirements that it covers in an equivalent way, DORA acts as a sector-specific framework in relation to NIS2. This is intended to avoid imposing duplicate obligations for equivalent risk management or incident reporting requirements. Eur-Lex

For a financial entity, the right question is therefore not:

“Do I have to choose between DORA and NIS2?”

but rather:

“Which obligations fall under DORA, which requirements may still apply under NIS2, and which authority supervises my activities?”

This must be assessed on a case-by-case basis.

Where should you start in practice?

The good news is that a NIS2 initiative does not necessarily need to begin with a complex project.

It starts with having a clear view of the current situation.

1. Confirm the regulatory scope

Sector of activity, company size, group structure and possible exceptions.

The ILR simulator is a good first filter, but complex situations may require legal or regulatory confirmation. NIS2 Simulator

2. Identify critical assets and services

Which systems are genuinely required for the company to operate?

Servers, Microsoft 365, business applications, data, network infrastructure, identities, cloud services, suppliers…

You cannot properly protect what you do not know.

3. Perform a risk assessment

For each relevant scenario:

• what is the likelihood?
• what would the impact be?
• which controls are already in place?
• what residual risk remains?
• is that risk acceptable?

The ILR also makes clear that the supervisory templates it provides do not replace the organization’s own risk assessment. ILR

4. Review the technical fundamentals

For example:

• administrator accounts;
• MFA;
• access control;
• workstation and server protection;
• network segmentation;
• patching;
• backups;
• restore testing;
• encryption;
• monitoring;
• logging.

But always based on the risks that have actually been identified.

5. Review business continuity

A backup is not yet a business continuity plan.

You need to know:

• what must be restored first;
• within what timeframe;
• with which data;
• by which people;
• and with which external dependencies.

And above all: test it.

6. Prepare incident management

Who decides?

Who responds?

Who notifies?

Who communicates?

Which information must be available within the first 24 hours?

These answers must exist before the incident happens.

7. Map critical suppliers

For each important dependency:

• which service does it provide?
• which data does it process?
• is there an alternative?
• what contractual guarantees exist?
• what happens if the provider becomes unavailable?

8. Document and build an action plan

Not every risk will be resolved within a week.

And that is not the objective.

A mature organization should be able to say:

This is where we are today, these are the risks we have identified, these are the ones we have addressed, and this is our plan for the remaining ones.

That is far more credible than a checklist completed once and then forgotten.

NIS2 is above all a risk management approach

Compliance is ultimately only part of the issue.

A company that clearly understands its critical assets, dependencies, risks, backups, procedures and priorities is also better prepared to deal with ransomware, a major outage or the failure of a supplier.

At Mensialis, we therefore approach NIS2 in the same way as our other cybersecurity topics: understand the environment and the risks before recommending tools or technical changes.

An IT and cybersecurity audit can help map the existing environment, identify the main gaps, review the technical fundamentals and turn the findings into a prioritized action plan.

Not sure whether your IT environment is ready for NIS2? Let’s review it together.

An audit can help map the current situation, identify the main gaps and build a prioritized action plan.

This article presents the main operational aspects of NIS2 in Luxembourg and does not constitute legal advice. The determination of scope and interpretation of regulatory obligations must be validated based on each organization’s specific situation.