The Dutch Cyberbeveiligingswet has been in force since 15 August 2026, and unlike most transpositions of Directive (EU) 2022/2555 in the EU, it arrived without a general transition period. If you are in scope, your obligations are not approaching. They are already overdue.
Netherlands NIS2 Arrived Without a Runway
The asymmetry is the story. In July 2026 the European Commission referred the Netherlands, alongside Ireland, Spain and France, to the Court of Justice for failing to notify full transposition of NIS2. The Senate had adopted the Cyberbeveiligingswet on 7 July, days before that referral landed, and the law entered into force on 15 August 2026. Six weeks from adoption to obligation.
Most compliance calendars are built around a date you work towards. This one has no runway to plan against, which changes what "getting started" means: you are not preparing for a deadline, you are closing a gap that is already open. Clyde & Co's read on the Dutch text confirms there was no general transition period attached to any of the four obligation streams.
Four Cyberbeveiligingswet Obligations That Went Live at Once
Four obligations landed on the same morning, and only one of them is quick. The other three run on entirely different clocks: a quarter of work for the duty of care, a 24-hour clock for reporting, a board cycle for governance. That is why treating 15 August as a single deadline misreads the problem. They are four separate programmes that happened to start on the same day.
The trap is that registration feels like compliance. It is an address record. Nobody has assessed anything about you when you finish it, and the thing that will be assessed is not written into the Act you just registered under.
Where the Cyberbeveiligingswet Hides the Testing Requirement
The Cyberbeveiligingswet is a framework act. The substance of the zorgplicht is delegated downward to the Cyberbeveiligingsbesluit, the general administrative order beneath it, with ministerial regulations adding sector-specific detail below that. If you read the Act looking for what to actually do, you will not find it there. This is the single most common reason Dutch entities conclude, wrongly, that the Cbw asks little of them.
The word doing the work is evaluate. An evaluation has to describe something that was actually run, against named systems, on a known date, by someone identifiable. The mechanics of how Article 21(2)(f) of the directive produces that obligation are covered in our guide to NIS2 penetration testing requirements. The Dutch point is narrower: the evaluation record is what your supervisor reads first, so it is worth being blunt about which artefacts survive that reading and which do not.
- Dated third-party external assessment with named scope and signatory
- Documented findings with reproduction detail
- Retest confirmation showing remediation
- Board minute recording review of results
- A policy document or security framework attestation
- A vulnerability scanner dashboard screenshot
- An undated, unattributed internal spreadsheet
- Statements such as "we use a WAF"
Nothing in that second list is worthless, and a supervisor may well want to see your policies. Those artefacts just answer a different question. Each describes an intention or a tool rather than an evaluation of whether the measure works, which is the thing the decree asks you to record.
How strictly that line gets drawn depends on which supervisor is reading your file, and in the Netherlands that is not one authority.
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →Who Supervises Netherlands NIS2 Compliance
There is no single NIS2 regulator in the Netherlands. Sector determines supervisor, and sector also determines which CSIRT receives your incident report: the NCSC is the national CSIRT, but the Act designates sectoral CSIRTs too, and you file through one portal that routes the report to the right one alongside your supervisor. The practical consequence: your supervisor's inspection style, not the statute, decides what "documented" means in your case. Read their published guidance before you design the evidence file, not after.
Who supervises digital infrastructure, managed service providers and trust services?
Who supervises energy entities under the Cyberbeveiligingswet?
Who supervises transport entities under the Cyberbeveiligingswet?
Who supervises health sector entities under the Cyberbeveiligingswet?
Who supervises banking and financial market infrastructure?
Who supervises public administration entities?
Whichever authority you answer to, they will apply one of two supervision models, and the difference is not the one most people assume.
Essential or Important: Same Duty, Different Enforcement
Both classes owe the same duty of care. The measures do not differ. What differs is supervision and cost of failure. Essential entities face ex ante supervision, so an inspection can arrive without an incident preceding it. Important entities face ex post supervision, which is reactive. Fine ceilings run to €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important ones, whichever is higher.
The reconstruction problem is what turns that into real exposure. Assembling a year of evidence is a two-week job when nothing is on fire and an impossible one during incident response. Financial entities run their testing programme under DORA rather than the Cbw, since DORA is lex specialis, and connected-product makers answer to the Cyber Resilience Act as well, so for some organisations the same evidence has to satisfy more than one reader. All of which argues for building the file on a quiet week.
What to Do in the Next 30 Days
Two of these are fast, four are not, and the ordering matters more than the speed. The sequence below front-loads the cheap items so that the expensive one, evidence, starts its clock on day one rather than day twenty.
One thing that list cannot enforce for you: name individual on-call owners in step three, not a team mailbox. A clock that starts the moment someone in your organisation becomes aware of the incident does not wait for a shared inbox to be opened on Monday morning.
Steps four through six all produce the same deliverable, which is a single file you can hand over. A free external security check is the cheapest way to see what step four will be pointed at, though reconnaissance is not the evidence itself. Here is what the file needs to contain before it is worth filing.
Three of those seven lines depend on someone outside your organisation putting their name to a document, which raises a fair question about what that document can honestly claim.
Where an Independent Signed Report Fits
What the report gives you
An independent, dated, signed external assessment can serve as underlying evidence for a written effectiveness evaluation, for the part of your estate it actually covers. Be precise about what that means. It is one exhibit in the evaluation, not the evaluation itself, and it evidences the systems named in its scope statement and nothing outside them. The evaluation is still yours to write, and it has to speak to the measures you implemented under the decree, most of which no external test touches.
What the report does supply is the set of properties that make an exhibit readable as evidence rather than as an assertion: a named scope, a date, a stated method, and an identifiable assessor who can be asked about it. The decree does not enumerate those four. They are what a supervisor looks for when deciding whether the record in front of them describes something that was genuinely run.
What the report does not give you
The limits deserve equal plainness. It is external-surface testing, not an internal network engagement, so it says nothing about lateral movement once someone is inside, about your identity estate, or about the OT and back-office systems a supervisor may care about most. It covers the classes that reward systematic breadth across everything internet-facing, and not the novel business-logic abuse that still needs a human sitting with your application for a week. It is also not a legal opinion on whether you are an essential or an important entity, and that classification drives your supervision model, so take it to counsel rather than to a testing vendor. There is also a Dutch-specific limit that matters more here than in any other member state.
Where the Keurmerk applies, it generally reaches you through a tender requirement or a sector procurement policy rather than through the duty of care itself, so settle which of the two you are answering to before you shortlist anyone. If it is a tender that names the Keurmerk, engage a certified provider. If it is the zorgplicht, what the evaluation record has to show is a named scope, a date, a method, an identifiable signatory and reproduction detail, and an independent signed report carries those.
Frequently Asked Questions
When did the Dutch Cybersecurity Act (Cyberbeveiligingswet) enter into force?
Is there a grace period or transition period for NIS2 in the Netherlands?
Does the Cyberbeveiligingswet require penetration testing?
Who supervises NIS2 compliance in the Netherlands?
What are the NIS2 fines in the Netherlands for essential and important entities?
How do I register my organisation under the Cyberbeveiligingswet?
What is the difference between the Cyberbeveiligingswet and the Cyberbeveiligingsbesluit?
What evidence does a Dutch supervisor expect for the NIS2 duty of care?
Build the Cbw Evidence File Before You Are Asked for It
The Cyberbeveiligingswet gave you no runway, but it also gave you no prescribed test, no named methodology, and no fixed cadence. What it gave you is an outcome and an expectation that you can show your working. For most entities in scope, the honest gap is not that the wrong test was run. It is that no dated, signed, independent record exists at all, so there is nothing for a written effectiveness evaluation to point at.
That record takes weeks to assemble and minutes to be asked for. Start with the free external check to see what is reachable from outside your network today, then scope the signed work against the systems that actually carry your essential or important service.
Sources
- Directive (EU) 2022/2555 (NIS2), the directive the Cyberbeveiligingswet transposes
- Cyberbeveiligingsbesluit, Staatsblad 2026, 189, the decree carrying the duty-of-care measures and the written effectiveness evaluation
- Rijksinspectie Digitale Infrastructuur: Cbw en Wwke van kracht vanaf augustus
- RDI: sectoren die onder toezicht RDI vallen, the authoritative list of RDI-supervised sectors
- NCSC: doorverwijsboom Cyberbeveiligingswet, the decision tree from sector to supervisor and CSIRT
- European Commission: referral of Ireland, Spain, France and the Netherlands to the Court of Justice
- Clyde & Co: Dutch Cybersecurity Act enters into force on 15 August
- Het CCV: versie 2.0 van het keurmerk Pentesten
- Nationaal Cyber Security Centrum (NCSC), the national CSIRT and the single reporting portal
Last verified: 26 August 2026. Dutch implementation is still moving, particularly the sector-specific ministerial regulations. If something here has changed, tell us and we will correct it and credit the correction.
This post is general information about Dutch cybersecurity regulation and security testing. It is not legal, audit, or compliance advice, and it is not a substitute for the current text of the Cyberbeveiligingswet or the Cyberbeveiligingsbesluit. Confirm your entity classification, your sector supervisor, and your obligations with that supervisor and with qualified legal counsel. Dates and figures describe the position as at the date above.