NIS2 in Belgium
Most boards open with the question of how to become compliant. The more useful first question is whether you are in scope at all, and if so, as which type of entity. That answer determines everything that follows, including where the responsibility lands.
This page explains how the qualification works for a Belgian organization, what changes once you are in scope, and what we recommend you settle first.
In many organizations the NIS2 conversation starts in the IT department, with an inventory of measures. That is the wrong end of the problem. Whether the rules apply to you at all is a legal question about your sector, your size and the service you provide, and it is answered by looking at your activities, not at your infrastructure.
The consequence is practical. An organization that begins implementing before the qualification is settled builds towards a target it has not defined. If the qualification later turns out differently, the work does not simply extend. Parts of it have to be redone, and the board has already been told the programme was on track.
Organizations in scope fall into two classes, and the distinction matters. The security obligations are broadly comparable, but the way compliance is verified and the way the authorities supervise it are not. One class faces active supervision, the other is largely checked after something has gone wrong. The route towards demonstrating conformity differs accordingly.
The timing differs with it. Essential entities work towards a fixed point: their target level has to be reached, and demonstrated, by April 2027. Important entities have no comparable appointment, which is easily mistaken for having no obligation. They carry the same duty of care, and the moment it is examined is the moment something has already gone wrong.
This is also where we see most organizations misjudge their position. Size thresholds and sector descriptions interact, and a company that considers itself too small can still be pulled into scope through the service it delivers to others. We treat the qualification as a piece of reasoning that has to hold up in front of a supervisor, not as a checkbox on a self assessment.
Supply chain security is part of the framework, which means two things at once. Your own suppliers become part of your risk picture and your own security posture becomes part of your clients' risk picture. Organizations that are not themselves in scope increasingly receive questionnaires, contract clauses and evidence requests from clients who are.
In practice that is the fastest growing reason to take this seriously. We regularly see organizations conclude that they fall outside the rules, and then discover that their largest client has effectively brought the requirements into the contract.
The framework puts approval of the security measures and oversight of their implementation with the management body itself, together with an expectation that its members understand enough of the subject to exercise that oversight. Delegating security entirely to IT and moving on is no longer defensible.
For a board this changes the nature of the reporting it should ask for. A status update stating that a programme is running does not demonstrate oversight. What demonstrates oversight is knowing which risks were accepted, on what grounds, and who decided. That is the reporting we build with boards, and it is useful well beyond this framework.
Our recommendation is straightforward. Put the qualification grounds on paper, have the management body formally establish them, and only then decide which measures follow. The document should state which activities were assessed, which grounds apply, which do not and why, and what would change the conclusion.
It is a short piece of work compared to the programme that follows, and it is the piece that makes the rest defensible. It also tells you which conformity route applies to you, which is the point where the Belgian framework becomes concrete and where our page on CyFun and assurance levels picks up.