NIS2 is no longer a future obligation. It has been enforceable across the EU since October 2024, and national cybersecurity authorities are actively investigating. The gap most commonly found in ongoing inspections is not missing documentation — it is an incident response process that fails at the point it matters most: the first four hours after a significant incident is detected.
This article walks through what NIS2-compliant incident response actually requires, using a detailed hypothetical scenario to illustrate where each obligation activates and what a compliant organisation does at each step.
The NIS2 incident notification timeline
Article 23 of NIS2 establishes a three-stage reporting process for significant incidents:
- Early warning — within 24 hours of becoming aware of the incident. A brief notification to the national CSIRT or competent authority, indicating whether the incident is suspected to be caused by unlawful or malicious acts and whether it has or could have cross-border impact.
- Incident notification — within 72 hours of awareness. A fuller report including an initial assessment of the incident, its severity, indicators of compromise, and the measures taken or under consideration.
- Final report — within one month of submitting the incident notification. A detailed description of the incident including: nature of the cause (if established), the impact, and the mitigation measures applied or ongoing.
A "significant incident" is defined as one that has caused or is capable of causing severe operational disruption of the service or financial losses for the entity concerned, or affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
This definition is deliberately broad. Supervisory authorities have interpreted it to require erring on the side of reporting — if you are uncertain whether an incident is significant, you should notify and allow the authority to assess it, rather than holding off and missing the window.
The scenario: a logistics company on a Saturday night
Consider a hypothetical: Meridian Freight Services, a 120-person logistics coordination company based in Rotterdam. They operate IT systems that manage carrier booking, customs documentation, and supply chain tracking for 40 SME clients. They have 50 employees and €18 million in annual revenue, making them an "important entity" in the transport sector under NIS2.
At 23:47 on a Saturday, an automated monitoring alert fires: unusual outbound data volume from their core booking system server. The on-call IT administrator, working remotely, logs in to investigate. By 00:30 Sunday morning, the pattern is clear: ransomware has encrypted several directories on the server. The IT administrator calls the CTO.
Here is what NIS2 requires at each subsequent step — and where most organisations go wrong.
Hour 1–2: Awareness triggers the clock
The 24-hour early warning window begins from the moment the organisation became "aware" of a significant incident. Under NIS2, awareness does not mean certainty. It means awareness of a reasonable probability that a significant incident has occurred.
At 00:30, when the IT administrator identifies ransomware encryption of production systems, Meridian Freight Services is "aware" of a probable significant incident. The 24-hour early warning clock has started.
Where most organisations fail: They treat the initial detection as the start of an internal investigation, not as the start of a regulatory clock. They spend the next 18–20 hours diagnosing the full scope, assessing the business impact, and drafting an internal incident report — before anyone considers notifying the CSIRT. By the time the notification question is raised, the 24-hour window has already closed.
The NIS2 early warning is not a comprehensive report. It is an early alert. It can be filed with minimal information — "we have detected what appears to be a ransomware infection affecting our booking system; we are investigating and will provide a full notification within 72 hours." That is sufficient. The purpose of the early warning is to give national authorities visibility, not to provide a complete picture you do not yet have.
What Meridian should do by 00:30: Initiate the incident response playbook. One person's immediate job is to find and begin completing the national CSIRT notification form. In the Netherlands, this means the NCSC (National Cyber Security Centre) incident reporting portal. The early warning can be filed while the technical investigation continues in parallel.
Hour 2–24: Containment and the 24-hour notification
Simultaneously, the technical response proceeds:
- Isolate affected systems from the network to prevent lateral spread
- Preserve forensic evidence — do not wipe or reimaged systems until after forensic imaging
- Activate offline backups — verify backup integrity before attempting restoration
- Identify the entry point if possible: phishing email, unpatched vulnerability, compromised credential
- Assess the scope: which systems are encrypted, what data was accessible, whether any data was exfiltrated before encryption
By approximately 06:00 Sunday, Meridian has a clearer picture: the ransomware entered through a compromised VPN credential, encrypted three servers containing booking data and client documentation, and appears to have been present in the environment for approximately 36 hours before encryption was triggered. There is no evidence of data exfiltration, but the 36-hour dwell time means it cannot be ruled out.
The GDPR intersection: If personal data was or may have been exfiltrated — or if personal data was rendered unavailable (which encryption achieves) — a GDPR breach notification to the Dutch AP (Autoriteit Persoonsgegevens) is required within 72 hours under Article 33. Ransomware that encrypts personal data constitutes a personal data breach even without exfiltration, because it affects the availability of the data. Meridian's incident response must therefore run two parallel notification tracks: NIS2 to the NCSC and GDPR to the AP.
By Sunday evening, the early warning has been filed with the NCSC. The 24-hour window is met.
Hour 24–72: The full incident notification
The 72-hour incident notification requires more substance. By Tuesday morning (72 hours from awareness), Meridian must file a notification that includes:
- A description of the incident and its severity
- The services affected and the geographic scope
- The cause or suspected cause
- The indicators of compromise (IOCs) — hash values, IP addresses, malware signatures — to the extent they have been identified
- The mitigation measures taken and the status of service restoration
- An assessment of cross-border impact: do any of Meridian's 40 clients operate in other EU member states? If so, the incident may have cross-border implications.
By Tuesday morning, Meridian has restored services from clean backups. The entry point (the compromised VPN credential) has been closed. Password resets have been issued across all accounts. An external forensics firm has been engaged and has confirmed no evidence of exfiltration, though the investigation is ongoing.
The 72-hour notification is filed with the NCSC. The GDPR breach notification is filed with the AP, noting that availability of personal data was affected but there is no current evidence of exfiltration.
Days 3–30: The final report
Within one month of the incident notification, Meridian must submit a final report to the NCSC. This is the most substantive document in the process and must include:
- A detailed description of the incident including confirmed cause (the compromised VPN credential obtained through credential stuffing against an exposed admin portal)
- The measures taken to address the root cause (MFA implemented on all VPN access, the admin portal moved behind additional access controls, the relevant entry point patched)
- The full business impact: duration of service disruption, clients affected, financial losses if applicable
- The post-incident review findings and any changes to security measures or procedures resulting from the incident
- The current status of the forensic investigation and any changes to the earlier assessment of data exfiltration
The forensic investigation completed by day 18 confirms no data exfiltration. The final report reflects this update.
The GDPR AP notification is updated with the same conclusion — under Article 34, Meridian must now assess whether the individuals whose data was affected (client contacts, employees) must be individually notified. Given no exfiltration occurred and services were restored within 36 hours, Meridian documents its assessment that individual notification is not required, and retains this documentation.
What was the key differentiator?
The element that made this hypothetical response compliant was not forensic speed or technical capability. It was the existence of a pre-built incident response playbook that:
- Defined "significant incident" with concrete examples relevant to Meridian's operations, so the on-call IT administrator could make an immediate assessment without legal consultation at midnight
- Named the national CSIRT contact point and included the reporting portal URL
- Assigned specific people to specific tasks in the first 24 hours — including one person responsible for regulatory notifications
- Included parallel tracks for NIS2 and GDPR notifications, because most significant IT incidents at Meridian's scale involve personal data
- Had a clear escalation chain that went from IT administrator to CTO to board-level awareness within two hours of a confirmed significant incident
Without that playbook, the response at most organisations goes: detect → investigate → escalate → draft internal report → realise there is a regulatory notification requirement → try to find the relevant contact → discover nobody knows who to notify → miss the 24-hour window.
The management liability dimension
NIS2 Article 20 makes this explicit: the management body of an essential or important entity is personally accountable for cybersecurity risk management and incident response. When the NCSC or another national competent authority investigates an incident and finds the 24-hour notification was missed, the question they will ask is: did management approve and implement an adequate incident response procedure?
If the answer is no — if there was no playbook, no trained designated person, no tested escalation chain — the management body's personal liability under Article 20 is directly engaged. In serious cases, national authorities can temporarily prohibit individuals from holding management functions under Article 32(6).
This is not a theoretical risk. Several national authorities have already indicated they intend to use this provision in cases of serious procedural non-compliance.
Supply chain notification obligations
One element of NIS2 incident response that catches organisations off-guard: you may have obligations to notify not just regulators but also affected parties in your supply chain. Article 21(2)(d) requires supply chain security measures that cover your relationships with direct suppliers and service providers.
In Meridian's case, their clients rely on Meridian's booking platform for their own operations. When a significant incident affects service availability, those clients may have NIS2 or DORA obligations of their own that are triggered by the disruption. Meridian's incident response plan should include a client notification protocol — both as a contractual obligation and as a practical component of the supply chain security requirements.
NIS2 incident response compliance is ultimately a preparedness problem, not a response-speed problem. The 24-hour early warning window is achievable if the playbook exists before the incident. It is not achievable if the playbook has to be written after the alarms fire. For any organisation within NIS2 scope, the most valuable compliance investment is an incident response procedure that has been reviewed by management, tested in a tabletop exercise, and assigned to named individuals — before the incident that activates it.
Frequently Asked Questions
What counts as a "significant incident" under NIS2 — does every IT outage trigger reporting?
No. The definition of a significant incident requires either: severe operational disruption of the service, or financial losses for the entity, or the capability to considerably harm other persons. A brief IT outage with no service impact on customers and no financial loss is not a significant incident. The practical threshold is: would a reasonable observer looking at the full facts conclude this incident caused or could cause severe disruption or harm? Ransomware encryption of production systems meets this threshold. A single workstation infected with malware that is isolated immediately and causes no service disruption typically does not. When in doubt, err on the side of early warning notification — it can always be withdrawn or clarified, but a missed 24-hour window cannot be remedied retrospectively.
Do we need to notify even if we have resolved the incident within 24 hours?
Yes, if it was a significant incident. The notification obligation is triggered by awareness of the incident, not by its duration or whether it has been resolved. A significant incident that is contained in six hours still requires an early warning notification within 24 hours and a full incident notification within 72 hours. The fact that it was quickly resolved may affect the content of the notifications and the authority's response to them, but it does not remove the notification obligation.
Where do we submit NIS2 incident notifications — is there a single EU portal?
No. NIS2 is a directive, implemented through national law by each EU member state. Notifications are submitted to the national CSIRT or competent authority in each member state where you operate. In the Netherlands, this is the NCSC. In Germany, this is the BSI. In Belgium, this is the CCB. For cross-border incidents affecting operations in multiple member states, you notify in each relevant jurisdiction and the national authorities coordinate among themselves. One of the most common preparedness gaps is organisations not knowing which authority to notify, or not having the national reporting portal URL readily accessible during an incident.
Is there a difference between NIS2 incident notification and GDPR breach notification?
Yes — they are separate obligations with separate authorities and different timelines. GDPR Article 33 requires notification to the supervisory data protection authority within 72 hours of becoming aware of a personal data breach. NIS2 Article 23 requires notification to the national CSIRT within 24 hours of becoming aware of a significant incident (with a further notification at 72 hours). These obligations frequently apply to the same incident — a ransomware attack on systems containing personal data triggers both. You should maintain parallel notification tracks: NIS2 to the CSIRT, GDPR to the DPA. The same incident description can be adapted for both notifications, but they go to different authorities and the NIS2 early warning has a tighter initial deadline.
What should a NIS2 incident response playbook contain at minimum?
At minimum: (1) a definition of "significant incident" with examples relevant to your specific operations; (2) a clear escalation chain with named individuals and contact numbers, including out-of-hours contacts; (3) the contact details and notification portal URLs for the national CSIRT(s) in each jurisdiction you operate in; (4) a parallel track for GDPR notifications to the relevant DPA if personal data may be involved; (5) a list of the steps required to file the 24-hour early warning — this should take under 15 minutes once the decision to notify is made; (6) a log template for capturing incident timeline information in a format that supports the subsequent 72-hour and 30-day reports; (7) evidence that management has approved the playbook — this satisfies part of the Article 20 management accountability requirement. The playbook should be tested in an annual tabletop exercise, with the exercise documented and any gaps remediated.