NIS2 Compliance Netherlands: 10 Cyberbeveiligingswet Measures

Looking for the NIS2 checklist? If you’d rather get straight to implementation, you can skip directly to the download section below to grab the full NIS2 Compliance Checklist (PDF & Excel formats).

What Is the Cyberbeveiligingswet and How Does It Relate to NIS2?

The European Directive sets overarching NIS2 directive requirements, but each Member State defines local enforcement according to different national implementation timelines. The Cyberbeveiligingswet (cbw) constitutes the Dutch transposition of the NIS2 Directive.

For organisations operating under NIS2 Netherlands oversight, understanding the transposition of European rules into national law is critical.

The Cbw entered into force on 15 August 2026, replacing the Wbni, which is no longer in force as the applicable Dutch cybersecurity law.

https://www.ncsc.nl/cyberbeveiligingswet-nis2

NIS2 compliance should not be approached as a one-time exercise. The cybersecurity landscape evolves continuously, so organisational systems, controls and risk management processes must also evolve to remain compliant with the Cyberbeveiligingswet.

Is NIS2 the Same as the Cyberbeveiligingswet?

No, NIS2 and the Cyberbeveiligingswet are not exactly the same. NIS2 is an EU directive, while the Cyberbeveiligingswet is the Dutch law that implements NIS2 in the Netherlands. In other words, NIS2 provides the European framework, while the Cyberbeveiligingswet translates those requirements into Dutch legislation and enforcement.

When Did the Cyberbeveiligingswet Enter Into Force?

The Cyberbeveiligingswet entered into force on 15 August 2026. From this date, organisations covered by the law must comply with its cybersecurity requirements. The Dutch government confirmed the date after the Senate approved the Cyberbeveiligingswet on 7 July 2026, replacing the previous Wbni framework.

Does the Cyberbeveiligingswet Apply to Your Organisation?

To determine whether the Cyberbeveiligingswet applies to your organisation and which cyber security requirements you need to meet, follow this structure:

1. Are you in Annex I or II?
↓
2. Are you medium/large?
↓
3. Do special “regardless of size” rules apply?
↓
4. Essential or Important Entity

1. Is Your Organisation in an NIS2 Annex I or Annex II Sector?

2. Does Your Organisation Meet the NIS2 Size Requirements?

According to the definition in NIS2 for the organisation to be considered Medium or Large, these conditions should be met:

3. Does Your Organisation Fall Under the NIS2 Special Rules Regardless of Size?

• Qualified trust service providers

• TLD registries

• DNS service providers

• Medium-sized or large providers of public electronic communications networks or publicly available electronic communications services

• Central government public administration entities (raising the regulatory baseline for public sector IT security across national and regional bodies)

• Entities identified as critical entities under the CER Directive

• Other Annex I or Annex II entities designated as Essential by the Member State

• Entities previously identified as Operators of Essential Services (OES) under the previous NIS Directive, if the Member State chooses to retain this classification

  
  

Important additional point

There are also other organisations that can be brought into NIS2 regardless of size because of their particular criticality in the Member State, for example entities that are:

• the sole provider of an essential service in a Member State;

• critical to public safety, public security or public health;

• capable of creating a significant systemic risk, particularly cross-border;

• particularly critical at national or regional level.

4. Essential or Important entity

If an organisation falls within the scope of NIS2, it is classified as either an Essential Entity or an Important Entity, depending on its sector, size and specific circumstances. For example, a large electricity company in Annex I would generally be classified as an Essential Entity, while a medium-sized food manufacturer in Annex II would generally be classified as an Important Entity.

You can check if you fall within the scope on the link below:

https://regelhulpenvoorbedrijven.nl/NIS-2-NL/#home

What If You Supply an Organisation That Falls Under NIS2?

Even if your organisation is outside NIS2’s direct scope, you may still face security requirements from customers that are covered by the directive. The NCSC warns that organisations within scope are likely to impose cybersecurity requirements on their suppliers and business partners. This makes third-party risk management increasingly important for understanding, documenting, and meeting customer security expectations. Explore RiskRhino’s third-party management solution.

