The Dutch Cybersecurity Act: what the Dutch NIS2 law means for IT providers

The Dutch Cybersecurity Act (Cyberbeveiligingswet, Cbw) has applied since 15 August 2026 and, according to the Dutch government, covers more than 8,000 organisations in 18 sectors, from energy and healthcare to digital infrastructure and public administration. It is the Dutch transposition of the EU NIS2 Directive and replaces the earlier Wbni. For an IT or software provider the Act arrives by one of two routes: you are in scope yourself, or you supply an organisation that is.

This page is an explanation, not legal advice. Whether your organisation is in scope depends on your exact services and size.

What the Act requires

The Cbw places four obligations on organisations in scope:

The duty of care is worked out further in the Cybersecurity Decree (Cyberbeveiligingsbesluit) and in sector-specific ministerial regulations. For public sector bodies, that is the BIO2.

Are you in scope yourself

According to the NCSC, two questions decide it:

1. Sector. Does your organisation operate in a sector listed in annex 1 or 2 of the Act? For IT companies the relevant ones are mainly digital infrastructure (including cloud computing service providers, data centres, content delivery networks and DNS services), ICT service management (managed service providers and managed security service providers) and digital providers (online marketplaces, search engines, social networks).
2. Size. Do you have 50 or more FTE, or fewer than 50 FTE but both an annual turnover and a balance sheet total above 10 million euros? Linked enterprises count. Some types, such as DNS service providers, trust service providers and public bodies, are in scope regardless of size.

In practice that means, for example:

• A hosting company or managed service provider with 60 FTE is almost certainly in scope.
• A SaaS provider with 70 FTE may count as a cloud computing service provider. That depends on how the service is delivered, so check it.
• A healthcare software supplier with 30 FTE is usually not in scope itself, but it supplies hospitals and care providers that are.

The Dutch Digital Infrastructure Inspectorate (RDI) offers a NIS2 self-assessment that gives a quick first indication.

Essential or important

The Act distinguishes essential and important entities. Large organisations in annex 1 sectors are generally essential; medium-sized ones in those sectors, and organisations in annex 2, are generally important. The obligations are the same. The difference lies in supervision: for essential entities the supervisor checks proactively, even without signs of a breach; for important entities it acts reactively, for example after an incident or a report.

Who supervises

The NCSC runs the register and the reporting portal. Supervision sits with a separate authority per sector. A selection from the NCSC overview:

A report made through the NCSC portal goes automatically to both the sector CSIRT and the supervisor.

Registering with the NCSC

Registration takes place through MijnNCSC using eHerkenning at level EH2+ and an authorisation to act for the organisation. You provide organisation and contact details and your network data: public IP addresses and ranges, domain names and AS numbers. Changes must be submitted within 14 days. Have someone with decision-making authority do it, such as the managing director or the security officer.

Incident reporting in three steps

The deadlines run from the moment you become aware of the incident:

1. Within 24 hours, an early warning, stating among other things whether malicious intent is suspected and whether there are cross-border effects.
2. Within 72 hours, an incident notification with an initial assessment of severity and impact.
3. No later than one month after the notification, a final report with the root cause and the measures taken, or a progress report if the incident is still ongoing.

What counts as significant depends on disruption of the service, financial damage and harm to others. Thresholds differ per sector and are set in ministerial regulations.

What the Act asks of management

Directors must approve the measures, oversee their implementation and have enough knowledge to judge cyber risks. They complete training within two years of the Act taking effect and receive proof of it. Management stays ultimately responsible, even when it delegates the work to a CISO. The NIS2 Directive also provides that directors can be held liable for breaches of the duty of care, and requires member states to allow fines of at least 10 million euros or 2 per cent of worldwide annual turnover for essential entities, and 7 million euros or 1.4 per cent for important entities.

In the chain: what your customer will ask

A provider that is not in scope itself receives the requirements through its customers. The NCSC points to suppliers that deliver services or products related to network and information systems, supply an ICT component, or have access to those systems. Organisations under the Cbw must manage the risks those suppliers bring, so they will ask more questions and agree terms on:

• the security measures you take;
• how and how quickly you report incidents to them;
• how you handle vulnerabilities;
• the continuity of your service.

A healthcare software supplier will notice this as a new supplier questionnaire or a revised SLA or data processing annex. According to the NCSC the Act does not prescribe a certificate, but an ISO 27001 certificate does shorten that conversation.

What ISO 27001 already covers

A working ISO 27001 ISMS covers much of the duty of care: risk analysis, incident management, continuity, supplier management, access security and cryptography all have a place in Annex A. What it does not settle on its own are the statutory parts: registration, the reporting deadlines towards the CSIRT and supervisor, and the training obligation for management. How the duty of care maps onto the Annex A controls is set out in the article on NIS2 duty of care and reporting.

The practical step for an ISO 27001 supplier is therefore not a second system, but the same controls linked to an additional set of requirements. Trustbird is built around that idea: a control exists once and points to every requirement it covers.