Why This Guide Exists

When a significant cyber incident hits your organization, NIS2 gives you 24 hours to file an early warning with your national CSIRT. Twenty-four hours from the moment you become aware — not business hours, not "when practicable."

For organizations subject to the Dutch Cyberbeveiligingswet (Cbw), that means reporting to NCSC-NL. The clock starts the moment your team recognizes the incident meets the significance threshold.

This guide covers what qualifies as a significant incident, what the early warning needs to contain, how to actually file it with NCSC-NL, and what happens after you hit submit. It's written for the person who will be responsible when the call comes in at 2 AM.

The Reporting Timeline

NIS2 Article 23 sets up a three-stage reporting obligation. The early warning is stage one — and the one with the tightest deadline.

Stage 1 — Early Warning: Within 24 hours A short, structured alert to your national CSIRT (NCSC-NL in the Netherlands) that a significant incident has occurred. This is not a full investigation report. Think of it as raising your hand.

Stage 2 — Incident Notification: Within 72 hours An updated assessment with initial findings, severity, impact, and indicators of compromise where available. This builds on the early warning with whatever your team has learned since.

Stage 3 — Final Report: Within one month The detailed report: root cause analysis, mitigation measures, cross-border impact. If you're still actively remediating at the one-month mark, the supervisory authority may grant an extension — but you'll need to file a progress report in the meantime.

One wrinkle worth noting: if the incident is still ongoing at 72 hours, you're expected to provide a progress report at that point, with the final report due within one month of resolution.

If you suspect the incident was caused by a malicious or unlawful act, flag that in the 24-hour early warning. NCSC-NL uses this to coordinate cross-border and law enforcement response, and the earlier they know, the more effective that coordination is.

What Counts as a "Significant Incident"

Not every security event triggers a reporting obligation. The directive sets two core criteria — your incident is significant if it meets either one:

Criterion 1: Serious operational disruption The incident has caused or is capable of causing severe disruption to the services you provide, or significant financial loss to your organization.

Criterion 2: Impact on others The incident has caused or is capable of causing considerable material or non-material damage to other natural or legal persons.

That phrase "capable of causing" is important. It's interpreted broadly. A ransomware attack that encrypted your production database is reportable even if customer-facing services are still running — because the capability for disruption is clearly there.

Concrete thresholds for digital service providers

The European Commission's Implementing Regulation (EU) 2024/2690 sets specific numbers for digital infrastructure and service providers (DNS, cloud, data centres, managed service providers, trust services, and similar):

Direct financial loss exceeding €500,000 (or 5% of annual turnover, whichever is lower)
Service unavailability exceeding 30 minutes for affected users
Successful, suspectedly malicious, unauthorized access to network and information systems
Death or considerable damage to someone's health

For everyone else — energy, transport, healthcare, water, manufacturing — the Dutch Cyberbeveiligingswet will define sector-appropriate thresholds. Until those are finalized, the two core criteria from Article 23(3) are your guide.

When you're on the fence

In practice, the significance decision usually comes down to a few questions:

Has any external service been degraded or interrupted? That's almost certainly reportable.

Has personal data or a trade secret been accessed or exfiltrated? Report it.

Could the financial impact exceed €500,000? Report it.

Was the cause suspected to be malicious? Flag it in the early warning, even if you're not sure yet.

Is this part of a recurring pattern? The individual incidents might not hit the threshold, but the pattern itself may be reportable.

Here's the thing — NIS2 doesn't penalize you for over-reporting. Filing an early warning that turns out to be less severe than you initially thought is perfectly fine. Missing the 24-hour window because your team spent too long debating whether the incident was "significant enough" is not. When in doubt, report.

What the Early Warning Must Contain

Less than you'd think. The 24-hour early warning is intentionally lightweight — the directive's authors understood you won't have answers yet. Article 23(4)(a) requires just two things:

Whether the incident is suspected to have been caused by unlawful or malicious acts (yes/no/unknown)
Whether the incident could have cross-border impact (yes/no/unknown)

That's the legal minimum. In practice, NCSC-NL's reporting form asks for more context — your organization name and sector, contact details for the incident response lead, a brief description of what happened and when, current status, affected services, and a preliminary impact assessment. All of this helps them respond effectively, but none of it needs to be perfect or complete at this stage.

What you explicitly do not need: root cause analysis, detailed technical indicators, forensic timelines, or a full impact assessment. That's what the 72-hour notification and the final report are for.

An example that works

A complete early warning can be a single paragraph:

On [date] at [time] CET, [Organization] detected unauthorized access to our [system/service]. The incident was identified through [detection method]. We have activated our incident response procedure. The incident is currently [ongoing/contained]. We suspect the cause is [malicious/accidental/unknown]. We are assessing potential cross-border impact; preliminary indication is [yes/no/unknown]. Our incident response lead is [name, email, phone].

Fill in the blanks, submit, and get back to containment. You'll have 72 hours to provide deeper analysis.

How to File with NCSC-NL

The reporting portal

In the Netherlands, incident reports under the Cyberbeveiligingswet go through the NCSC-NL portal at mijn.ncsc.nl.

You'll need eHerkenning (the Dutch government's digital business identity system) at assurance level 3 or higher to access it. If your organization doesn't have eHerkenning credentials yet, this is the single most important thing you can do today to prepare. Registration takes several business days. You do not want to be figuring this out during a live incident.

Getting ready before anything happens

Five things to do now, while nothing is on fire:

1. Register at mijn.ncsc.nl. Log in with your eHerkenning credentials. Click around. Make sure it works. This takes ten minutes and could save you an hour of panic later.

2. Know your sectoral supervisor. Your primary regulatory contact depends on your sector:

Telecom and digital services: Agentschap Telecom (AT)
Healthcare: Inspectie Gezondheidszorg en Jeugd (IGJ)
Transport and water: Inspectie Leefomgeving en Transport (ILT)
Energy: Rijksdienst voor Digitale Infrastructuur (RDI)
Other sectors: NCSC-NL acts as the central CSIRT

3. Pre-draft your organizational details. Organization name, KvK number, sector classification, primary services, eHerkenning account holder, 24/7 incident contact. Put these in your incident response playbook so nobody is looking them up under pressure.

4. Separate reporting from response. The person filing the early warning should not be the same person leading technical containment. Your best incident responder needs to focus on stopping the bleeding, not filling out forms.

5. Do a dry run. NCSC-NL accepts voluntary incident reports. You can walk through the portal and the form structure without a real incident. Think of it as a fire drill for your reporting process.

When an incident hits

Once your team determines an incident meets the significance threshold:

Hour 0–1: Confirm it meets at least one significance criterion. Assign someone specific to handle reporting. Start drafting the early warning while containment proceeds in parallel.

Hour 1–4: Log into mijn.ncsc.nl, complete the form with what you know, mark anything uncertain as "under investigation" (this is expected and fine), submit, and save your confirmation number.

Hour 4–24: Document everything. Start collecting what you'll need for the 72-hour notification. If the situation escalates significantly, file an updated early warning.

If you can't reach the portal

If mijn.ncsc.nl is down — or if your incident has knocked out your internet access — NCSC-NL has fallback channels:

Email: cert@ncsc.nl
Phone: +31 70 751 55 55 (24/7 for significant incidents)

Document that you tried the portal first and used the alternative. The obligation is to notify within 24 hours. How you notify is secondary.

After You File

What NCSC-NL does with your report

They'll acknowledge receipt, usually within hours. From there, they assess cross-border implications, coordinate with other member states' CSIRTs if needed, notify ENISA where required, and may offer guidance or technical assistance. If your incident is part of a broader campaign, they may share anonymized threat intelligence.

One thing they won't do: publish your organization's name or incident details. Reports are treated as confidential.