The 10 Cyberbeveiligingswet Measures for NIS2 Compliance: Key NIS2 Compliance Requirements

1. Conduct a Cybersecurity Risk Analysis

An effective NIS2 risk assessment identifies the cybersecurity risks that could affect critical services, systems and assets. It forms an important part of NIS2 risk management, helping organisations assess risks systematically and implement appropriate security measures.

What You Need to Do

Your NIS2 risk management process should cover:

• Identify critical services, systems, and assets.

• Identify relevant threats and vulnerabilities.

• Assess the likelihood and potential impact of each risk.

• Document existing security controls.

• Determine the resulting residual risk.

• Define and document appropriate risk treatment measures.

  
  

Evidence to Keep

Maintain clear evidence that demonstrates how risks are assessed and managed, including:

• Documented risk assessment methodology.

• Current risk register.

• Latest risk assessments.

• Assigned risk owners.

• Documented risk treatment decisions.

• Management approval and review records.

  
  

Practical Example

A logistics company depends on a cloud-based warehouse management platform to process orders and coordinate deliveries.

• Critical system: cloud based warehouse management platform

• Threat: Ransomware compromises the platform or a connected system.

• Business impact: Warehouse operations are disrupted, delaying orders and deliveries.

• Risk: The company may be unable to fulfil customer orders during an extended outage.

• Controls: MFA, access controls, backups, network segmentation, and incident response procedures.

• Residual risk: The remaining risk after controls are applied is assessed and either accepted, further treated, transferred, or avoided.

Use RiskRhino free Risk Scoring Matrix to consistently assess likelihood and impact and support risk treatment decisions.

2. Establish an NIS2 Incident Response Process

Your incident response process should define what happens from the moment an incident is detected until the organisation has recovered and documented what happened.

At a minimum, the process should cover:

• Detection: identify and validate potential security incidents.

• Classification: determine the type, severity and potential business impact.

• Escalation: involve the right technical, management, legal and external contacts.

• Containment: limit the spread and reduce further damage.

• Recovery: restore affected systems and services safely.

• Communication: coordinate internal, customer, supplier and regulatory communications where required.

• Reporting: document the incident and make required regulatory notifications.

The process should also define who is responsible for each step. During an incident, people should not have to work out responsibilities from scratch.

Prepare for NIS2 Incident Reporting

For organisations covered by the Cyberbeveiligingswet, NIS2 incident reporting should be built into the incident response process rather than treated as a separate compliance task.

A significant incident must be reported through the Dutch central reporting point. The Cbw uses a phased reporting process: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. If the incident is still ongoing after one month, a progress report is submitted and the final report follows after the incident has been resolved.

Incident detected → assess significance → early warning ≤24h → notification ≤72h → final report ≤1 month

The reporting process should be tested before a real incident occurs. Your incident response plan should make clear who decides whether an incident is significant, who submits the notification, what information is required and who communicates with the CSIRT and supervisory authority.

Evidence to Keep

Keep enough evidence to demonstrate that the incident response process exists, is assigned to responsible people and is actually tested.

At a minimum, retain:

• Incident Response Plan: current procedures, responsibilities and decision points.

• Incident log: record of incidents, actions, decisions, timestamps and outcomes.

• Assigned roles: documented incident response responsibilities and deputies.

• Contact and escalation list: internal contacts, management, suppliers, CSIRT and other relevant parties.

• Tabletop exercise records: scenarios, participants, findings and resulting actions.

• Lessons learned: what happened, what worked, what failed and what needs to change.

The goal is to show that your organisation can detect, respond to, report and learn from a cybersecurity incident.

3. Prepare for Outages and Ensure Business Continuity

NIS2 requires organisations to prepare for situations where cybersecurity incidents or other disruptions affect the availability of critical services and systems.

Business continuity is not just having backups. Your organisation should know which services must be restored first, how they will be restored, who makes recovery decisions and how the business will operate while systems are unavailable.

Your approach should cover:

• Business Continuity Plan (BCP): define how critical business activities will continue during a disruption and what alternative processes are available.

• Backups: maintain appropriate backups of critical data and systems and regularly verify that they can actually be restored.

