Analysis · 9 July 2026
The Netherlands has a new cybersecurity law. Here is what it means.
On 7 July 2026 the Eerste Kamer passed the Cyberbeveiligingswet. From 15 August it puts hard duties on roughly 8,000 Dutch organisations, and the EU Cyber Resilience Act adds product rules on top.
Cybersecurity in the Netherlands stopped being a matter of good intentions this month. On 7 July 2026 the Eerste Kamer passed the Cyberbeveiligingswet (Cbw), and it takes effect on 15 August 2026. It is the Dutch version of the European NIS2 directive, and it replaces the older Wet beveiliging netwerk- en informatiesystemen (Wbni). There is no transition period. The day the law starts, the duties start.
If your organisation runs something that matters to Dutch society, or you sell software and connected products into Europe, two things changed at once. This piece walks through what the law actually asks of you, who it covers, and where the AI systems you are shipping fit into all of it.
Two laws on the same day
15 August brings in a pair of laws. The Cyberbeveiligingswet covers digital security and comes from NIS2. Next to it sits the Wet weerbaarheid kritieke entiteiten (Wwke), which comes from the European CER directive and covers physical resilience: keeping critical services running through sabotage, natural disasters and physical attack. The Wwke names roughly 500 critical entities. The Cbw is the broad one, reaching around 8,000 organisations directly, and many thousands more through the supply chain, because organisations in scope have to hold their suppliers to account too.
Who the Cyberbeveiligingswet covers
The law applies to organisations that deliver essential or important services across 18 sectors, including energy, drinking water, digital infrastructure, healthcare, transport, government, banking, waste, food and postal services. It splits them into two groups:
- Essential entities: the larger organisations in the most critical sectors. They get active, up-front supervision.
- Important entities: still in scope, but supervised mostly after something goes wrong.
You will not get a letter telling you that you qualify. The job of working out whether you are in scope, and then registering, sits with you. If you are not sure, the safe move is to check now rather than after 15 August.
What you actually have to do
Three duties sit at the centre of the law.
- Register. Organisations in scope must register in the entity register through the NCSC. Registration opens on 15 August, and it is not optional.
- Duty of care (zorgplicht). You have to run a real risk analysis and then take appropriate and proportionate measures to secure your network and information systems, and to limit the damage when an incident happens. This is the usual ground: access control, patching, backups, logging, supplier risk, and a plan for when things break.
- Reporting duty (meldplicht). A significant incident has to be reported to your CSIRT on a fixed clock: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month.
One part catches a lot of people off guard: the board is on the hook. Directors are ultimately responsible for managing cyber risk, they have to understand it well enough to judge the measures, and they are expected to follow training. This is not something you can hand to IT and forget.
The fines are real
The penalties follow the EU framework. Essential entities can be fined up to 10 million euros or 2% of worldwide annual turnover, whichever is higher. Important entities face up to 7 million euros or 1.4% of turnover. Supervisors can also issue binding instructions, and for essential entities they can suspend management in serious cases. The point of the numbers is to move cybersecurity off the IT budget line and onto the board's desk.
The EU layer: the Cyber Resilience Act
NIS2 is about organisations. The Cyber Resilience Act (CRA) is about products. It sets security requirements for hardware and software with digital elements sold in the EU, from routers to mobile apps to the connected gadget on a shelf. The CRA entered into force in December 2024, and its full requirements apply from December 2027, but one deadline lands sooner: from 11 September 2026, manufacturers have to report actively exploited vulnerabilities and severe incidents. The clock is tight there too, a 24 hour early warning and then a 72 hour notification, filed through a single EU platform that reaches the national CSIRT and ENISA.
So if you build products, you are looking at both regimes at once: NIS2 as an organisation, and the CRA for what you ship.
Where AI fits in
Neither law was written for AI on purpose, and neither leaves it out. If you have bolted an LLM assistant, an AI agent, or any model-driven feature onto a service in scope, that feature is now part of your attack surface, and the duty of care covers it like everything else. An AI feature can leak data, take an action it should not, or be steered by a hostile input, and a regulator will not accept "the model did it" as an answer. It also sits on top of the EU AI Act, which already asks for accuracy, robustness and cybersecurity in Article 15.
The hard part is evidence. The law asks you to take proportionate measures and to be able to show that you did. For a chat interface or an agent with tools, that means testing the thing the way an attacker would, not just running a vulnerability scanner over the servers it happens to run on.
What to do before 15 August
- Work out whether you are an essential or important entity, and get ready to register with the NCSC.
- Run a risk analysis that includes your AI and LLM features, not only the classic IT stack.
- Put an incident reporting process in place that can actually hit the 24 hour and 72 hour marks.
- Brief your board, and make sure they can show they understand the risk.
- If you ship products into the EU, start on CRA vulnerability reporting before 11 September 2026.
The deadlines are close and there is no grace period. The organisations that come out of this well are the ones that treat the duty of care as something to prove, with real testing and real records, rather than something to describe in a policy document.
Sources: Rijksoverheid, NCSC, European Commission (Cyber Resilience Act).
Test this on your own AI before someone else does
Redproof is independent red-teaming for LLM and AI-agent products. We probe your system across the OWASP LLM Top 10, hand you severity-ranked findings with reproductions, fixes, and EU AI Act mapping, and re-test after you patch. That is the evidence your self-assessment needs, before a regulator or customer asks.