Back to knowledge base

NIS2 compliance checklist: demonstrable compliance in 2026

Published on August 22, 2026

Does your organisation fall under the Dutch Cybersecurity Act (Cyberbeveiligingswet, Cbw)? Then only one thing counts in an inspection: can you demonstrate what you have put in place. The act entered into force on 15 August 2026, without a general transition period, and applies to essential and important entities. This checklist goes through the obligations in the order in which you tackle them: scope, the ten areas of measures, the reporting obligation and the evidence file that stands up to an audit.

The act article by article, with the ten elements of Article 21 next to the evidence that belongs to each, is on the Dutch Cybersecurity Act page.

Do I fall under the Dutch Cybersecurity Act?

The Cbw applies to organisations in the designated sectors that exceed the thresholds for number of employees or for turnover and balance sheet total. Even an organisation that falls outside the act itself can, as a critical supplier to an essential entity, have comparable requirements imposed on it through contracts.

  1. Check whether your sector is listed in the annexes of the NIS2 directive.
  2. Test your number of employees and turnover against the thresholds for an essential or important entity, for example with the NIS2 self-assessment (NIS2-Zelfevaluatie) of the Dutch Authority for Digital Infrastructure (Rijksinspectie Digitale Infrastructuur, RDI). Our self-check goes through the same questions.
  3. Register your organisation in the entity register via MijnNCSC (the NCSC's online portal).
  4. Determine whether you are in scope directly or indirectly, through supply-chain requirements from a customer. Being indirectly in scope means in practice: providing evidence to your customer, often with the same kind of documentation.

Supervision, fines and the role of the board

Supervision is organised by sector. The RDI supervises nine sectors, including digital infrastructure, energy and government; other sectors have their own supervisor, such as De Nederlandsche Bank (DNB) for the financial sector. Essential entities are subject to proactive supervision: the supervisor can carry out audits and inspections even without a specific reason. Important entities are assessed reactively, after signals or incidents. The obligations are the same for both classes; the difference lies in how likely it is that you will have to be able to show the evidence unprompted.

The sanctions are substantial: an administrative fine can reach €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities. In addition, the supervisor can issue binding instructions and, for essential entities, as a last resort temporarily suspend directors.

The board is personally accountable in this. The act requires directors to approve the measures, to oversee their implementation and to complete training on cyber risks themselves (a period of no more than two years after entry into force applies to this). A policy document without board approval and without evidence of training for the board itself is therefore weak in an inspection.

The five-phase checklist: from baseline to continuous compliance

A NIS2 programme works best as a project-based sequence with a clear result per phase.

  1. Scope and registration. Determine the entity class and register in the entity register via MijnNCSC. Result: a scope document with rationale and date.
  2. Baseline and risk analysis. Inventory assets, processes and threats. Result: a risk register with an owner per risk.
  3. Gap analysis and prioritisation. Compare the current situation with the ten areas of measures in Article 21 of the NIS2 directive. Result: an action plan with responsible people.
  4. Implementation. Introduce policy, procedures and technical measures. Result: signed policy, procedure documents and evidence of technical configuration.
  5. Monitoring and continuous improvement. Keep compliance up to date with internal audits and management reviews. Result: an up-to-date evidence file and records of board review.

If you already have an ISMS based on ISO 27001, a large part of phases three and four is already in place. The Cbw requirements around reporting deadlines, board responsibility and supply-chain care do call for additional evidence that a generic ISMS does not automatically provide. The Cbw (NIS2) Control Framework of the Dutch Central Government Audit Service (Auditdienst Rijk) and NOREA offers a recognisable structure for this; the NLdigital roadmap (in Dutch) combines those building blocks with NCSC and ENISA guidance.

The ten areas of measures: paper evidence and external measurement

Article 21 of the NIS2 directive lists ten areas of measures. Each area calls for two kinds of evidence: the document that shows you have put it in place, and where possible a measurement that shows it also works on the outside. If you can show both, you are in a considerably stronger position with an auditor.

Area of measures (Art. 21(2))Paper evidenceExternally measurable signal
a. Risk analysis and security policySigned policy, risk registern/a
b. Incident handlingReporting procedure, exercise reportsPresence and validity of security.txt
c. Business continuity and backupsRecovery test with documented recovery timen/a
d. Supply-chain securitySupplier assessments, contract requirementsThe supplier's scan report
e. Secure development and procurementRequirements in procurement and development processesOutdated software visible from the outside
f. Effectiveness assessmentInternal audits, management reviewRepeated external scan shows a trend
g. Cyber hygiene and trainingTraining register, including for the boardEmail security (SPF, DKIM, DMARC) publicly testable
h. CryptographyEncryption policyTLS configuration and certificates publicly testable
i. Personnel, access and assetsAccess reviews, joiner and leaver processExposed admin interfaces
j. MFA and secure communicationEvidence of MFA rolloutExposed login screens on publicly reachable services

In practice the right-hand column regularly stays empty: the policy says everything is patched, while an external scan finds a forgotten subdomain with an expired certificate and an open admin interface. Filling both columns is what demonstrating means.

The reporting obligation: 24 hours, 72 hours, one month

You report a significant incident (a serious operational disruption or considerable damage, for your own organisation or for others) via the central reporting portal on MijnNCSC to the CSIRT and your supervisor, in three steps: an early warning within 24 hours, a full incident notification within 72 hours and a final report within one month of the incident notification. The clock starts as soon as you know the incident is significant. Include these deadlines in the reporting procedure, appoint someone responsible and rehearse the scenario at least once a year: a missed 24-hour deadline is formally a shortcoming even in an otherwise well-handled incident.

The evidence file: what does a supervisor want to see?

There is no fixed, published list. A useful rule of thumb from audit practice: one piece of evidence per measure, with a date, an owner and an approval. Think of signed policy with a version date, an up-to-date risk register, patch logs, recovery tests with their results and training registers. Make sure timestamps cannot be changed afterwards: an auditor who doubts the authenticity of a log puts the entire body of evidence under pressure. Forensically substantiated evidence for auditors and insurers explains how to arrange that traceability in practice.

Supply-chain duty of care: managing and proving supplier risk

Your own security can be in order while a supplier with access to your systems is the weakest point. The supply-chain duty of care obliges you to make those risks manageable and demonstrable. Classify suppliers by criticality, set out reporting deadlines and the right to verification in contracts, and reassess critical suppliers on a fixed cycle. A questionnaire that a supplier fills in itself is at most the starting point; an independent, repeated measurement of external exposure is stronger evidence, precisely because the supplier does not fill it in itself.

Where do you start with limited time?

Start with the measures that remove the most risk for the least effort: multi-factor authentication on administrator accounts and critical applications, clearing outstanding critical patches with a fixed SLA per risk class for what follows, a tested and documented backup recovery procedure, and cleaning up unnecessary accounts and permissions. Structured vulnerability management turns that patch discipline into an ongoing process. Scope and gap analysis can be done in weeks; allow months for implementation, depending on size and starting position.

What most checklists skip

The emphasis is often on technology: MFA, patching, logging. The supervisor explicitly also assesses the governance side, because that is where the act places responsibility. And the largest exposure regularly sits with a supplier that is rarely checked independently. So start with evidence: document what you already do, fill the gaps along the ten areas of measures, and give every document a date, an owner and an approval. The rest is execution.

Where Exposentry fits in this programme

Exposentry fills a large part of the right-hand column of the table of measures: continuous monitoring of your external attack surface, with monthly reporting on subdomains, exposed services and vulnerabilities. The scans run on OpenKAT, the open-source scanner developed within the Dutch government; Exposentry is built on it and founder Edward Hasekamp contributes to OpenKAT. Reports are cryptographically signed with an independent timestamp, so anyone can verify that they are authentic and unaltered: usable evidence towards supervisors, auditors and customers. A free security scan shows what an attacker can see of your domain; for ongoing evidence in your file there is the vulnerability scan.

Sources

Further reading

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.