• Disaster Recovery (DR): define the technical procedures for recovering systems, applications and infrastructure after a major outage or security incident.

• Restoration priorities: identify which systems and services need to be recovered first based on their business importance and dependencies.

• Testing: regularly test continuity, backup and recovery procedures to identify weaknesses before an actual outage occurs.

A backup that has never been restored is not evidence that you can recover. Testing should therefore include actual recovery where practical, not just confirmation that backups completed successfully.

Evidence to Keep

Keep documentation and test results that demonstrate your organisation has planned for disruption and can recover critical services.

At a minimum, retain:

• Business Impact Analysis (BIA): identify critical processes, dependencies, recovery requirements and business impact.

• Business Continuity Plan (BCP): documented continuity strategies, responsibilities and procedures.

• Disaster Recovery Plan: technical recovery procedures, system dependencies and restoration steps.

• Recovery test records: test dates, scenarios, results, failures and follow-up actions.

• Backup test records: evidence that backups are available, usable and can be restored.

• Corrective actions: documented weaknesses identified during tests, assigned owners and remediation status.

The objective is simple: if a critical system goes down, your organisation should know what matters most, how to recover it and who is responsible for making it happen.

4. Secure Your Supply Chain

Your organisation's cybersecurity depends partly on the security of its suppliers, service providers and other third parties. A supplier with access to your systems or data can introduce risks that your internal security controls do not fully address.

NIS2 supply chain security therefore requires organisations to understand their important supplier relationships, assess the associated risks and apply appropriate security requirements.

Identify Critical Suppliers

Start by identifying suppliers that could significantly affect your critical services, systems or data if they were compromised or became unavailable.

Do not treat every supplier equally. Map important dependencies and determine:

• Which suppliers support critical business services?

• Which suppliers have access to your systems or network?

• Which suppliers process sensitive or business-critical data?

• Which suppliers would cause significant disruption if they became unavailable?

• Which suppliers rely on important subcontractors?

This dependency mapping gives you a basis for prioritising supplier risk assessments and security requirements.

Assess Supplier Cybersecurity Risk

Supplier risk assessments should be proportionate to the supplier's criticality and exposure.

Consider factors such as:

• Criticality: determine how important the supplier is to your services and operations.

• Access: assess whether the supplier has privileged, remote or other access to your systems.

• Data processing: identify what information the supplier handles and how sensitive it is.

• Subcontractors: understand whether the supplier relies on other parties to deliver the service and how those relationships are controlled.

• Certifications: consider relevant certifications and independent assurance where appropriate.

  
  

The assessment should result in a documented risk decision. Where weaknesses are identified, define remediation actions, assign responsibility and track them to completion.

Include Cybersecurity Requirements in Contracts

Supplier security should not depend only on informal expectations. Important cybersecurity requirements should be reflected in contracts and, where appropriate, service-level agreements.

Depending on the supplier and risk involved, contractual requirements may include:

• incident notification,

• security requirements

• audit rights

• access controls

• subcontractor obligations

Evidence to Keep

Maintain evidence showing that supplier cybersecurity risks are identified, assessed and managed throughout the relationship.

At a minimum, retain:

• Supplier inventory: current list of suppliers, services, criticality and relevant dependencies.

• Supplier risk assessments: documented assessments and risk decisions.

• Contracts: agreements containing applicable cybersecurity requirements.

• Remediating actions: identified weaknesses, assigned owners, deadlines and status.

• Supplier reviews: periodic reviews of security posture, changes, incidents and outstanding risks.

The objective is to identify which third parties matter most, understand the risks they introduce and demonstrate that those risks are being actively managed.

5. Establish Strong Cyber Hygiene

Cybersecurity measures are only effective if employees understand core principles of cyber security and know how to apply them in daily operations. Embedding fundamental cybersecurity principles into organizational culture ensures security policies translate into practical habits.

Cyber hygiene should be treated as an ongoing process rather than a one-time training exercise.

Security Policies

Define clear cybersecurity policies that explain the security rules employees and relevant third parties are expected to follow. Internal cyber policies should cover critical areas such as acceptable use, authentication rules, access management, and incident escalation.

