NIS2 and municipalities: what does the regulator expect from you?

The headline first

The NIS2 directive is a European law that obliges member states to make "essential" and "important" entities cyber-resilient. In the Netherlands, the directive has been transposed into the Cybersecurity Act (Cyberbeveiligingswet). Municipalities are designated as essential entities — the heaviest regime. This has three direct consequences:

• Demonstrable technical and organisational measures must be in place and periodically verified.
• Significant incidents must be reported within 24 hours to the CSIRT (in the Netherlands: the NCSC).
• Executives face personal liability for negligence — fines can run to €10m or 2% of turnover (for municipalities: the equivalent amount in the budget).

The four pillars of NIS2 compliance

The law names four substantive requirements a municipality must meet. In practice these are the areas the RDI will ask about in an inspection.

What the RDI expects in practice

The legal text is deliberately principle-based — it doesn't say "you must do an annual pentest." But from the first enforcement actions and signals from the RDI, a fairly clear picture emerges of what a municipality must be able to provide.

1. A current, documented risk analysis

Not a year-old policy document, but a living document addressing concrete threats (ransomware, supply chain, DDoS, targeted spear-phishing at leadership), related assets and corresponding measures. The BIO (Baseline Information Security Government) is the common framework — NIS2 explicitly expects you to periodically reassess this.

2. Evidence that technical measures work

Not just policy. Evidence. This is where many municipalities now have a gap. A security policy in a document is not enough — the RDI expects demonstrable verification. Concretely:

• A recent independent pentest report on critical applications (citizen portal, chain connections, internal applications)
• A retest declaration showing that findings have actually been resolved
• Logging and monitoring with demonstrable detection events
• Recent backup restore tests — not just backups, but working restores

3. A working alert chain

Not on paper. Working. That means: who gets called at 3am? Who makes the notification to NCSC? Who communicates to the board, cabinet and press? A tabletop exercise in which this chain is tested once a year appears as positive evidence in an inspection.

4. Supplier agreements that aren't just on paper

NIS2 makes municipalities responsible for their suppliers. Concretely: SaaS providers, hosting parties, application suppliers. The RDI asks in an inspection whether you have contractually obligated your suppliers to adequate security, whether you periodically request their pentest reports or audits, and what you do when these are absent.

5. Personal involvement of the board

This is new and essential under NIS2. An alderman or municipal secretary who claims "no knowledge of IT" is not protected from liability. The law requires that the board is periodically informed, has received training and takes strategic decisions about cyber risks. A log of board discussions on cybersecurity is a sensible artefact to maintain.

What NIS2 doesn't say — and what that means

The law nowhere literally says "penetration test." That's not a free pass — on the contrary: it means you must demonstrably show that your chosen verification method is appropriate. And in municipal practice that comes down 9 times out of 10 to a combination of:

• ENSIA self-assessment (mandatory, annual) — for the procedural side
• BIO audit — for the setup of technical measures
• Penetration test — for objective evidence that those measures technically work

These instruments partially overlap, but none replaces the others. A municipality that only fills in ENSIA lacks evidence of technical verification. A municipality that only does a pentest lacks the governance side. The complete picture is what the RDI wants to see in an inspection.

A realistic timeline

If you start now — without panic, but without delay — this is a workable plan:

• Month 1: Reassess risk analysis, map to BIO. Identify 5 most critical systems.
• Month 2: Plan pentest for 1–2 critical systems (citizen portal and core internal application are common choices). Start supplier inventory.
• Month 3: Execute pentest and remediation. Practise alert chain tabletop. Formally brief the board.
• Month 4: Retest. Review supplier contracts for cybersecurity clauses. Set up log.
• Month 5–6: Complete ENSIA with this evidence. Reflection and planning for next year.

The role of a pentest within NIS2

An independent penetration test within the NIS2 framework is not an end in itself, but the strongest evidence instrument for pillar 2 (technical measures). The report shows:

• Which vulnerabilities actually existed at the time of testing
• Which were exploitable — not just theoretically
• Which have been patched (retest)
• Which measures demonstrably work

At Resync, the report is deliberately structured to be directly usable in ENSIA, BIO audit and towards the RDI. Not a loose PDF — structured evidence with executive summary, technical findings and retest declaration. See our municipality penetration testing page for details.

Conclusion

NIS2 is not a tick-box exercise. It's a change in how the Netherlands evaluates the cyber-resilience of public entities — with executive liability as the final safeguard. For a municipality that means: ensure you can show that measures demonstrably work, that the board is involved, and that the alert chain has been practised.

Waiting until the RDI appears at your door is the most expensive option. Scheduling a pentest — as part of a broader NIS2 programme — is one of the most concrete first steps.