Cybersecurity incident reporting duties in the Netherlands are governed by the Cybersecurity Act (Cyberbeveiligingswet, Cbw), which entered into force on 15 August 2026 and replaced the Network and Information Systems Security Act (Wet beveiliging netwerk- en informatiesystemen, Wbni). Organisations covered by the Act must report a significant incident within 24 hours of detection, follow it with a fuller notification within 72 hours, and submit a final report within one month. Reports go through the portal of the National Cyber Security Centre (NCSC), which passes them to the relevant CSIRT and to the competent supervisor.
The Cbw implements the NIS2 Directive and arrived alongside the Critical Entities Resilience Act (Wet weerbaarheid kritieke entiteiten, Wwke), which implements the CER Directive and imposes physical resilience and reporting obligations on the roughly five hundred organisations designated as critical entities. Our wider guide to NIS2 and the Dutch Cybersecurity Act covers the duty of care in full; this article sets out who falls under the reporting regime, when an incident crosses the threshold, which reports are due when, which authority receives them, and how the duty interacts with the notification obligations you may already have under the GDPR or DORA.
Which organisations the reporting duty covers
The Cbw applies to essential entities and important entities across eighteen sectors. Essential entities include energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space. Important entities cover postal and courier services, waste management, the manufacture of chemicals and of food, manufacturing of medical devices, computers and vehicles, digital providers such as online marketplaces, search engines and social platforms, and research organisations.
Size normally decides the classification within a sector. Large organisations in an essential sector are essential entities, medium-sized organisations are important entities, and organisations below the medium-sized threshold usually fall outside the Act. That size rule has exceptions: providers of DNS services, top-level domain registries, trust service providers, providers of public electronic communications networks and services, and parts of public administration fall under the Act regardless of size, as do organisations that are the sole provider of a service critical to society or whose disruption would have a significant effect. Whether you are an essential or an important entity does not change the reporting deadlines; it changes the intensity of supervision and the ceiling on the fine.
Registration comes before reporting
An organisation that falls under the Cbw must register itself in the national entity register kept by the NCSC, stating among other things its sector, its contact details for incidents and the internet domain names for which it is responsible. Registration is not a formality that can wait for the first incident: the register is how the CSIRT and the supervisor know who you are, and reporting through the portal presupposes that you are in it. Changes to the registered details must be passed on.
Alongside registration the Act imposes a duty of care. Entities must take appropriate and proportionate technical, operational and organisational measures against the risks to their network and information systems, worked out further in the Cybersecurity Decree (Cyberbeveiligingsbesluit) and in ministerial rules. The Act also places responsibility at the top: the management body approves the risk-management measures, is accountable for compliance, and must follow training on cybersecurity risks. That accountability is one of the practical differences with the old Wbni, and it is a governance question rather than an IT question. It sits alongside the criminal-law side of cybersecurity, on which our note on the Cybercrime III Act is the starting point. Our overview of the compliance frameworks a Dutch business has to reckon with puts it in context.
When an incident becomes reportable
The trigger is a significant incident, not any incident. An incident is significant where it causes or is capable of causing a serious operational disruption of the services or financial loss for the entity concerned, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The clock starts on detection, not on completion of the investigation, so the first decision has to be taken on incomplete information.
Because the statutory criterion is open, sector-specific thresholds and guidance fill it in. In assessing significance the questions that matter are how long the service has been unavailable and to how many recipients, whether data has been accessed or altered without authorisation and in which categories, whether the effects reach other member states, whether the incident disrupts services you supply to other essential or important entities, and how long recovery is expected to take. Cascading effects count in their own right: a cloud provider whose breach disrupts a hospital reports on the basis of that disruption, not only on the basis of its own losses.
The sensible response to an open norm is to write down where your own threshold lies before anything happens. A short internal classification standard, applied consistently and recorded, is both an operational aid and evidence of good faith if a supervisor later asks why a particular incident was not reported.
The three reports and their deadlines
The reporting duty is staged. Within 24 hours of becoming aware of a significant incident you submit an early warning, stating whether the incident is suspected of being caused by unlawful or malicious acts and whether it may have cross-border effects. Within 72 hours you submit the incident notification, which updates the early warning with an initial assessment of the incident, its severity and impact, and, where available, the indicators of compromise. Within one month of the incident notification you submit the final report, covering a detailed description of the incident, its severity and consequences, the type of threat or root cause, the mitigating measures applied and, where relevant, the cross-border impact.
If the incident is still ongoing when the month expires you submit a progress report instead, followed by the final report within one month of handling the incident. Two shorter deadlines sit alongside this scheme. Trust service providers report an incident affecting the provision of their trust services within 24 hours rather than 72. And where a significant incident affects the recipients of your service, you must inform those recipients without undue delay of the incident and, where the threat warrants it, of the measures or remedies they can take themselves.
Who receives your report
You file through the NCSC portal, and the notification is passed on from there to the CSIRT responsible for your sector and to the supervisor that oversees it. That single point of entry is a deliberate simplification: you do not have to work out the division of responsibilities under time pressure. Supervision itself remains sectoral. The Netherlands Authority for Digital Infrastructure (Rijksinspectie Digitale Infrastructuur, RDI) supervises digital infrastructure, digital providers and most of central government; the Human Environment and Transport Inspectorate (ILT) supervises the water authorities and parts of transport; health falls to the Health and Youth Care Inspectorate (IGJ); and the financial sector is supervised by De Nederlandsche Bank and the Netherlands Authority for the Financial Markets. Confirming which supervisor covers your sector, and recording its contact details in your incident plan, is a five-minute exercise that is impossible to do well at three in the morning.
Where other reporting duties overlap
A single incident rarely triggers a single duty. Where the incident involves personal data, the GDPR applies in parallel: a personal data breach must be notified to the Dutch Data Protection Authority within 72 hours of becoming aware of it unless it is unlikely to result in a risk to individuals, and the data subjects themselves must be informed where the risk to their rights and freedoms is high. That obligation is independent of the Cbw, runs to a different authority, and is assessed against a different threshold, and where the incident occurred at a processor the allocation of roles in the data processing agreement decides who notifies whom, as our guide to the General Data Protection Regulation sets out.
Financial entities are the main exception to the Cbw regime rather than an addition to it. The Digital Operational Resilience Act (DORA) contains its own rules on ICT risk management and on the reporting of major ICT-related incidents to the competent financial supervisor, and where those rules are at least equivalent, they displace the corresponding NIS2 obligations. A bank or an insurer therefore reports a major ICT incident to De Nederlandsche Bank or the Netherlands Authority for the Financial Markets under DORA, and registers its contractual arrangements with ICT third-party providers in the register of information that DORA requires; it does not duplicate that reporting under the Cbw. Providers of electronic communications networks and services have continuity notification duties of their own under the Telecommunications Act, and organisations designated as critical entities report disruptions under the Wwke. Mapping which of these applies to you, before an incident, is the single most useful preparatory step there is.
What happens if you report late or not at all
Supervisors under the Cbw have the ordinary administrative toolkit and then some. They can demand information, order an audit, give binding instructions, impose an order subject to a penalty payment (last onder dwangsom) and impose an administrative fine. NIS2 requires member states to make available maximum fines of at least ten million euros or two per cent of worldwide annual turnover for essential entities, whichever is higher, and at least seven million euros or 1.4 per cent for important entities; the Dutch maxima are laid down in the Cbw itself. For essential entities the directive also allows a supervisor, as a last resort, to suspend a certification or authorisation and to prohibit an individual from exercising management functions.
The exposure is not only administrative. An incident that becomes public knowledge is followed by questions from customers and contractual counterparties, and a late or incomplete report weakens the position of the organisation in any dispute that follows. Our note on the legal responsibilities of directors and companies explains where that exposure sits within the organisation.
Building a procedure that survives a real incident
Deadlines of 24 and 72 hours are only met by organisations that decided in advance who does what. A workable procedure names the person who assesses an incident against the reporting threshold, the person who approves the notification, the person who submits it and the person who keeps contact with the authority, with a named deputy for each role, because incidents do not respect office hours. The assessment step should sit within the first couple of hours of detection; the early warning has to be drafted, checked and filed well inside the first day.
Prepared templates make the difference between meeting the 24-hour deadline and missing it. An early warning template needs the time of detection, the category of incident, the systems affected, whether malicious activity is suspected and whether cross-border effects are possible, plus a named contact. The incident notification template adds the severity assessment, the scope of impact, the number of recipients affected, the indicators of compromise and the containment steps already taken. The final report template covers the timeline, the root cause, the full impact and the measures put in place. Keep these accessible offline as well; an incident that takes down your systems will also take down the wiki they are stored on. A short legal review of the draft is worth building into the workflow, and our IT lawyers are used to doing that within the hour.
The register of ICT third parties deserves separate attention. A large part of reportable incidents originates with a supplier, and the contractual obligation to inform you promptly, together with the right to the technical information you need for your own report, has to be in the cloud or supplier contract before the incident. That is a procurement question as much as a security question, and it belongs with the wider due diligence obligations that run through the supply chain.
Training and governance
Procedures that live in a document fail. Staff outside the security team need to recognise what a possible incident looks like, know whom to contact at any hour, and understand that they should not investigate on their own or delete anything. The security team needs to know the classification standard and the workflow well enough to apply them under pressure, which in practice means rehearsing them: a tabletop exercise that runs a realistic scenario from detection through to the final report exposes the gaps that a written procedure hides.
At board level the Cbw makes cybersecurity risk a standing item rather than an occasional one. The management body approves the risk-management measures and must be trained; it should receive a regular account of incidents, of reports filed and of the responses received from the authorities, and one named executive should own reporting compliance. Our regulatory compliance practice helps organisations put that governance in place and test it before a supervisor does.
What to do next
Three things decide whether an organisation meets its cybersecurity incident reporting duties: knowing whether it falls under the Cbw and is registered with the NCSC, having a written threshold for what counts as significant, and having a named person able to file an early warning within 24 hours at any hour of the day. Everything else follows from those three. Check the registration first, because it is the one obligation that is already overdue for organisations that have not attended to it, and it is the easiest for a supervisor to verify.
Law & More advises organisations on the scope of the Cybersecurity Act, on the drafting of incident-reporting procedures and supplier clauses, and on the handling of a report and the supervisory correspondence that follows it. Where an incident also involves personal data, a supply chain or a contractual dispute, we can take those strands together rather than in sequence. If you are unsure whether your organisation falls under the Act, that is the question to settle first, and we are glad to answer it.
