Cyberbeveiligingswet from 15 August 2026: a practical NIS2 guide for healthtech suppliers

On 15 August 2026, the Netherlands' NIS2 implementation stops being a future compliance project. From that date, the Cyberbeveiligingswet applies to organisations within its scope - and its supply-chain rules will also be felt by many healthtech vendors that are not directly regulated.

Legal status as of 11 July 2026. The Cyberbeveiligingswet and Cyberbeveiligingsbesluit are final and were published on 10 July 2026. Both enter into force on 15 August 2026. The healthcare-specific ministerial regulation had not yet been published as final on the review date; draft provisions are identified as drafts in this article.

The law creates two different consequences for the healthtech market. First, some healthcare providers, medical-device manufacturers and digital service providers become essential or important entities with direct legal duties. Second, regulated hospitals and other healthcare organisations must assess and periodically monitor risks arising from their direct suppliers.

Selling to a hospital does not by itself place a supplier within the Cyberbeveiligingswet. It does, however, make cybersecurity evidence, rapid incident cooperation and operational resilience much more important in procurement and contract renewals.

The short answer

What changes on 15 August 2026?

The Cyberbeveiligingswet replaces the Wet beveiliging netwerk- en informatiesystemen and implements the EU NIS2 Directive in the Netherlands. There is no general statutory grace period: the principal duties apply when the law enters into force. Existing board members receive a specific two-year period to meet the statutory knowledge and training requirements.

1. Registration

Essential and important entities must register in the national entities register managed by the Nationaal Cyber Security Centrum (NCSC). Registration is already available through MijnNCSC and becomes compulsory on 15 August.

The process uses eHerkenning at assurance level EH2+ and requires an appropriate authorisation. The organisation should prepare its company, sector, contact and network information, including public IP ranges, domains and autonomous system numbers where applicable. Changes to registered information must be reported within 14 days.

2. Cybersecurity duty of care

An in-scope entity must take appropriate and proportionate technical, operational and organisational measures to manage risks to the network and information systems used for the relevant activities or services. The Cyberbeveiligingsbesluit requires documented policies, assigned responsibilities, applied processes and evidence that the controls work in practice.

• cybersecurity risk analysis and risk treatment;
• incident detection, response, documentation and recovery;
• business continuity, tested backups and crisis management;
• supply-chain security and periodic checks of direct suppliers;
• secure acquisition, development, maintenance and vulnerability handling;
• control-effectiveness reviews, cyber hygiene and training;
• cryptography, access management, personnel security and asset management;
• multi-factor authentication and secure communications where appropriate.

3. Incident reporting

Every significant incident must be reported to the entity's CSIRT and competent authority. The first notification is deliberately preliminary: an organisation must not wait for a complete forensic conclusion before starting the reporting process.

An incident is significant when it causes or could cause serious operational disruption or financial loss, or when it affects or could affect other organisations through substantial material or non-material damage. More detailed thresholds can be established in sectoral ministerial regulations.

4. Management responsibility

The board must approve the cybersecurity risk-management measures and oversee their implementation. Every board member must be able to identify cyber risks, assess the measures being taken and understand how those risks and measures affect the organisation's services.

Existing board members have two years to obtain the required knowledge and skills. The training must be evidenced by a certificate recording the participant, dates, provider and subjects covered. This two-year window does not postpone registration, incident reporting, risk management or board oversight.

Which healthtech organisations are directly covered?

Healthtech supplier is a market description, not a legal category. Coverage depends on the legal entity's activities, size, establishment and any specific designation. A reliable assessment therefore starts with the service or product legally provided - not with a list of customers.

Healthcare providers

A healthcare provider within the meaning of the Dutch Wet kwaliteit, klachten en geschillen zorg is included in Annex 1. Large healthcare providers are generally essential entities; medium-sized providers are generally important entities. A smaller provider can still be brought into scope through a specific designation or another applicable category.

Medical-device and IVD manufacturers

