NIS2 for mid-market Dutch companies: what to actually do in the first 90 days

Most mid-market companies I talk to about NIS2 have roughly the same reaction when they realise they’re in scope: some mixture of irritation, anxiety, and a quiet hope that if they say nothing, no one will notice. That is a reasonable human response and a terrible compliance strategy. The Dutch implementation, the Cyberbeveiligingswet, came into force with real enforcement powers, and the supervisory authorities have been explicit that they intend to use them.

The good news is that for a competently-run mid-market business, the first ninety days of NIS2 work is unglamorous, mostly free, and roughly the same regardless of sector. This post is the sequence I walk clients through. It is not legal advice; it is what I do.

Week 1-2: Confirm scope, then breathe

Before spending any money, pin down two things.

First, are you actually in scope? NIS2 applies to “essential” and “important” entities across eighteen sectors, with size thresholds. A lot of companies assume they are in scope based on a vendor’s email, when in fact their turnover, headcount, or sector exclusion keeps them out. Read Annex I and Annex II of the directive, then read the Dutch Cyberbeveiligingswet’s scope articles, and get a written view from your legal advisor if there is any ambiguity. Wrong-scope work is a very expensive waste.

Second, register. If you are in scope, Dutch implementation requires registration with the relevant sector authority (RDI for the digital infrastructure sector, NCTV for some essential entities, sector regulators for the rest). This is administrative, takes an afternoon, and you want it out of the way before you start thinking about controls.

Week 3-4: One person, in writing

Appoint a named individual responsible for NIS2 compliance. They do not need to be a security expert, and for most mid-market businesses they will not be. They need authority to spend money and to make the rest of the business do things. In practice this is often the CFO, sometimes the COO, occasionally the IT manager if they have the ear of the board. Document it, in a short memo, signed by the board. This single artefact, a named person with board backing, is evidence of governance that matters more than most of the controls you will put in later.

At the same time, set up the incident-reporting machinery. NIS2 requires a 24-hour early-warning notification for significant incidents, a 72-hour full incident report, and a 1-month final report. None of those timelines are achievable if nobody knows who to call at 11pm on a Sunday. Write a one-page incident procedure that answers three questions: what counts as significant, who decides, and who makes the call. Test it once.

Week 5-8: Find the fires

This is the part that feels like “real” security work, and it is the part where I most often see companies over-invest. The temptation is to buy something, a new EDR, a pentest, a SIEM, because it is easier than looking hard at what you already have.

Resist that. Instead, do a gap assessment against NIS2 article 21’s ten measures. You do not need a framework. You need:

• A list of all your systems, ranked by how much damage their compromise or unavailability would cause.
• For each of the top ten systems, honest answers to three questions: who has admin, how would we know if it were compromised, and could we restore it from backup this week.
• A list of your top ten suppliers, and whether any of them have the ability to ruin your week if they get compromised.

Nine times out of ten, that exercise surfaces the same three things: MFA is not universal, backup restore has never been tested, and there is a supplier somewhere with domain-admin-equivalent access that nobody remembers authorising. Those are your first month of remediation, and they are almost never a licensing problem. They are a “spend a week doing the unglamorous work” problem.

Week 9-12: Write the minimum viable ISMS

Do not buy an ISMS tool yet. You do not need one. In the first ninety days, what you need is a short set of documents that demonstrate governance:

• An information-security policy (two pages is fine).
• A risk register (a spreadsheet of the top fifteen risks is fine).
• An incident-response procedure (the one-pager from week 3-4).
• A supplier-security register (a spreadsheet: supplier, data they access, last security review date).
• A simple log of board-level reviews of the above (a calendar entry plus minutes is fine).

That is it. The point of these documents, in the first ninety days, is not to make you actually secure. It is to demonstrate to a supervisor that you have taken NIS2 seriously and have begun the work. Substance can follow; evidence of intent must come first.

After day 90

At this point you should have: a named responsible individual, an incident procedure that has been tested once, three or four remediated findings from your gap assessment, and a skeleton ISMS. That is enough to have a credible conversation with a regulator if one calls. It is not enough to call yourself compliant, but compliance is a direction of travel under NIS2, not a date on a calendar.

From month four onwards, the work gets longer and more specialised: detection capability, supply-chain assurance, OT-specific controls if relevant, tabletop exercises, third-party assessments. None of those are cheap, and none of them are worth doing before the basics above.

The organisations I see struggling with NIS2 are not the ones who started late. They are the ones who started by buying things. The first ninety days are overwhelmingly about people, process, and writing things down.

---

If you’d rather not do this alone, the three-week NIS2 readiness engagement covers the whole of the above: scope confirmation, gap map, twelve-month roadmap, and an explicit hand-off so your team can run the work themselves. Get in touch if it sounds useful.