Loading…
Published
If you run a company in Luxembourg, you have probably heard that "NIS2" is now something you are supposed to deal with. What is usually missing from that sentence is the part that matters most to you: who inside the company actually carries the obligation, and what the first sensible move is.
The short version is that this is not only an IT topic, and it is not something you can fully delegate and forget. Luxembourg has transposed the EU's NIS2 Directive through the Act of 5 May 2026, which entered into force on 10 May 2026. The national regulator, the Institut Luxembourgeois de Régulation (ILR), publishes guidance and a self-registration process for entities that fall under it. So the framework is live, local, and has a named regulator behind it.
This article does three things: it explains what "management body" means for an owner or managing director, what being "in scope" should make you start doing operationally, and where to take the question next. It does not tell you whether your specific company is in scope — that is a determination, not a blog post, and we will be clear about where that line sits.
The most important thing to understand about NIS2 is where it puts accountability. Under Article 20 of the NIS2 Directive, the management body of an entity in scope must approve the cybersecurity risk-management measures, oversee their implementation, and can be held accountable for failures to comply. The same Article expects members of the management body to follow training so they can identify risks and assess cybersecurity practices.
Read that again with your own role in mind. "Management body" is deliberately broad — it points at the people who actually run and govern the company, not at a single technical owner buried in an org chart. For most Luxembourg SMEs, that means the owner, the managing director, or the people who sign off on how the business operates. You can — and should — rely on your IT lead or a partner to do the work. What you cannot do is treat cybersecurity governance as something that happens entirely below your level. Approval and oversight are explicitly the management body's job.
This is usually the moment the topic stops feeling abstract. It is no longer "should IT look at this?" It is "what am I, as the person accountable, expected to have reviewed and approved?"
Let us separate two questions that often get tangled together.
The first is the legal one: is my company in scope at all? That depends on sector, activity, and size criteria set out in the law and in the ILR's guidance. We are not going to paraphrase those criteria here, because getting them slightly wrong helps no one — and the honest answer for most owners is that scope is something to confirm against the ILR's own pages and the Act, not something to guess from a checklist online. If you are unsure, the ILR's NIS2 page and self-registration guidance are the right first reference.
The second question is the operational one, and it is the one you can act on today regardless of how the first resolves: if we are in scope, what should already be in motion? This is where owners get the most value early. Being in scope is not a single switch you flip on a deadline; it is an operating posture you can start building toward. In practice it means you can name who owns cybersecurity risk decisions, you have a defensible record of the measures you have approved, and you can produce evidence of that when a customer, a regulator, or your own board asks.
None of that requires you to have finished anything. It requires you to have , deliberately, with the accountability sitting in the right place — with the management body.
Two things generally have to line up before NIS2 applies to your company: you operate in one of the regulated sectors, and you are at least a medium-sized business — unless you fall into one of a few special categories that are covered whatever your size. Luxembourg follows the EU Directive's sector lists exactly: 18 sectors in total — 11 "high-criticality" sectors and 7 "other critical" sectors.
Read the "not in scope" column as conditional, not permanent. Company size is assessed across linked group companies, so a business that looks small on its own can cross the line; and becoming a sole or essential provider — or being formally designated by the regulator — can pull an otherwise-exempt organisation in. There is no single headcount or revenue figure that decides scope on its own. When it matters, confirm your position against the ILR's published scope guidance and the Act rather than from a table alone.
When owners ask "what do I actually do first?", the most useful answer is to start one operating file with three parts. None of these depends on the scope question being fully closed, and all of them are useful even if you later confirm you are out of scope.
The owner review. Sit down — once, properly — with whoever runs your IT and security and establish what risk-management measures exist today, who decided them, and what you as the management body are being asked to approve. This is the Article 20 expectation made concrete: approval and oversight you can point to.
The customer-evidence pack. Increasingly, the pressure does not arrive from the regulator first — it arrives from a customer's procurement team asking how you manage security. A small, current set of evidence (what you do, who owns it, when it was last reviewed) answers that question without a fire drill every time it is asked.
The regulator-ready file. This is the same material, organized so that if you do register with the ILR and questions follow, you are assembling from a maintained record rather than starting from nothing. The goal is not volume. It is that the management body can show what it approved and why.
Notice that these three are mostly the same underlying material, viewed by three different audiences. That is the point. The work is in keeping one honest record, not in producing three separate binders.
If you get to the end of that owner review and conclude you need help turning it into a maintained operating file, that is the point where Cyvalent is built to help.
Cyvalent works through software and services together. Cyvalent RGX (Risk, Governance & eXecution), our platform, is designed to help organize the operating file: the controls you rely on, the evidence behind them, the risks you have decided to manage, and the readiness follow-up that keeps the record current. Where you need people rather than tooling — to run the owner review, structure the evidence, or stand up governance you can defend — Cyvalent 360 Cyber Services provides expert-led support, and the same team can pair the two so the software and the services reinforce each other.
To be clear about what this is and is not: this is help organizing your operating file and your readiness work. It is not a compliance guarantee, and it does not replace the legal determination of whether NIS2 applies to your company. That determination stays with you, your advisors, and the ILR's guidance. What we can do is make sure that once you know where you stand, the work of staying there is organized, current, and defensible.
That is the difference between scrambling to prove something under deadline pressure and running a security program you can stand behind.
Discuss your NIS2-LU readiness — talk to us about where you stand and what your first operating file should contain.