These cybersecurity policies should cover the areas relevant to your organisation, such as acceptable use, password and authentication requirements, access management, remote working, incident reporting and handling of sensitive information.

The objective is provide clear, practical rules that employees can follow, they do not have to be long, boring documents.

Employee Cybersecurity Training

Employees should receive cybersecurity training appropriate to their roles and responsibilities.

Training can cover common risks such as phishing, credential theft, social engineering, malware, data handling and incident reporting. Employees with privileged access or security responsibilities may require additional role-specific training.

Training should be repeated periodically and updated when significant threats or organisational changes require it.

Cyber Exercises and Simulations

Training alone does not demonstrate that your organisation is prepared to respond to a cybersecurity incident.

Use exercises and simulations to test how employees and responsible teams react to realistic scenarios. Depending on the organisation, this could include phishing simulations, incident-response exercises or tabletop scenarios involving management and key business functions.

Record what happened during each exercise, identify weaknesses and assign remediating actions.

Evidence to Keep

At a minimum, retain:

• Policies: current security policies and their review history.

• Acknowledgements: evidence that relevant employees have received and acknowledged applicable policies.

• Training completion: training records, completion rates and role-specific training where applicable.

• Exercise results: scenarios, participants, findings and outcomes from cybersecurity exercises.

• Corrective actions: weaknesses identified during training or exercises, assigned owners and remediation status.

The goal is to demonstrate that people understand their security responsibilities and that the organisation uses exercises and incidents to improve them over time.

6. Secure Network and Information Systems

Organisations must shift from reactive patching to proactive security measures throughout the lifecycle of their digital assets. A robust security implementation framework ensures security controls are integrated into acquisition, code development, and ongoing configuration management.

For a practical NIS2 approach, focus on having defined processes for:

• secure acquisition,

• secure development,

• patching,

• vulnerability management,

• configuration management,

• assigned responsibility for vulnerability findings

These processes should be risk-based. Not every vulnerability, system or configuration change presents the same level of risk, so organisations should be able to demonstrate how they prioritise remediation based on potential impact and exposure.

Evidence to Keep

Maintain evidence that security requirements are defined, vulnerabilities are identified and addressed, and important systems are managed through controlled processes.

Examples can include:

• Vulnerability scans: records of identified vulnerabilities, severity and affected systems.

• Patch reports: evidence of security updates applied and outstanding exceptions.

• Policies: documented requirements for secure acquisition, development, vulnerability and configuration management.

• Change records: evidence that significant system and configuration changes are authorised and controlled.

• Corrective actions: assigned vulnerabilities or security findings, owners, deadlines and resolution status.

The objective is to have a repeatable process for identifying security weaknesses, prioritising them and demonstrating that appropriate action is being taken.

7. Manage Personnel, Access and Assets for NIS2 Compliance

Effective personnel and access management starts with an accurate asset inventory, clear access rules and processes for changing or removing access when people's roles change.

NIS2 Asset Management & Inventory Maintenance

Effective NIS2 asset management begins with maintaining an up-to-date inventory of critical hardware, software, systems, applications and other assets that support your organisation's services.

The inventory should identify relevant owners and, where appropriate, dependencies and business criticality. It should also be updated when assets are acquired, changed or retired.

Apply Least-Privilege Access

Give users only the access they need to perform their responsibilities.

Access should be based on job responsibilities and reviewed periodically. Where possible, separate standard user accounts from privileged accounts and apply stronger controls to administrative access.

Access should also be removed or changed when it is no longer required.

Implement Joiner, Mover and Leaver Processes

Access management should be connected to employee lifecycle processes.

• Joiners: provide the access required for the person's role.

• Movers: update or remove access when responsibilities change.

• Leavers: promptly disable accounts and revoke access when employment or the relevant relationship ends.

These processes should cover employees as well as relevant contractors and third parties.

Review Privileged/Admin Access

Privileged accounts can create significantly greater risk because they can make important changes to systems, configurations and data.

