NIS2 Incident Reporting: The 24-Hour Early Warning Explained

NIS2 imposes a three-stage notification timeline on essential and important entities across the EU. The first stage — an early warning to the national CSIRT or competent authority within 24 hours — is where most compliance teams are getting it wrong. The clock starts ticking not when the incident occurred, but from the moment the organisation became aware of it. That distinction is not a technicality: it determines whether your entity faces a supervisory investigation and fines of up to €10 million or 2% of global turnover.

The three-stage reporting obligation under Art. 23 NIS2

NIS2 establishes a sequential reporting structure that builds in detail as the incident response matures. The three stages are not optional — all three must be completed for any incident that qualifies as significant. Missing any stage, or submitting substantially incomplete information, constitutes a separate compliance failure.

The most common misinterpretations of the NIS2 notification timeline

Across engagements with essential and important entities, four misunderstandings surface repeatedly during tabletop exercises and gap assessments.

1. “The clock starts when the incident happens.” It does not. Art. 23(1) NIS2 uses the phrase “without undue delay, and in any event within 24 hours of becoming aware.” ENISA guidance (Dec 2024) confirms that awareness means the moment the entity's internal processes — its SOC, helpdesk, monitoring tools, or third-party notification — first recorded or received credible information indicating a significant incident may have occurred. An entity that detects an incident on Day 3 but whose logs show monitoring alerts on Day 1 will be treated as having been aware from Day 1.

2. “We need the full root cause before notifying.” Art. 23 explicitly states that the early warning does not require a definitive analysis. Withholding notification pending internal investigation is not legitimate and is specifically flagged in ENISA guidance as a compliance failure risk. The 24-hour report is intentionally preliminary.

3. “Only cyberattacks trigger the obligation.” NIS2 covers any incident causing significant disruption, regardless of cause. A prolonged power outage affecting a critical infrastructure operator, a misconfiguration that brings down a core service for thousands of users, or a third-party supplier failure — all can qualify as significant incidents under Art. 23(3). ENISA guidance references operational disruption and financial loss as qualifying criteria independently of malicious intent.

4. “72 hours is the main deadline.” The 72-hour intermediate notification is better known because it mirrors the GDPR personal data breach notification window. But for NIS2, the 24-hour early warning is the first — and most frequently missed — deadline. Supervisors treat the early warning as an indicator of an entity's incident management maturity.

NIS2 vs NIS1: how reporting obligations changed

How IgeraRegTech supports NIS2 incident reporting compliance

When a security incident occurs, compliance teams face competing demands: contain the breach, communicate internally, manage operational continuity, and simultaneously track regulatory notification deadlines across potentially several frameworks (NIS2, GDPR Art. 33, sector-specific regulations). IgeraRegTech is built for precisely this situation.

What your internal incident SOP must cover to meet Art. 23

ENISA's December 2024 guidance is explicit that supervisors will ask to see documented internal procedures during inspections. A NIS2-compliant incident response SOP must cover at minimum:

• Awareness trigger definition: a clear internal definition of what constitutes the moment of “awareness” — typically when a named role (SOC lead, CISO, on-call security officer) formally classifies an event as a potential significant incident in the incident management system with a timestamped record.
• Significance threshold assessment: a documented decision tree or scoring matrix mapped against the Art. 23(3) criteria (operational disruption, financial loss, cross-border impact, number of affected users) that allows a classification decision within 2–4 hours of initial detection.
• Notification routing: who drafts the Art. 23 early warning, who approves it, and the technical channel to the national CSIRT or competent authority (most Member States now use dedicated secure notification portals).
• 24-hour and 72-hour deadline tracking: automated reminders from the moment the awareness timestamp is logged, escalating to senior management if the draft notification has not been approved by hour 20.
• Management body notification: Art. 20 NIS2 places personal accountability on management body members. Your SOP should specify when and how the CISO briefs the CEO and board — typically at or before the early warning submission.

