NIS2 Incident Reporting: Identity Breach Obligations

NIS2's Incident Reporting Timeline

Article 23 of NIS2 sets out the reporting obligations for significant incidents. The structure is a three-stage process with specific timeframes measured from the moment the organisation becomes aware of the incident — not from when the incident began.

Stage 1: Early Warning — within 24 hours

The covered entity must submit an early warning to the relevant national competent authority or CSIRT within 24 hours of becoming aware of the significant incident. The early warning must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it is likely to have a cross-border impact. It does not require a full technical analysis at this stage — the purpose is to alert the authority that a significant incident has occurred.

Stage 2: Incident Notification — within 72 hours

Within 72 hours of becoming aware of the incident, the entity must provide an incident notification updating the early warning with an initial assessment of the incident, its severity, impact, and indicators of compromise where available. This notification must also indicate whether the incident is ongoing.

Stage 3: Final Report — within one month

A final report must be submitted no later than one month after the incident notification. The final report must provide a detailed description of the incident including its severity and impact, the type of threat or root cause, any cross-border impact, and the mitigating measures taken or proposed. This is the document that will be most closely examined in any subsequent supervisory review.

If an incident is still ongoing when the one-month deadline falls, a progress report is submitted at that point, with the final report due within one month of the incident being resolved.

The clock on all of these stages runs from awareness, not from discovery or confirmation. An organisation that delays formal acknowledgment of an incident to avoid starting the clock is not protected by that delay — it creates additional supervisory risk.

Identity-Specific Incidents and When Reporting Obligations Trigger

Not every security event triggers NIS2 reporting obligations — only "significant incidents" do. But for identity incidents, the threshold for significance is lower than many security teams assume, because identity compromises frequently meet multiple significance criteria simultaneously.

Credential compromise

A credential compromise — where an attacker obtains valid credentials and uses them to authenticate to covered systems — is likely to meet the significance threshold if it affects systems or services within NIS2 scope. The relevant question is not whether a password was stolen in isolation, but whether the compromised credentials enabled access to covered network and information systems. Where they did, the impact assessment required for significance is likely to be met.

Privilege escalation

An attacker who gains a foothold through a standard user account and then escalates to administrative or privileged access has caused an incident with greater potential impact than the initial compromise alone. Privilege escalation affecting covered systems is a strong indicator of a significant incident under NIS2, particularly where the escalated rights enable access to critical data or control systems.

Directory attacks

Attacks targeting directory services — Active Directory, Azure AD/Entra ID, LDAP infrastructure — are particularly serious under NIS2 because directory compromise affects the integrity of the entire access control system rather than a single account. A DCSync attack, a Golden Ticket, or a domain controller compromise creates immediate, extensive access across all systems that rely on that directory. Any such attack on an in-scope entity almost certainly meets the significance threshold.

What "Significant Incident" Means — the Threshold Question

Article 23(3) of NIS2 sets out the criteria for determining whether an incident is significant. An incident shall be considered significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

ENISA has published guidance on significance assessment, and implementing acts under Article 23(11) provide additional criteria. The factors that supervisors and CSIRTs use to assess significance include:

• The number of users affected by the disruption of the service
• The duration of the incident
• The geographic spread of the areas affected
• The extent to which the functioning of the network and information system can be restored
• The impact on economic and societal activities or on public safety
• The sensitivity of the data concerned

For identity incidents, the significance question is often whether the compromised access was used, or could have been used, to cause operational disruption or data loss — even if that use was detected and blocked. The "capable of causing" language means that an attempted attack that was successfully contained may still require reporting if the potential impact met the threshold.

The practical advice is to err on the side of notification. The consequences of failing to report a significant incident are more serious than the consequences of over-reporting. Early engagement with the national authority when the significance is unclear is better than a late notification after the 72-hour window has passed.

The Post-Incident Supervisory Examination

Following a reported incident, covered entities should expect supervisory attention — the intensity of which will depend on the severity of the incident and the quality of the final report submitted under Article 23. For identity incidents in particular, supervisors will examine the state of identity controls before the incident occurred.

The questions a supervisor or their appointed auditor will ask in a post-incident examination of identity controls include:

• Was MFA deployed on the access path used by the attacker? If the incident involved credential compromise on a remote access point without MFA, the absence of Article 21(2)(j) controls will be a primary finding.
• Were privileged accounts subject to appropriate controls? If privilege escalation was part of the incident, the supervisor will examine whether privileged accounts were managed, inventoried, and subject to appropriate access controls before the event.
• Were access rights reviewed and current? If the attacker used a dormant or forgotten account, the absence of effective joiner/mover/leaver controls or periodic access reviews will be identified.
• Was the incident detected within a reasonable timeframe? Detection capability — logging, alerting, monitoring of identity events — is within scope. An incident that persisted for weeks before detection suggests inadequate monitoring of identity activity.
• Was the management body informed and involved? Article 20 requires management body oversight of cybersecurity measures. If management were not informed of the incident promptly and appropriately, that creates a separate compliance issue alongside the incident itself.

The controls that were in place before the incident determine the organisation's position in the supervisory examination after it. An organisation with documented, tested, and evidenced identity controls is in a fundamentally different position to one that cannot demonstrate what was in place.

How to Prepare for the Reporting Obligation Before an Incident Happens

Preparation for NIS2 incident reporting cannot happen during an incident — the 24-hour early warning deadline does not allow time to establish processes from scratch. The following are the preparatory steps that should be completed in advance.

Know your competent authority and reporting contact

Each EU member state designates competent authorities and CSIRTs responsible for receiving NIS2 notifications. The relevant authority depends on the sector the entity operates in. In some member states, sector-specific authorities — financial regulators, energy regulators — are designated. Organisations should identify the correct reporting channel before they need it and confirm whether an online reporting portal exists.

Define your significance assessment process

The incident response process must include a significance assessment step that applies the Article 23(3) criteria. This assessment should be completed as early as possible after detection — within hours, not days — because the 24-hour early warning clock is already running. The significance assessment should be documented, with the reasoning for the conclusion recorded.

Prepare notification templates

The three-stage notification process requires specific information at each stage. Preparing template structures in advance — with guidance on what information to populate at each stage — reduces the time needed to produce a compliant notification under pressure. Templates should be reviewed and updated as national guidance evolves.

Establish identity incident detection capability

NIS2 reporting obligations depend on the organisation becoming aware of the incident. "Becoming aware" is not the same as "receiving confirmation." Where detection capability is weak — where identity events are not logged, where privileged account activity is not monitored, where directory changes do not generate alerts — incidents may go undetected for extended periods. When they are eventually discovered, the discovery date, not the incident date, starts the clock. But weak detection capability will be a finding in its own right in the supervisory examination that follows.

Monitoring for identity-specific threat indicators — failed authentication spikes, unusual privileged account activity, changes to directory objects, lateral movement patterns — should be part of the security operations capability for any NIS2-covered entity. This is not just good practice; it is the capability that enables timely compliance with Article 23.