If your company runs in Belgium and the Netherlands, you are currently living under two different versions of the same law. That is not a paradox, it is the practical reality of NIS2 in 2026, and it has direct consequences for the software you already run.
Most NIS2 coverage explains the directive. Far less of it explains what the obligations mean for systems that were built years before anyone had heard of NIS2: the ERP that has no meaningful logging, the integration nobody documented, the server whose patch cycle is “when something breaks”. That gap is where compliance quietly turns into an engineering problem.
Where things actually stand
Belgium moved early and is already enforcing. The Belgian NIS2 law and its Royal Decree entered into force on 18 October 2024, making Belgium one of only four Member States to meet the original deadline. The Centre for Cybersecurity Belgium (CCB) acts as both national cybersecurity authority and CSIRT. In-scope entities had to register through the Safeonweb@Work portal by 18 March 2025, and by late 2025 roughly 1,500 essential and 2,500 important entities had done so. On 18 April 2026 Belgium passed its first conformity assessment deadline: essential entities had to submit verified documentation showing that cybersecurity controls are actually in place, assessed by an accredited body or by the CCB. Self-declarations were not accepted.
The Netherlands is still catching up. The Dutch transposition, the Cyberbeveiligingswet (Cbw), replaces the older Wbni. It passed the House of Representatives on 15 April 2026, with entry into force expected during 2026. In the meantime the European Commission referred the Netherlands to the Court of Justice on 8 July 2026 for failing to notify full transposition. NCSC-NL is already publishing guidance and operational expectations.
For a company operating in both countries, the message is uncomfortable but clear: in Belgium you are late if you have not acted, and in the Netherlands the transposition gap is preparation time, not a reprieve. Surveys through 2026 have repeatedly found that a large majority of in-scope organisations describe themselves as not ready.
What NIS2 actually asks for
Strip away the legal language and NIS2 comes down to two things: a set of duty-of-care measures you must have in place, and a reporting obligation when something goes wrong.
The duty-of-care measures cover risk analysis, incident handling, business continuity, supply chain security, security in acquisition and development, access control, multi-factor authentication, cryptography, vulnerability handling and staff awareness.
The reporting timetable is where NIS2 becomes concrete. For a significant incident, the sequence is an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month.
Read that timetable again with your oldest system in mind. Twenty-four hours is not a lot of time to notice, confirm and characterise an incident. It is essentially no time at all if the system in question cannot tell you what happened inside it.
Why legacy systems struggle with this
Here is the part that lands on engineering teams rather than on legal.
You cannot report what you cannot detect
The 24-hour clock assumes you will notice. Many older systems log almost nothing useful: no structured audit trail, no centralised collection, no alerting on anomalies. When something suspicious happens, the honest answer is often that nobody would know for weeks.
Retrofitting logging and monitoring into a running production system is unglamorous, careful work. It is also the single most valuable thing most companies can do for NIS2 readiness, because it turns an unanswerable question into an answerable one.
Duty of care assumes an inventory you may not have
Risk analysis, vulnerability handling and access control all presuppose that you know what you are running. In practice, many mid-size companies cannot produce a complete list of their systems, dependencies, integrations and who has access to what. Shadow integrations built years ago for a specific need are a recurring example.
The first NIS2 task for most companies is therefore not writing a policy. It is mapping reality.
Vulnerability handling requires a patch path that works
A duty to handle vulnerabilities implies you can actually apply fixes. Systems running end-of-life frameworks, unsupported runtimes or dependencies frozen years ago often cannot be patched without a modernisation step first. That is a maintenance programme, not a policy decision, and it needs lead time.
Supply chain security cascades to your suppliers, and to you
This is the clause that quietly widens NIS2 far beyond the entities formally in scope. In-scope organisations must manage security in their supplier relationships. So if your customer is an essential or important entity, their obligations arrive at your door as contractual requirements, questionnaires and evidence requests, whether or not NIS2 applies to you directly.
Many companies discover they are affected not through a regulator, but through a customer’s procurement form.
Documentation is now evidence
Belgium’s April 2026 deadline made this explicit: verified documentation, assessed externally, not a self-declaration. Documentation stops being internal hygiene and becomes the artefact that demonstrates compliance. Systems whose knowledge lives in one person’s head cannot produce that.
What this means practically
NIS2 readiness for a company with older systems tends to follow a predictable sequence:
- Map what you run. Systems, versions, dependencies, integrations, data flows, access. This is the foundation for everything else.
- Fix detection first. Logging, centralised collection and alerting, so the 24-hour clock is survivable.
- Establish a patch path. Identify what cannot currently be patched and plan the modernisation those systems need.
- Tighten access. Access control and multi-factor authentication, including on the old internal tools everyone forgets.
- Write it down. Architecture, runbooks, incident procedures, in a form an external assessor can read.
- Rehearse the reporting path. Know who notifies the CCB or NCSC-NL, with what information, within which deadline.
None of these steps is exotic. All of them are maintenance work on systems that cannot go down while the work happens.
How Dink can help
This is the work we already do, applied to a compliance deadline.
Our fixed-scope technology assessment produces exactly the map NIS2 assumes you have: what runs where, on what versions, integrated with what, with which single points of failure and which gaps in monitoring and recovery readiness.
Adding logging, closing vulnerabilities and modernising components that can no longer be patched are changes to live systems. Staged rollouts, reversible changes and testing are how we work on critical systems already, because the alternative, taking the system down, is not available.
And documenting what only lives in people’s heads is standard practice when we take over a system. Under NIS2 that documentation is no longer just useful internally, it is evidence.
If you are not sure whether NIS2 applies to you, or you know it does and you are looking at systems that were never designed for it, that is a good first conversation to have.
Frequently asked questions
Does NIS2 apply to mid-size companies?
Often yes. NIS2 generally covers medium and large organisations, from 50 employees or 10 million euro turnover, across 18 sectors. Certain entity types are in scope regardless of size, and Member States can designate additional entities. Even outside direct scope, the supply chain security obligations of your customers can reach you contractually.
What is the difference between Belgium and the Netherlands right now?
Belgium transposed NIS2 with effect from 18 October 2024, required registration with the CCB by 18 March 2025, and set its first conformity assessment deadline for essential entities on 18 April 2026, requiring externally verified documentation. The Netherlands is transposing through the Cyberbeveiligingswet, which passed the House of Representatives on 15 April 2026 with entry into force expected during 2026. Companies operating in both countries face different timelines for the same directive.
How quickly do we have to report an incident under NIS2?
For a significant incident: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. Meeting the first deadline depends on detection, which is where older systems usually fall short.
Our systems are old. Where do we start?
Start by mapping what you actually run, then fix detection through logging and monitoring. Those two steps unlock everything else: you cannot do risk analysis, vulnerability handling or incident reporting without knowing what exists and being able to see what it is doing.
Are we affected if our customers are in scope but we are not?
Frequently, yes. In-scope entities must manage supply chain security, so their obligations pass to suppliers through contracts, security questionnaires and evidence requirements. Many companies first encounter NIS2 through a customer’s procurement process rather than through a regulator.
This is practical guidance from an engineering perspective, not legal advice. For scoping and classification decisions, involve your legal counsel or your national authority.
Wondering whether your systems could meet a 24-hour reporting deadline? Start with a fixed-scope technology assessment, or get in touch.