Frequently asked questions about NIS2 incident reporting

Does the 24-hour early warning apply to both essential and important entities?

Yes. Art. 23(1) NIS2 applies the same three-stage notification timeline — 24-hour early warning, 72-hour intermediate notification, 1-month final report — to both essential entities and important entities. The distinction between the two categories affects the level of supervisory scrutiny and the maximum fine (€10M / 2% turnover for essential; €7M / 1.4% turnover for important), but not the reporting timeline itself.

What exactly counts as the moment of awareness that starts the 24-hour clock?

ENISA's December 2024 implementation guidance states that awareness arises when the entity's responsible personnel — through its monitoring systems, incident management procedures, or third-party notification — first received or should have received credible information sufficient to form a reasonable belief that a significant incident may have occurred. If your monitoring tools generated alerts indicating a potential significant incident, supervisors may regard awareness as having arisen at that point, regardless of whether a human reviewed those alerts immediately. This is why timestamped, documented alert triage is essential.

What information must the NIS2 24-hour early warning actually contain?

Art. 23(4)(a) NIS2 specifies that the early warning must at minimum include: (1) an indication that a significant incident has occurred, (2) where applicable, whether the entity suspects the incident resulted from unlawful or malicious acts, and (3) whether the incident is expected to have cross-border impact. The early warning does not require a root cause analysis, a full impact assessment, or a list of affected systems — those belong in the 72-hour intermediate notification and the final report. Attempting to delay the early warning until all this information is available is a compliance error.

Can we submit all three notifications at once if we have the full information within 24 hours?

Yes, in principle. Art. 23(1) NIS2 does not prevent an entity from submitting a more complete notification within the 24-hour window provided it meets the minimum content requirements of each stage. In practice, very few significant incidents are sufficiently contained and understood within 24 hours for a combined submission to be meaningful. ENISA guidance notes that submitting a combined report is permitted but entities should not use this as a reason to delay the early warning while gathering additional information.

What is the UK equivalent obligation under NIS Regulations 2018?

UK entities remain subject to the Network and Information Systems (NIS) Regulations 2018, which implemented NIS1 and were retained post-Brexit. Under UK NIS, Operators of Essential Services must notify their relevant competent authority (NCSC, Ofcom, FCA, Environment Agency, or relevant sector regulator) of incidents having a significant impact on continuity. The reporting deadline is “without undue delay” — the UK did not formally adopt NIS2's explicit 24-hour early warning stage. The UK Cyber Security and Resilience Bill (2025) is expected to align UK requirements more closely with NIS2. UK entities operating in the EU must comply with NIS2 for their EU operations regardless of UK domestic law.

Does a ransomware attack automatically trigger the NIS2 reporting obligation?

Not automatically — classification still depends on whether the attack constitutes a significant incident under Art. 23(3). A ransomware attack that encrypts systems used to deliver an essential service and causes operational disruption will almost certainly qualify. A ransomware attempt blocked at the perimeter with no operational impact is less likely to qualify, though entities should document their classification reasoning. ENISA guidance explicitly lists ransomware as one of the most common incident types triggering NIS2 notification and recommends that entities include ransomware response playbooks in their incident classification SOPs.

How does NIS2 reporting interact with GDPR Art. 33 personal data breach notification?

The two obligations run in parallel but are independent. GDPR Art. 33 requires notification to the supervisory authority (data protection authority) within 72 hours of becoming aware of a personal data breach. NIS2 Art. 23 requires notification to the national CSIRT or competent authority within 24 hours of becoming aware of a significant incident. A single cyber incident — for example, a data exfiltration attack on a hospital — may trigger both obligations simultaneously but to different authorities and with different deadlines. Art. 23(7) NIS2 specifically addresses this: if a NIS2-significant incident also constitutes a GDPR personal data breach, the entity must notify under both frameworks. ENISA guidance recommends that incident response procedures explicitly map the dual notification paths and nominate separate DPO and CISO leads for each notification stream.