Incident Reporting and Communication Duties

1. Where Incident Reporting Fits in NIS2

NIS2 (Directive (EU) 2022/2555) significantly tightens incident reporting and communication duties compared with the original NIS Directive.

As of today (late 2025):

• NIS2 had to be transposed by Member States by 17 October 2024 (Art. 41), but national implementation is uneven.
• The core incident reporting model (timelines, thresholds, CSIRTs, single points of contact) is, however, harmonised in the Directive and already used as a reference by regulators, ENISA, and large organisations.

This module assumes you already know:

• Which entities are essential vs important under NIS2
• The basic risk-management measures NIS2 requires (previous module)

Now we focus on Articles 3, 6, 7, 23–24 and related recitals:

• What counts as a reportable incident (significant vs substantial)
• Exact notification stages and deadlines
• How to coordinate with CSIRTs and competent authorities
• How to design internal escalation and communication workflows

Keep in mind:

• National laws may adjust channels, forms, and who receives what, but they cannot relax the minimum NIS2 timelines or thresholds.
• For exam or professional purposes, always separate: “What NIS2 requires at EU level” vs “How country X implements it procedurally.”

2. Key Definitions: Incidents, Significant, and Substantial

NIS2 uses several layered concepts. You must be able to distinguish them precisely.

2.1 Basic terms (Art. 6)

• Incident: any event compromising availability, authenticity, integrity, or confidentiality of data or services provided by a covered entity.
• Security of network and information systems: ability of systems to resist actions that compromise the above properties.

2.2 Significant incident (triggers reporting duties)

NIS2 uses the notion of “incident having a significant impact”. The Directive does not fix a single numeric threshold; instead, it sets criteria that Member States must operationalise (often via guidance or secondary legislation):

Typical criteria (from NIS2 and national drafts):

1. Number of users affected or service coverage (e.g., % of national population, number of customers)
2. Duration of the incident (e.g., hours vs days)
3. Geographical spread (local, regional, national, cross-border)
4. Severity of disruption to services (e.g., complete outage vs degraded performance)
5. Impact on economic and societal activities, public safety, or public security

Important: A significant incident does not have to be malicious. Major outages due to misconfiguration or hardware failure can be reportable.

2.3 Substantial incident

The term “substantial incident” is used in some Member State drafts/guidance and in ENISA materials to indicate a higher severity tier (e.g., incidents that may trigger cross-border coordination, public communication, or EU-level situational awareness).

In practice (late 2025 practice):

• All substantial incidents are significant, but not all significant incidents are substantial.
• Substantial often means highest severity according to a national or sectoral scale (e.g., 3 or 4 on a 4‑level scale).

2.4 Cyber threat vs incident

• Cyber threat: a potential cause of an incident (e.g., detected exploitation attempt, malware beaconing, credible ransomware threat).
• NIS2 requires early warning even for certain cyber threats that are likely to lead to a significant incident.

For workflow design, you should implement internal severity levels and map them to significant/substantial as defined by your national authority.

3. NIS2 Incident Notification Stages and Timelines

NIS2 standardises a multi‑stage reporting model. You must know the sequence and time limits.

> Note: Exact wording appears in Art. 23 (reporting obligations). National laws may add details, but cannot loosen these minimum deadlines.

3.1 Overview of stages

For significant incidents (and certain imminent threats), NIS2 foresees:

1. Early warning – within 24 hours of becoming aware
2. Incident notification – within 72 hours of becoming aware
3. Intermediate updates – on request or when new information arises
4. Final report – within 1 month of the incident notification (or resolution)

3.2 The 24‑hour Early Warning

Trigger:

• You become aware of an incident or cyber threat that may lead to a significant incident and which is ongoing or likely to occur soon.

Content (high-level):

• Indication whether the incident is suspected to be caused by unlawful or malicious acts
• Whether it may have a cross-border impact
• Any early indicators of compromise (if available)

Purpose: enable rapid situational awareness for CSIRTs and competent authorities, even before all facts are known.

3.3 The 72‑hour Incident Notification

Trigger:

• You confirm or reasonably suspect that an incident has had a significant impact.

Deadline:

• No later than 72 hours after becoming aware of the significant impact.

Content (more detailed):

• Initial impact assessment (users, services, geography, criticality)
• Root cause hypothesis (if known)
• Mitigation measures already taken
• Any known or suspected cross‑border effects

This stage is roughly analogous to the 72‑hour personal data breach notification under GDPR, but it is broader (covers service disruption and security, not just personal data).

3.4 Final report (within 1 month)

Trigger:

• Follows the incident notification; due when you have a consolidated post‑incident view.

Deadline:

• Within 1 month of the incident notification, or of incident resolution if resolution took longer.

Content (comprehensive):

• Detailed root cause analysis
• Full timeline of events and detection
• Technical and organisational measures taken to respond and recover
• Lessons learned and planned long‑term improvements
• Assessment of cross‑border and sectoral impacts

3.5 Edge case: Evolving awareness

If you first think an event is minor but later realise it is significant:

• The 24h and 72h clocks start when you become aware that the impact is significant, not when the first anomaly occurred.
• However, regulators expect reasonable diligence; long unjustified delays in recognising significance can be criticised in supervision.

4. Worked Example: Applying the Timelines

Consider a regional energy provider classified as an essential entity.

#### Timeline example

• Day 1 – 09:00: Monitoring detects abnormal traffic to SCADA gateways. Short, intermittent slowdowns, but no outage yet.
• Internal SOC labels this as Severity 2 (medium). Investigation starts.

• Day 1 – 14:00: Investigation reveals active exploitation of a zero-day in a remote access appliance. Attackers have limited foothold but no service disruption yet.
• SOC escalates to CISO and Incident Response Team (IRT).
• The IRT concludes there is a credible cyber threat likely to cause a significant incident if not contained.

