Legislation · 12 Sep 2024 · Rob Nidschelm

NIS2 Becomes Dutch Law: What Changes on 15 August 2026

The Netherlands is about to move from preparing for NIS2 to enforcing it. On 15 August 2026, the Cyberbeveiligingswet enters into force and introduces new cybersecurity obligations for more than 8,000 Dutch organisations.

The European NIS2 Directive was never intended to be a voluntary security framework. It is legislation designed to raise the level of cyber resilience across services that society and the economy depend on.

For Dutch organisations, the practical turning point is the Cyberbeveiligingswet, or Cbw. The law implements NIS2 in the Netherlands and replaces the existing Wet beveiliging netwerk- en informatiesystemen. It applies across eighteen sectors and brings a much larger group of organisations into scope.

The date matters, but the more important change is one of accountability. Cybersecurity is no longer something that can be delegated to an IT department and reviewed once a year. Organisations must understand their exposure, take proportionate measures, report serious incidents and be able to demonstrate that management is engaged.

Why NIS2 is broader than its predecessor

NIS1 focused on a smaller group of operators of essential services and certain digital service providers. NIS2 expands the scope to reflect how interconnected essential services have become.

Energy, transport, healthcare, finance, drinking water and digital infrastructure remain central, but the framework also reaches sectors such as public administration, managed ICT services, waste and wastewater, postal and courier services, food, critical manufacturing, research and space.

The logic is straightforward. A hospital can be disrupted by a compromised software supplier. A water company can depend on remote maintenance. A public body can rely on a managed service provider. A manufacturer may produce components that are essential to another critical sector.

The resilience of the service is therefore partly determined by organisations outside its traditional perimeter.

The Dutch law creates four immediate duties

The exact application of the law depends on sector, size and other criteria, so organisations should use the official Dutch self-assessment and obtain legal advice where necessary. At an operational level, four duties deserve immediate attention.

Registration

Organisations within scope must register in the national entity register. This provides the authorities and the relevant Computer Security Incident Response Team with the information required to coordinate oversight and support.

Registration sounds administrative, but it forces an important internal decision: who owns the organisation’s NIS2 status? If nobody is responsible for maintaining the registration, the same gap is likely to appear in incident reporting, regulatory communication and evidence management.

Duty of care

The Cbw requires organisations to perform risk analysis and implement appropriate and proportionate measures to secure network and information systems.

This is not a product list. The right measures depend on the organisation’s services, threats, dependencies and potential impact. NIS2 includes subjects such as incident handling, business continuity, crisis management, supply-chain security, vulnerability management, cryptography, access control, asset management and multifactor authentication.

The word proportionate is important. It does not mean minimal. It means that decisions should be connected to risk and supported by evidence.

Incident reporting

Significant incidents must be reported quickly. NIS2 uses a phased model: an early warning within 24 hours, a more complete incident notification within 72 hours and, normally, a final report within one month.

The first report will rarely contain perfect information. That is expected. The organisation still needs a process for deciding whether the incident may be significant, who has authority to notify and how technical facts are converted into a regulatory report without delaying containment.

The incident process should also account for overlapping obligations. A single event may trigger NIS2, GDPR, contractual, insurance and sector-specific notifications on different timelines. Treating each of these as a separate workflow creates confusion when time is limited.

Management responsibility

NIS2 brings cybersecurity into the boardroom. Management bodies must approve and oversee risk-management measures, and managers are expected to maintain relevant knowledge.

The practical meaning is not that every director must understand packet captures or malware analysis. They must be able to ask whether the organisation knows its critical services, whether risks are being addressed, whether incidents can be escalated and whether the claimed level of resilience has been tested.

Determine scope before buying controls

The first task is not selecting a platform or commissioning a penetration test. It is determining whether the organisation falls within scope and whether it is classified as an essential or important entity.

The Netherlands places responsibility on organisations to make that assessment. Sector and size are key factors, but special rules and designations can apply. Suppliers that are not directly in scope may still feel the effect because covered customers must manage security in their supply chains.

A useful scope assessment records:

the legal entities involved;
the services each entity provides;
the sectors and subsectors that may apply;
size and establishment criteria;
the systems and locations supporting those services;
relevant regulators, CSIRTs and reporting channels;
dependencies on group companies and external suppliers.

This prevents a common failure: implementing controls centrally while overlooking a subsidiary, service or operational environment that carries the actual obligation.

Supply-chain security will reach beyond 8,000 organisations

The direct scope of the Cbw is only part of its effect.

Organisations covered by the law must consider the security of suppliers and service providers. This will change procurement questionnaires, contracts, assurance requests and ongoing monitoring. A smaller technology provider may not be directly regulated but can still be required to meet stronger security conditions to retain a customer.

Suppliers should expect questions about:

incident notification and cooperation;
vulnerability disclosure and remediation;
access control and privileged accounts;
subcontractors and hosting locations;
business continuity and recovery testing;
evidence such as audits, certifications and test results;
the secure termination or transfer of services.

Responding with a policy document will not always be enough. Customers increasingly need evidence that the described process is operating.

Build one incident process for several laws

One of the most practical improvements an organisation can make is to create a single incident classification and notification process.

The technical incident should enter one decision flow. That flow can evaluate operational impact, affected services, personal-data exposure, geographic scope, supplier involvement and regulatory thresholds. From there, it can start the appropriate notification tracks.

This avoids three dangerous delays:

Security waits for legal to decide whether an incident is reportable.
Legal waits for security to provide certainty that is not yet available.
Business teams assume another department has already notified the authority.

The process should identify a decision owner, alternates, pre-approved contact routes and the minimum facts needed for an early warning. It should be tested in an exercise that includes executives, communications, privacy, suppliers and the operational teams that would handle the event.

What proportionate security looks like

NIS2 does not eliminate risk, and it does not require every organisation to build the same security architecture. It does require a defensible relationship between risk and control.

For a service that could cause significant societal disruption, proportionate security may include strong network separation, continuous monitoring, tightly controlled remote access, immutable recovery copies and regular crisis exercises.

For a lower-impact supporting system, a different control set may be reasonable. The important point is that the distinction is deliberate, documented and reviewed when the service changes.

This makes asset and service classification essential. If an organisation cannot identify what is critical, it cannot reliably apply stronger protection where it matters most.

A practical readiness sequence

With the law taking effect on 15 August 2026, organisations should focus on work that creates operational readiness rather than last-minute documentation.

Confirm scope and ownership.
Complete or validate registration information.
Map essential services, systems, data and suppliers.
Compare existing measures with the Cbw duty of care.
Fix high-impact gaps in identity, remote access, backups and monitoring.
Integrate NIS2 reporting into the existing incident process.
Review supplier contracts and practical escalation routes.
Brief and train management on its oversight responsibilities.
Exercise a realistic incident and record the lessons.
Maintain an evidence set that can be updated, not rebuilt for each audit.

Compliance is the floor

NIS2 creates a common European baseline because failures in critical services do not remain local. The Dutch Cyberbeveiligingswet turns that baseline into enforceable national duties.

The best outcome is not a completed compliance checklist on 15 August. It is an organisation that can see risk earlier, make decisions faster, contain incidents more effectively and recover with less damage.

That is the difference between being able to describe a security programme and being able to depend on it.

Sources and further reading

This article provides general technical and operational context, not legal advice.

Continue the series: European National Cyber & Digital Law Series index

NIS2 Becomes Dutch Law: What Changes on 15 August 2026

Why NIS2 is broader than its predecessor