Back to knowledge base

The NIS2 roadmap for public-sector boards: from duty of care to demonstrable compliance

Published on June 12, 2026

Please note: this article is intended as general knowledge-base information and is not legal advice.

Introduction

In our article on NIS2 and joint and several liability we explained that public-sector directors need not fear automatic personal liability — but they do have to give demonstrable substance to their governance duty of care. The logical follow-up question is: how, exactly?

This roadmap provides the answer. No abstract policy language, but five concrete steps that take a municipality, province, water authority or central-government organisation from a paper duty of care to demonstrable compliance. The common thread: every step produces evidence. Not because the regulator will be on your doorstep tomorrow, but because a board that cannot substantiate its choices is administratively vulnerable — during an incident, during an audit and in political accountability.

Why the duty of care demands a culture change

The NIS2 directive and the Dutch Cybersecurity Act (Cyberbeveiligingswet) do not treat cybersecurity as an IT file, but as a board-level responsibility. The Dutch National Coordinator for Security and Counterterrorism (NCTV) puts it sharply: the board is responsible for policy and compliance, must have demonstrable knowledge of cyber risks and cannot delegate that ultimate responsibility to the CISO.

For many public organisations that means a culture change. Cybersecurity shifts from "a paragraph in the planning-and-control cycle" to a standing item at the board table, with the same discipline as finance: an up-to-date picture, periodic reporting, explicit decisions and a verifiable trail. The good news: public bodies do not have to start from scratch. Existing structures such as BIO and ENSIA form a foundation that NIS2 compliance can build on — the Dutch government indicates that supervision will align with existing accountability information as much as possible.

Five steps to a NIS2-proof public-sector board

Step 1: Determine the criticality and scope of your assets

You cannot oversee what you do not know. The first step is therefore a current and complete picture of the digital assets: domains, subdomains, systems, connections to national facilities, supplier portals and cloud environments. Determine the criticality per asset: which systems affect essential services, sensitive data or chain partners?

In practice the formal asset register almost always turns out to be incomplete. Test environments, forgotten subdomains and shadow IT are not in it — yet they are just as visible to an attacker as the main systems. So start from the outside in: first map what an attacker sees of your domain and lay that next to the internal register. The difference between those two lists is your first board-level finding.

Evidence for this step: a dated asset overview, criticality classification and an established process to keep the picture current.

Step 2: Set up the mandatory cybersecurity training for the board

NIS2 requires directors to build the knowledge and skills to assess cyber risks and control measures. That is not a formality: a board that cannot ask the right questions cannot fulfil its oversight role.

Practical implementation: an annual board training, supplemented with periodic threat updates and a fixed quarterly conversation with the CISO. The Dutch NCSC publishes concrete questions that directors can ask their CISO — a useful starting point for that conversation.

Evidence for this step: training certificates, agendas and minutes of CISO conversations, and demonstrable follow-up of action items.

Step 3: Implement continuous monitoring instead of ad-hoc audits

An annual audit or pentest gives a snapshot; cyber risk changes daily. New vulnerabilities are published, suppliers change configurations and colleagues put new services online. The Dutch Authority for Digital Infrastructure (RDI) emphasises that risk management under the Cybersecurity Act is a continuous cycle: identify, analyse, evaluate and control.

Continuous monitoring of the external attack surface makes that cycle concrete. Every new finding gets an owner, a priority and a remediation deadline — and every remediation is re-checked. This automatically builds the file that step 5 needs. Why a single scan is not enough for this, you can read in scanning is not NIS2 compliance.

Evidence for this step: continuous scan reports with date and finding, remediation SLAs and re-checks.

Step 4: Formally establish incident response protocols

NIS2 sets tight reporting deadlines for significant incidents: an early warning within 24 hours and an incident notification within 72 hours. You only meet those deadlines with a protocol that has been established and rehearsed in advance: who decides, who reports, who communicates, and where is the contact information of the regulator and the CSIRT?

Establish the protocol at board level and rehearse it at least annually, including the board's role. An incident at three in the morning is not the moment to discover that the escalation line is unclear.

Evidence for this step: an established incident response plan, exercise reports and a tested notification procedure.

Step 5: Set up the internal audit trail for the regulator

The last step ties everything together: ensure that every decision, every finding and every remediation action is recorded traceably. Not as bureaucratic ballast, but as a continuous by-product of steps 1 through 4. Whoever builds the audit trail only when the regulator asks for it has to reconstruct; whoever builds it during the process only has to show it.

How do you prepare for the formal NIS2 audit?

Supervision of public organisations aligns as much as possible with existing accountability structures such as ENSIA. But the underlying question of every audit remains the same: can you demonstrate that you know your risks, have chosen appropriate measures and verify follow-up?

Three actions you can start with today:

1. Expose the gap between your asset register and reality. An external scan of your domains shows within days what is actually online.
2. Put cybersecurity on the agenda as a standing board item, with a quarterly report in a fixed format: attack surface, critical findings, remediation status, risk acceptance, supply-chain risks.
3. Start with the file, not with the policy document. A folder of dated reports, decisions and re-checks is worth more in an audit than a policy document without evidence of execution.

Conclusion

NIS2 compliance for public-sector boards is not a legal sprint but an administrative routine: know your assets, train the board, monitor continuously, rehearse the response and build the evidence as you work. Whoever follows these five steps answers the core question of every regulator — can you demonstrate it? — with a simple: yes.

Exposentry supports steps 1 and 3 with evidence-first monitoring of the external attack surface: continuous, dated and traceable. See the plans and pricing or start with a first scan to make the gap between your register and reality visible.

Sources

1. NCTV, "Bestuurlijke verantwoordelijkheid en trainingsplicht voor bestuurders" — nctv.nl
2. Digitale Overheid, "Veelgestelde vragen Cyberbeveiligingswet" — digitaleoverheid.nl
3. Rijksinspectie Digitale Infrastructuur, "Risicomanagement en cyberbeveiliging" — rdi.nl
4. NCSC, "Vragen die je als bestuurder kunt stellen aan de CISO" — ncsc.nl
5. EUR-Lex, Directive (EU) 2022/2555, Articles 20, 21 & 23 — eur-lex.europa.eu

Written by Edward Hasekamp, founder of Exposentry and core maintainer of the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides NL-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.