Back to knowledge base

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

Published on June 12, 2026 · Updated on August 4, 2026

This article is general information about laws and regulations, not legal advice.

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: 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, 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 has applied at EU level since 17 October 2024; the Dutch Cybersecurity Act (Cyberbeveiligingswet, Cbw) takes effect on 15 August 2026, without a transition period. Both treat cybersecurity 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.

Does your public organisation fall under the Cbw?

Not every public organisation automatically falls under the same obligations. The Cbw distinguishes essential and important entities. For essential entities, supervision is in principle proactive: the regulator can inspect even without a specific trigger. For important entities, supervision is mainly reactive: it typically comes into play after an incident or signal. Which category you fall into partly determines how heavily supervision weighs.

Which layers of government are concretely in scope varies. Central government, provinces, municipalities and water authorities can fall under the Cbw, but this does not happen automatically for every organisation: whether and how the act applies depends on sector, task and size. A small implementing body may remain outside the scope where a large grid operator or drinking-water company falls squarely within it. So test your applicability with the competent authority or the NCSC before making assumptions about your obligations.

If your organisation does fall under it, that comes with a concrete registration obligation. Entities covered by the Cbw must register in the entity register via the NCSC (mijn.ncsc.nl), providing among other things contact details, sector and a description of the service delivered. That registration applies from the moment the act takes effect on 15 August 2026 and sits alongside the duty of care and the reporting duty covered in the steps below.

Five steps to a board-level cyber routine

These five steps put the board-level basics in order; they do not amount to full NIS2 compliance. Article 21 of the directive sets out around ten measures (from encryption, access control and back-ups to supply-chain security) that fall partly outside this scope. The precise way each step is implemented also depends on your scope and size; read the imperatives below as direction.

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 often 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 requirement has a substantive reason: 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 or the person responsible for information security. Many smaller municipalities and water authorities have no CISO of their own; that role may then sit with a regional partnership, an information-security officer or an external party. In that case, explicitly record who the board's counterpart is. The Dutch NCSC publishes concrete questions that directors can ask that person, a useful starting point for the 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, a more detailed incident report within 72 hours and a final report within one month. 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, 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 decentralised government aligns as much as possible with existing accountability structures such as ENSIA. ENSIA is an administrative accountability instrument: questionnaires and self-assessments with which you demonstrate on paper that policy and measures exist. That remains necessary, but it does not measure whether those measures also hold up technically. An external measurement of your attack surface complements ENSIA in exactly that: with current data it shows what is externally visible and reachable and whether remediation has really been carried out. The two are complementary: paper alongside measurement. And 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 externally visible and reachable.
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. 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 lays the board-level foundation and can back the core question of every regulator (can you demonstrate it?) with evidence. Full NIS2 compliance takes more (Article 21 sets out further measures such as encryption, access control, back-ups and supply-chain security), but without this board-level routine the rest never gets off the ground.

Exposentry supports steps 1 and 3 with evidence-driven monitoring of the external attack surface: continuous, dated and traceable. The platform builds on OpenKAT, the open-source security scanner of the Dutch government, to which founder Edward Hasekamp contributes as a collaborator. 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 opleidingsplicht 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 collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.