What you owe next

72 hours after detection: File the incident notification — an updated assessment with initial findings on nature, severity, indicators of compromise, and impact on services and data.

One month after detection: Submit the final report with root cause analysis, what you did to remediate, and lessons learned. If you're still actively responding, file a progress report and submit the final report within one month of resolution.

Don't forget GDPR. If personal data was involved, you likely owe a separate notification to the Autoriteit Persoonsgegevens (AP) within 72 hours under GDPR Article 33. NIS2 and GDPR are separate regimes, separate authorities, separate filings. Track them independently or things will fall through the cracks.

Mistakes That Will Cost You

Waiting too long to report. This is the big one. Teams burn hours debating whether an incident is "really" significant while the 24-hour clock runs down. The early warning accommodates uncertainty by design — "we detected anomalous activity, investigation ongoing" is a valid report. Spending 22 hours confirming the exact attack vector before filing is not.

Mixing up NIS2 and GDPR timelines. A single incident can trigger both. They have different deadlines, different authorities, and different content requirements. If your IR plan treats them as one reporting obligation, you're going to miss something.

Discovering you need eHerkenning during an active incident. It takes days to set up. Every organization in NIS2 scope should have this ready now. This is the most avoidable failure on this list.

Making your best technical person do the paperwork. Your senior incident responder should be focused on containment and forensics, not navigating a government portal. Give reporting to someone else — your compliance officer, a trained delegate, anyone who can write clearly and follow a form.

Filing the early warning and forgetting the follow-up. The 72-hour notification deadline starts from the same moment as the 24-hour one. Calendar it the second you submit the early warning, or it will sneak up on you in the middle of an active response.

Pre-Incident Checklist

Print this out. Put it in your incident response binder. Review it quarterly.

[ ] eHerkenning credentials are active and tested at mijn.ncsc.nl
[ ] Sectoral supervisor identified and contact details documented
[ ] Incident response plan includes NIS2 reporting steps and role assignments
[ ] Significance assessment criteria are documented and accessible to the IR team
[ ] Reporting officer is assigned (separate from technical IR lead)
[ ] Template early warning text is pre-drafted with organizational details
[ ] Parallel GDPR notification process is documented for data breach scenarios
[ ] 72-hour and one-month follow-up deadlines are built into IR procedures
[ ] IR team has been trained on the reporting portal and timeline obligations
[ ] Alternative reporting channels (email, phone) are documented for portal outages

How Docket Helps

I built Docket's incident response engine around the Article 23 timeline because I've seen the same problem across other regulatory landscapes: teams often understand their regulatory obligations in theory but don't have the tooling to execute under pressure.

When you create an incident in Docket, a reportability decision tree walks your team through the significance assessment — structured questions mapped to the NIS2 criteria that produce a documented rationale your auditors can actually review. The 24-hour countdown starts automatically, with alerts at key intervals so nobody loses track of the deadline.

Every piece of evidence is timestamped and integrity-verified with SHA-256 hashing and RFC 3161 timestamps. Notification templates pre-populate the early warning, 72-hour notification, and final report so your team isn't drafting from a blank page at 3 AM. And every action — who did what, when, why — is captured in a tamper-proof audit trail.

When the regulator asks "show me how you handled this," you hand them a complete, verified evidence pack. Not a folder of emails and screenshots.

Book a demo: dockethq.app

This guide reflects NIS2 Directive 2022/2555 Article 23 requirements. Significant incident thresholds for digital service providers are specified in Commission Implementing Regulation (EU) 2024/2690; thresholds for other sectors will be defined in national transposition laws. For the Netherlands, reporting obligations take effect upon entry into force of the Cyberbeveiligingswet (Cbw). This guide is provided for informational purposes and does not constitute legal advice. Consult your legal counsel for organization-specific compliance guidance.

Published by Docket — The NIS2 Incident & Evidence Platform dockethq.app | patrick@dockethq.app