Identify privileged users and regularly review whether their elevated access is still required. Unnecessary privileged access should be removed, and privileged activities should be appropriately controlled and monitored.

Evidence to Keep

Keep evidence that demonstrates assets and access are actively managed rather than simply documented once.

An example of such evidence:

The objective is straightforward: know your assets, limit access to what people need and remove access when they no longer need it.

8. Use Strong Authentication, MFA and Passkeys

Strong authentication reduces the risk of compromised credentials being used to gain access to important systems and services.

Organisations should define where stronger authentication is required and apply appropriate controls based on the sensitivity and risk of the access involved. This can include multi-factor authentication (MFA), passkeys and other strong authentication mechanisms.

Where Strong Authentication Should Be Prioritised

Prioritise strong authentication for access that could have a significant impact if credentials are compromised, including:

• Privileged accounts: administrator and other accounts with elevated permissions.

• Remote access: connections to internal systems and corporate environments from outside the organisation.

• Cloud services: especially services containing sensitive information or supporting critical operations.

• Sensitive systems: systems processing important business, personal or otherwise sensitive data.

• Administrative consoles:interfaces that allow users to change security settings, configurations or access rights.

MFA or passkeys should not be treated as a standalone control. Access should also be protected through appropriate permissions, account management and monitoring.

Where exceptions are necessary, document the reason, assess the associated risk and define compensating measures where appropriate.

Evidence to Keep

Maintain evidence showing where strong authentication is required, how widely it is implemented and how exceptions are managed.

Keep, at a minimum:

• authentication policy,

• MFA coverage report,

• exceptions and their justification,

• periodic reviews.

The goal is to demonstrate that strong authentication is applied to the access that matters most and that any gaps are known, justified and managed.

9. Establish a Cryptography Policy

A cryptography policy should define how your organisation uses encryption and other cryptographic controls to protect information and systems.

What a Cryptography Policy Should Cover

At a minimum, your policy should address the following areas:

• Data at rest: Define when sensitive or business-critical information must be encrypted when stored.

• Data in transit: Define requirements for protecting information when it moves between systems, applications, users or third parties.

• Acceptable algorithms and protocols: Specify which cryptographic algorithms, protocols and configurations are approved and identify obsolete or prohibited technologies.

• Key management: Define how cryptographic keys are generated, stored, distributed, rotated, revoked, backed up and eventually destroyed.

• Ownership and responsibilities: Assign responsibility for approving cryptographic requirements, managing keys, maintaining configurations and reviewing exceptions.

• Review cycle: Define when the policy and its technical requirements are reviewed.

Evidence to Keep

Useful evidence includes:

• Cryptography policy: current policy, approval and review history.

• Encryption inventory: identification of important systems and data stores where encryption is required or implemented.

• Technical standards: approved algorithms, protocols, configurations and minimum requirements.

• Key management procedures: documented processes for key generation, storage, rotation, revocation, backup and destruction.

• Key ownership records: assigned owners and responsibilities for important cryptographic keys or key-management systems.

• Configuration evidence: relevant system or cloud configuration showing that required encryption is enabled.

• Exceptions: documented cases where a cryptographic requirement cannot be met, including the reason, associated risk, approval and compensating measures.

• Periodic reviews: evidence that the policy and cryptographic controls have been reviewed and updated when necessary.

  
  

The objective is simple: protect sensitive information with appropriate cryptographic controls and make sure those controls do not become outdated or unmanaged.

10. Regularly Assess Whether Your Security Measures Are Effective

Organisations should regularly assess whether their controls are implemented, effective and still appropriate for the risks they face.

Policy exists ≠ control works.

For example, having a policy requiring quarterly access reviews does not prove that reviews are actually performed or that inappropriate access is removed.

Test Controls, Not Just Their Documentation

Test whether controls work in practice through activities such as:

• Reviewing records and configurations.

• Sampling users, systems or suppliers.

• Reperforming control activities.

• Reviewing incidents and exercise results.

• Testing technical controls where appropriate.

The goal is to verify that controls operate as intended, not simply that the required documentation exists.

Establish a Recurring Control Monitoring and Testing Cycle

Control assessments should be ongoing rather than a one-time compliance exercise:

