NIS2 Incident Reporting: The 24-Hour and 72-Hour Rules

The NIS2 Directive sets NIS2 requirements for reporting significant incidents. An early warning is due within 24 hours of becoming aware of an incident, followed by an incident notification within 72 hours. The final report is due within one month of submitting the notification, not one month after the incident.

For leadership teams, the challenge is producing reliable information whilst managing disruption. Meeting these deadlines starts with clear decision-making authority, an accessible response process and reporting arrangements prepared before an incident occurs.

Key takeaways

• Essential and important entities must report significant incidents without undue delay. The 24-hour and 72-hour deadlines are maximum limits.

• The reporting clock starts when the organisation becomes aware of a significant incident, not when investigators establish its root cause.

• Submit reports to the designated national computer security incident response team (CSIRT) or competent authority, using the applicable national reporting route.

Who must report under NIS2?

Essential and important entities

The NIS2 Directive covers specified activities across energy, healthcare, banking, digital infrastructure, digital services and manufacturing, amongst other sectors. Medium-sized and larger organisations generally fall within scope, although sector-specific exceptions apply. Financial entities also have sector-specific obligations under DORA.

UK organisations can fall within scope through covered EU activities or services. Supplying a regulated customer doesn't automatically make a vendor directly subject to NIS2. Suppliers may instead face contractual incident-notification and third-party security requirements.

EU Member States had to transpose the Directive into national law by 17 October 2024. National legislation sets the NIS2 requirements for reporting arrangements and enforcement responsibilities. Organisations must check the applicable rules for NIS2 compliance.

What makes an incident significant?

Article 23 treats an incident as significant where it causes, or could cause, severe operational disruption or financial loss to the entity. Incidents also qualify where they cause, or could cause, considerable material or non-material damage to others. This assessment helps determine whether incident reporting obligations apply.

Your assessment should therefore consider service availability, affected recipients, safety, financial consequences and potential harm. Some digital providers also face more detailed EU implementing criteria.

Record the assessment and its timing. A technical alert alone doesn't establish significance, but uncertainty about the full impact isn't a reason to postpone escalation.

The NIS2 incident reporting timeline

Within 24 hours: send the early warning

Send the 24-hour warning to the designated CSIRT or competent authority without undue delay, and within 24 hours of awareness.

Where applicable, indicate whether you suspect unlawful or malicious activity and whether the incident could affect other countries. You don't need a completed forensic investigation before submitting this warning.

Within 72 hours: submit the incident notification

The incident notification updates the early warning. Include an initial assessment of severity and impact, plus available indicators of compromise.

Both deadlines run from awareness. The 72-hour period doesn't begin after the early warning. Trust service providers face a shorter notification deadline, addressed below.

Within one month: submit the final report

The final report is due no later than one month after submitting the incident notification. Include the incident's severity and impact, likely threat or root cause, mitigation measures and any cross-border effects.

If the incident remains ongoing, submit a progress report at that deadline. Then submit the final report within one month after handling concludes. Authorities can also request intermediate status updates.

For deadline calculation, awareness at 10:00 UTC on 10 November 2026 gives maximum deadlines of 10:00 UTC on 11 November and 13 November. If you submit the incident notification on 13 November, the final-report deadline is 13 December.

  An earlier incident notification brings forward the final-report deadline. Calculate it from the actual submission date.  

Use one incident record for every submission

Maintain a controlled record for each security incident rather than rebuilding the account for every report. Separate confirmed findings, preliminary assessments and outstanding questions.

The following structure supports preparation for the applicable national reporting form.

Record area	Information to capture
Identity and contacts	Legal entity, affected service, incident reference, reporting lead and deputy.
Timeline and significance	Detection, awareness and submission timestamps; significance assessment and reasoning.
Impact	Disruption, affected recipients, financial consequences and possible harm to others.
Threat information	Suspected malicious activity, available indicators and possible cross-border effects.
Response and recovery	Containment, mitigation, restoration status and unresolved risks.
Final analysis	Incident description, likely root cause, completed measures and outstanding actions.

This record supports consistency without requiring every field to be complete at the early-warning stage. Mark unknown information clearly and update it as evidence develops.

Retain submission receipts and report versions alongside the incident chronology. Preserve relevant logs and evidence using access controls that limit access to authorised staff.

An internal remediation report can support the final analysis, but it doesn't replace the required submission to the authority.

Reporting may also extend beyond authorities. Where appropriate, NIS2 requires communication with affected service recipients. Personal-data breaches can trigger separate GDPR obligations, so the data protection lead should assess those alongside NIS2 reporting.