• Day 1 – 15:00: Decision: this meets the NIS2 early warning condition.
• By 15:00 + 24h (Day 2 – 15:00), the entity must send an early warning to the national CSIRT or single point of contact.
• The early warning will state: suspected malicious attack, possible cross‑border impact (interconnected grids), and ongoing investigation.

• Day 2 – 22:00: Attackers trigger ransomware, causing a 6‑hour blackout in part of the region. Thousands of customers lose power.
• This clearly qualifies as a significant incident (large user base, critical service, regional impact).
• The entity is now “aware of a significant impact”.

• By Day 5 – 22:00 (72 hours later):
• The entity must submit the incident notification with initial impact estimates, suspected root cause (zero‑day exploited via remote access), and mitigations (isolation, manual switching, restoration steps).

• Day 20: Systems are fully restored; forensics complete.
• The entity prepares a final report: detailed attack path, detection gaps, how segmentation and backups helped, and planned improvements.
• By Day 35 (1 month after the incident notification), the final report is due.

#### Reflection questions

• At what exact moment did the 24‑hour clock start? When the credible threat was identified (Day 1 – 14:00/15:00), not at first anomaly.
• At what moment did the 72‑hour clock start? When the entity became aware of a significant impact (Day 2 – 22:00), not when exploitation was first suspected.

This example shows why you need formal internal criteria for:

• When a threat becomes reportable
• When an incident crosses from “operational issue” to significant incident under NIS2.

5. Who You Talk To: CSIRTs, Competent Authorities, Single Points of Contact

NIS2 clarifies institutional roles (Arts. 8–12). Internally, you must know who receives which notification.

5.1 CSIRTs (Computer Security Incident Response Teams)

• Provide technical assistance, early warnings, and rapid response support.
• Under NIS2, they may receive early warnings and incident notifications directly or via a single point of contact.
• They often maintain 24/7 channels and structured incident formats (e.g., ENISA templates).

5.2 Competent authorities

• Sectoral or cross‑sector regulators responsible for supervision and enforcement of NIS2.
• They use your reports to:
• Assess compliance with risk-management and reporting obligations
• Decide on inspections, corrective measures, or sanctions
• Coordinate with other national/EU bodies

5.3 Single point of contact (SPOC)

• A national body designated to coordinate cross‑border NIS2 issues and liaise with the EU.
• In some Member States, the SPOC also acts as the central portal where you submit all NIS2 notifications, which are then forwarded to CSIRTs and competent authorities.

5.4 Practical variations across Member States (late 2025)

Although NIS2 is harmonised, national practice differs:

• Some countries:
• One portal → automatically sends reports to CSIRT + regulator
• Others:
• Separate channels: CSIRT for technical reporting, regulator for compliance

For designing workflows, assume the strictest case:

• You must be ready to notify both CSIRT and competent authority, possibly with slightly different content (technical vs regulatory focus).

5.5 Confidentiality and liability

• NIS2 encourages reporting by protecting confidentiality of sensitive information and limiting the use of reports for purely punitive purposes.
• However, false or grossly incomplete reporting can still lead to supervisory measures.

You should explicitly map, for your chosen Member State:

• Which entity you notify
• Which format (portal, encrypted email, structured form)
• Which language and which time zone the deadlines refer to.

6. Design an Internal Escalation Path (Thought Exercise)

You are the Information Security Officer of a large cloud service provider classified as an important entity under NIS2.

Your task: sketch an internal escalation and communication workflow that ensures you can meet the 24h / 72h / 1‑month obligations.

Work through these prompts (write answers separately):

1. Detection to triage

• Which teams or tools can first detect potential incidents? (e.g., SOC, helpdesk, monitoring tools)
• How quickly must they triage and assign a provisional severity level?

1. Severity mapping

• Define at least 4 internal severity levels (e.g., Sev1–Sev4).
• For each level, specify when it should be considered a candidate for NIS2 significant incident.
• Decide: at which level do you trigger a NIS2 early warning?

1. Decision authority

• Who has the authority to decide: “This is a reportable NIS2 incident”? (e.g., CISO, NIS2 compliance officer, incident commander)
• What is the maximum time allowed between initial detection and this decision?

1. Communication matrix

• For a Sev1 / significant incident, list:
• Which internal stakeholders are informed (CEO, legal, PR, data protection officer, operations)?
• Which external stakeholders (CSIRT, competent authority, key customers, partners)?
• Who is responsible for drafting each communication?

1. Documentation and evidence

• How do you ensure that timestamps, decisions, and rationales are logged (for later audits by competent authorities)?
• Which system or tool acts as the single source of truth for the incident timeline?

1. Integration with GDPR and other regimes

• If the incident also involves a personal data breach, how will you coordinate NIS2 and GDPR notifications to avoid contradictions or duplication?

When you are done, compare your workflow with:

• The NIS2 timelines and definitions from previous steps
• Typical ISO 27035 / NIST incident response phases

Identify at least two bottlenecks where you might miss the 24h or 72h deadlines, and propose mitigations (e.g., on‑call decision‑makers, pre‑approved templates, playbooks).

7. Check Understanding: Thresholds and Timelines

Answer the question based on NIS2’s general rules (ignoring any stricter national variations).

8. Pseudocode: Automating NIS2 Reporting Triggers

Below is language‑agnostic pseudocode to illustrate how an organisation could embed NIS2 logic into its incident management system. This is not production code, but a conceptual model.

9. Check Understanding: Coordination with Authorities

Test your understanding of who receives what and when.

10. Flashcard Review: Core Concepts

Use these cards to consolidate the key terms and mechanisms of NIS2 incident reporting and communication.