Entities manufacturing medical devices under the MDR and in-vitro diagnostic devices under the IVDR appear in Annex 2. A medium-sized or large legal manufacturer is therefore generally an important entity. This can include the legal manufacturer of software that qualifies as a medical device or IVD; manufacturer does not mean only a factory producing physical hardware.

A separate Annex 1 category covers manufacturers of medical devices included on the EU list of devices considered critical during a public-health emergency. A large manufacturer within that narrower category can be an essential entity, while a medium-sized manufacturer can be an important entity. MDR or IVDR risk class alone does not decide the Cbw category.

B2B managed services, managed security and cloud

A healthtech company may also be covered because of the service it provides. The B2B managed-service category is relevant where a supplier actively installs, manages, operates or maintains a customer's ICT products, networks, infrastructure, applications or systems. A conventional software licence or standard SaaS subscription does not automatically meet that definition.

Cloud classification is also fact-specific. NIS2 refers to on-demand remote access to a scalable and elastic pool of shareable computing resources. Hosting a health application in the cloud is not, by itself, enough to classify the application vendor as a cloud-computing provider.

Size matters - but the 50-employee shortcut is incomplete

The Dutch guidance uses the EU SME methodology. As a practical screening rule:

• A medium-sized organisation generally has 50-249 employees, or has annual turnover above EUR 10 million and a balance-sheet total above EUR 10 million, while remaining below the large-enterprise thresholds.
• A large organisation generally has at least 250 employees, or has annual turnover above EUR 50 million and a balance-sheet total above EUR 43 million.

These are not stand-alone tests. The formal calculation also considers whether the company is autonomous, a partner enterprise or a linked enterprise. Headcount and financial data from related companies may therefore need to be included. A 35-person venture-backed company should not conclude that it is outside scope without checking its group structure.

Size alone is also insufficient. The entity must perform an activity listed in Annex 1 or Annex 2, fall within a special entity category or be specifically designated. The official Dutch NIS2 self-evaluation tool is a useful starting point, but the conclusion should be recorded in a short written scope analysis.

What changes for suppliers that are not directly in scope?

For many healthtech companies, the first impact will arrive through procurement rather than a regulator. The Cyberbeveiligingsbesluit requires in-scope entities to define how supplier dependencies are managed and to check periodically whether direct suppliers and service providers meet the entity's security requirements.

This does not create one statutory questionnaire or require a full audit of every supplier. It creates a risk-based assurance obligation for the regulated customer. The following are common forms of evidence a healthtech supplier may be asked to provide; they are not a statutory checklist for every supplier:

• security ownership, approved policies and a current risk assessment;
• NEN 7510 or ISO 27001 certification, an independent assessment or equivalent evidence;
• secure-development, vulnerability-management and coordinated-disclosure processes;
• MFA, privileged-access control, logging and periodic access reviews;
• incident-response contacts and a tested escalation procedure;
• business-continuity plans, tested backups and agreed recovery objectives;
• visibility of critical subcontractors, subprocessors and hosting dependencies;
• evidence that material changes and incidents will be communicated promptly.

Supplier contracts should allow an in-scope customer to meet its own 24-hour reporting clock. The parties should define which events require notice, the initial notification deadline, out-of-hours contacts, the information supplied at each stage and the cooperation expected during regulatory reporting. A supplier should not wait for a complete root-cause analysis before sending an agreed early warning.

Does NEN 7510 satisfy the Cyberbeveiligingswet?

NEN 7510 is highly relevant, but NEN 7510 compliant and Cyberbeveiligingswet compliant are not interchangeable statements.

For relevant healthcare information and electronic exchange systems used by Dutch healthcare providers, the applicable editions were updated from 1 June 2026 to NEN 7510-1:2024 and NEN 7510-2:2024+A1:2026. This applicability decision concerns healthcare organisations and the relevant systems; it does not automatically impose the same legal status on every technology supplier.