Implement → Test → Find Gaps → Remediate → Reassess

The frequency should be based on risk. Critical controls may need more frequent testing, while significant changes to systems, suppliers or risks should trigger additional assessments.

Evidence to Keep

Keep practical evidence showing that controls are regularly assessed:

• Control tests

• Supporting evidence

• Findings

• Remediating actions

• Approvals

• Periodic assessment results

RiskRhino software can simplify this process by automating recurring manual control executions and control monitoring, assigning tasks to control owners, collecting evidence and tracking remediation.

The objective is simple: continuously verify that your security measures work and remain appropriate as your risks change.

NIS2 Compliance Checklist for the Netherlands

Wondering what your organisation needs to have in place for NIS2 compliance? This NIS2 compliance checklist provides a practical starting point for understanding the key requirements of the Cyberbeveiligingswet in the Netherlands.

Scope & Governance

☐ Confirm whether the Cyberbeveiligingswet applies to your organisation
☐ Determine your Essential or Important Entity status
☐ Complete required registration and assign responsibilities

Risk & Security

☐ Perform a cybersecurity risk analysis
☐ Maintain a current risk register and treatment plan
☐ Implement appropriate security, access and authentication controls

Incident & Continuity

☐ Establish and test an Incident Response Plan
☐ Prepare business continuity, backup and disaster recovery procedures
☐ Understand your incident reporting obligations

Third-Party & Supply Chain

☐ Identify critical suppliers and dependencies
☐ Assess supplier cybersecurity risks
☐ Include appropriate security requirements in contracts

Evidence & Continuous Compliance

☐ Document policies, controls and supporting evidence
☐ Test whether security measures actually work
☐ Track findings, remediation and recurring assessments

This is only a preview. The full checklist provides a more detailed, practical breakdown of the actions, evidence and responsibilities to consider across each NIS2 requirement.

Download the full NIS2 Compliance Checklist PDF and Excel spreadsheet

You can download the NIS2 Compliance Checklist in English and in Dutch. Input your data and you will receive an email with a link to the documents,

What Evidence Should You Maintain for NIS2 Compliance?

NIS2 compliance is not just about having policies and controls in place. Organisations should also be able to demonstrate that those measures exist, are implemented and are working effectively.

The exact evidence will depend on your organisation and risk profile, but the following provides a practical starting point:

The key is to maintain traceable evidence that connects your risks, controls, responsibilities and remediation activities. This makes it easier to demonstrate compliance during internal reviews, audits or regulatory assessments.

Who Should Be Responsible for NIS2 Compliance?

NIS2 compliance should not sit with the IT or security team alone. Management remains accountable for ensuring that appropriate cybersecurity measures are implemented and supervised, while different teams are responsible for carrying out specific activities.

A simple responsibility model could look like this:

A = Accountable, R = Responsible, C = Consulted, I = Informed

The important point is not to create a complicated RACI matrix. It is to make sure that every important NIS2 activity has a clear owner, appropriate oversight and documented evidence of completion.

This also supports a continuous compliance approach: assign → execute → collect evidence → review → remediate.

How to Manage NIS2 Compliance as a Continuous Process

NIS2 compliance should not become a collection of documents that is updated only before an audit. As risks, systems, suppliers and security measures change, compliance needs to be maintained continuously.

Most organisations move through three stages:

Stage 1 - Documents and Spreadsheets

Compliance is managed through separate files and tools:

• Risk register.xlsx

• Supplier spreadsheets

• Security policies

• Emails and reminders

• Audit folders

This can work initially, but it becomes difficult to track ownership, deadlines, evidence and changes as the organisation grows. Maintaining compliance becomes the real challenge.

Stage 2 - Structured Processes

The organisation introduces repeatable processes for:

• Assigning control and risk owners

• Running recurring assessments

• Collecting evidence

• Recording findings

• Tracking remediation

This provides more consistency, but information is still spread across different systems and documents and inconsistencies are the killer of the approach.

Stage 3 - Integrated GRC

A mature approach connects the different parts of the security and compliance programme:

Risks ↔ Controls ↔ Assets ↔ Suppliers ↔ Incidents ↔ Evidence

This makes it easier to understand how a risk relates to a control, what evidence supports that control, which suppliers or assets are affected and whether outstanding findings have been addressed.

Where GRC Software Helps

NIS2 compliance software can help organisations manage NIS2 requirements in one structured system, rather than relying on disconnected spreadsheets, documents and manual processes. RiskRhino GRC software includes:

• AI Agents

• Central risk register

• Control mapping

• Recurring assessment workflows

• Policy management

• Third-party assessments

• Evidence collection

• Findings and remediation

• Compliance reporting

• Audit trail

The goal is to make compliance repeatable, traceable and easier to maintain as the organisation changes.

Contact us to see how RiskRhino can help structure and continuously manage NIS2 compliance.

Frequently Asked Questions About NIS2 and the Cyberbeveiligingswet

What is the Cyberbeveiligingswet?

The Cyberbeveiligingswet (Cbw) is the Dutch cybersecurity law implementing the European NIS2 Directive. It establishes cybersecurity, risk management, incident reporting and other requirements for organisations within its scope.

Is the Cyberbeveiligingswet the Dutch implementation of NIS2?

Yes. NIS2 is an EU directive, while the Cyberbeveiligingswet is the Dutch legislation that transposes NIS2 into national law. The Dutch law therefore provides the specific legal framework that applies to organisations in the Netherlands.

Who needs to comply with NIS2 in the Netherlands?

Organisations operating in the sectors covered by Annex I or Annex II may fall within scope, depending on their size and specific circumstances. Certain organisations can also fall within scope regardless of size because of their criticality or specific role. Organisations should assess their sector, size and applicable special rules to determine whether the Cyberbeveiligingswet applies.

When did the Cyberbeveiligingswet enter into force?

The Cyberbeveiligingswet entered into force on 15 August 2026, replacing the previous Wbni framework.

Is NIS2 registration mandatory?

For organisations covered by the Cyberbeveiligingswet, registration with the relevant Dutch Cbw entities register is part of the compliance process. Organisations should confirm their registration requirements and complete the applicable registration.

What are the 10 Cyberbeveiligingswet measures?

The 10 measures cover:

1. Cybersecurity risk analysis

2. Incident response

3. Business continuity and outage preparedness

4. Supply chain security

5. Cyber hygiene and security awareness

6. Secure network and information systems

7. Personnel, access and asset management

8. Strong authentication, MFA and passkeys

9. Cryptography and encryption

10. Effectiveness of security measures

These measures cover both the implementation of cybersecurity controls and the ongoing assessment of whether those controls remain effective.

What are the NIS2 incident-reporting requirements?

For organisations covered by the Cyberbeveiligingswet, a significant incident follows a phased reporting process: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month.

Do suppliers need to comply with NIS2?

Not necessarily. An organisation outside the direct scope of NIS2 may still face cybersecurity requirements from customers that are subject to the Cyberbeveiligingswet. This makes supplier security and third-party risk management an important part of the NIS2 compliance programme.

Can ISO 27001 help with NIS2 compliance?

Yes. ISO 27001 can provide a useful framework for managing information security risks and controls, and there can be significant overlap with NIS2 requirements. However, ISO 27001 certification does not automatically mean that an organisation meets every Cyberbeveiligingswet requirement. A gap analysis should be performed to identify any additional requirements that need to be addressed. You can read more about it here.

From NIS2 Requirements to Continuous Cybersecurity Management

NIS2 compliance is not about completing ten tasks once and putting the checklist away. Cybersecurity risks, systems, suppliers and business activities change over time. Your compliance programme therefore needs to evolve with them.

A practical continuous approach is:

Identify risks → Implement controls → Collect evidence → Test effectiveness → Remediate → Repeat

This is also consistent with a risk-based approach: organisations need to understand their risks and determine which measures are appropriate to manage them.

The ultimate goal of the Cbw framework is improving cybersecurity resilience across all critical Dutch supply chains. By establishing a closed-loop monitoring model, your organisation ensures its defenses continuously adapt as threats evolve.