Build a response process that meets the deadlines

Assign authority before an incident

Name an incident lead, technical lead, reporting owner and deputies. Small organisations can combine roles, but they still need capacity to investigate and maintain records simultaneously.

Document who can isolate systems, disable accounts, approve notifications and authorise emergency expenditure. Legal advisers, the data protection lead and communications staff should join decisions when their responsibilities apply.

Pre-arrange out-of-hours coverage and access to reporting portals. Our incident response planning guidance explains how to connect escalation, delegated authority and evidence handling.

Test continuity and supplier arrangements

Business continuity planning should cover system recovery, emergency procedures and a crisis response team. Keep response instructions accessible if corporate messaging or identity services fail.

During recovery, maintain appropriate access restrictions, encryption and logging. Test restoration as well as backup creation, and protect recovery credentials.

Agree supplier security arrangements in advance, including escalation contacts, notification times and access to evidence. Select supply chain security measures according to each direct supplier's vulnerabilities and the quality of its products, services and security practices. Then assess the overall security level of your suppliers and service providers.

Connect reporting with the ten minimum security measures

Reporting depends on wider controls. Risk management, corporate accountability, reporting obligations and business continuity provide a useful way to organise the programme.

Article 21 requires appropriate and proportionate measures covering ten minimum areas:

1. Maintain policies for risk analysis and information-system security.

2. Establish incident-handling arrangements.

3. Prepare business continuity, backup management, disaster recovery and crisis management.

4. Address supply chain security, including direct suppliers and service providers.

5. Secure system acquisition, development and maintenance, including vulnerability handling.

6. Assess whether cybersecurity risk-management measures work effectively.

7. Maintain cyber hygiene practices and cybersecurity training.

8. Establish policies for cryptography and, where appropriate, encryption.

9. Address personnel security, access controls and asset management.

10. Use multi-factor authentication or continuous authentication and secured communications where appropriate, including secured emergency communications.

A gap analysis that compares current controls with these ten areas can identify implementation gaps and help prioritise action.

An ISO/IEC 27001 management system can organise risk treatment, ownership and evidence around these requirements. However, certification doesn't establish NIS2 compliance by itself.

ISO 27001 Annex A controls 5.24 to 5.28 address incident preparation, assessment, response, learning and evidence collection. Controls 5.29 and 5.30 connect security during disruption with ICT continuity readiness.

Control applicability requires justification through risk treatment and the Statement of Applicability. ISO 27001 doesn't prescribe a standalone incident-plan template or the NIS2 reporting deadlines.

Management accountability and implementation priorities

Management bodies must approve and oversee cybersecurity risk-management measures. Depending on national implementation, they can face liability for infringements. Authorities can also temporarily suspend relevant managerial responsibilities at essential entities, but this isn't an automatic penalty.

For breaches of Articles 21 or 23, national regimes must provide maximum fines of at least €10 million or 2% of worldwide annual turnover for essential entities. For important entities, the figures are €7 million or 1.4%, whichever is higher.

A full compliance programme can take approximately 12 months, including security assessments, audits, consulting and tool implementation. Treat this as a planning estimate, not a statutory grace period.

Senior management should oversee immediate reporting readiness and longer-term remediation, using gap analysis findings to prioritise remediation. A vCISO service can provide governance oversight where a full-time security leader isn't practical.

Frequently asked questions

Do weekends pause the reporting clock?

The Directive expresses these deadlines in hours, not working days. Your response arrangements therefore need weekend and bank-holiday coverage.

Trust service providers must submit their incident notification within 24 hours of awareness where the significant incident affects their trust services.

Can existing certification work support NIS2 readiness?

Yes. ISO 27001 training can strengthen escalation awareness, whilst consultancy and internal auditing can improve procedures and evidence. However, these activities don't replace statutory reporting.

Automotive suppliers can reuse incident records across TISAX training, consultancy and auditing preparation. The ENX participant handbook explains the TISAX assessment process, which remains separate from NIS2 reporting.

Likewise, ISO 42001 addresses AI management, whilst CMMC concerns US defence information requirements. Shared controls can support multiple obligations, but reporting routes and evidence requirements remain distinct.

Make reporting readiness a management priority

Reliable NIS2 reporting starts before disruption. Establish the awareness trigger, reporting owner and submission route, then exercise them alongside containment and recovery.

The strongest preparation produces usable evidence under pressure. Teams need to explain what happened, what it affects and what they are doing about it.

If you would like to find out more information or require any of our services please Contact Us and complete our contact form.