The consultation version of the Cyberbeveiligingsregeling zorg proposed that Cbw risk-management measures may follow NEN 7510, follow ISO 27001 and ISO 27002, or provide an equivalent level of protection. As of 11 July 2026, that sectoral regulation had not yet been published as final. The final text must therefore be checked before relying on these provisions.

Even if the final regulation retains this approach, an ISMS or certificate does not complete the following duties:

• formal scope and jurisdiction assessment;
• NCSC registration and updates to registered information;
• 24-hour and 72-hour statutory incident reporting;
• application of final sector-specific incident thresholds;
• board approval, oversight and training evidence;
• communication with the competent authority, CSIRT and affected service recipients;
• controls or systems excluded from the certified ISMS scope.

How does the Cbw interact with MDR, IVDR and GDPR?

MDR and IVDR regulate medical devices and IVDs at product level. The Cyberbeveiligingswet regulates the entity's cyber resilience and the network and information systems used for its relevant activities and services. The GDPR adds a separate personal-data breach assessment.

A single ransomware or vulnerability incident can therefore trigger several parallel questions: Does it affect product safety or performance? Is MDR or IVDR vigilance required? Has personal data been compromised? Is it a significant Cbw incident? Which customers must be informed under contract?

One notification does not automatically satisfy every regime. Healthtech companies should use a single incident-classification workflow that routes the event through product safety, privacy, cybersecurity and customer obligations, while preserving the separate deadlines and decision criteria.

Enforcement and maximum fines

The law gives competent authorities supervisory and enforcement powers. For breaches of core risk-management and incident-reporting obligations, the statutory maximum administrative fines are:

These are maximums, not automatic penalties for every deficiency. The practical purpose of the enforcement framework is to make cybersecurity risk management demonstrable and accountable, not simply to punish organisations after an incident.

A practical readiness plan before 15 August

A company is unlikely to complete every long-term security improvement in a few weeks. It should nevertheless be able to show that it understands its scope, can report incidents, has active management oversight and is treating identified risks through an approved plan.

Four practical healthtech examples

A 90-person medical-device software company

A Dutch company is the MDR legal manufacturer of clinical decision-support software and has 90 employees. Assuming the formal SME calculation confirms medium-sized status, it will generally be an important entity under Annex 2. It should prepare for registration, management oversight, risk-management measures, supplier controls and incident reporting.

A 35-person hospital SaaS supplier

A Dutch company provides appointment and patient-communication software to hospitals. It is not a medical-device manufacturer and does not actively manage the hospitals' wider ICT systems. It is not automatically covered merely because its customers are hospitals. Its cloud and managed-service model, ownership structure and any specific designation should still be checked. Even if it remains outside scope, customers are likely to request stronger security and incident evidence.

A large Dutch healthcare provider

A Dutch healthcare provider has more than 250 employees. Healthcare providers appear in Annex 1, so the organisation will generally qualify as an essential entity. Its technology suppliers will become part of its direct-supplier risk-management programme.

A German supplier serving Dutch hospitals

A German healthtech supplier does not become subject to the Dutch Cbw merely because it has Dutch customers. For most activities, jurisdiction follows the country in which the entity is established. Special main-establishment rules apply to certain cross-border digital providers. The supplier may fall under Germany's NIS2 implementation while still facing Dutch hospital procurement requirements.

Conclusion

The Cyberbeveiligingswet does not turn every healthtech vendor into a regulated NIS2 entity. It does raise the security standard expected across Dutch healthcare.

Companies directly within scope need a documented classification, NCSC registration, working risk-management system, board oversight and an incident process capable of meeting the 24-hour deadline. Suppliers outside direct scope should avoid claiming statutory compliance they do not need; their priority is credible assurance evidence, resilient services and contracts that support their customers' reporting obligations.

The distinction is practical: direct legal scope determines who must register and report to the authorities. Supply-chain dependence determines which other suppliers will still be expected to prove that their security and resilience can be trusted.

Information only. This article provides general information and is not legal advice. Scope and jurisdiction should be assessed using the organisation's actual activities, legal structure and group relationships.