NIS2 Incident Reporting: 24-Hour, 72-Hour, and 1-Month Requirements Explained

When a ransomware attack hits your organization at 2 AM on a Friday, you have exactly 24 hours to notify your national competent authority under NIS2. Miss that deadline, and you’re looking at penalties up to €10 million or 2% of global turnover—on top of whatever damage the incident itself causes.

NIS2 incident reporting requirements are among the most demanding aspects of the directive, and they catch many organizations unprepared. Unlike previous regulations where you could wait until you had a complete picture, NIS2 forces you to report while you’re still figuring out what happened.

This guide walks through exactly what you need to report, when, and to whom—so you can build procedures that ensure compliance even during the chaos of a real incident.

Why NIS2 Incident Reporting Matters

The NIS2 Directive fundamentally changed how organizations must handle cybersecurity incident disclosure. Under NIS1, incident reporting was often vague, inconsistent across member states, and easy to delay. That approach failed to give regulators or other organizations the visibility needed to respond to emerging threats.

NIS2 fixes this with prescriptive timelines and clear reporting requirements. The goal isn’t bureaucratic compliance—it’s creating a real-time picture of the European threat landscape so that:

• Regulators can coordinate responses across borders when attacks target multiple organizations
• CSIRTs can issue timely warnings to other potential victims
• Patterns can be identified early, enabling faster collective defense
• Organizations can learn from incidents affecting their sector

For your organization, robust incident reporting also demonstrates due diligence to insurers, customers, and partners. When you can show you detected, contained, and reported an incident properly, you’re in a much stronger position during claims negotiations and contract discussions.

The 3-Stage Reporting Timeline: What You Must Do and When

NIS2 breaks incident reporting into three distinct phases, each with specific requirements and deadlines. You don’t wait until you have all the answers—you report what you know at each stage.

Stage 1: 24-Hour Early Warning

Deadline: Within 24 hours of detecting a significant incident

The 24-hour requirement catches many organizations off guard. You’re not expected to have a complete picture—you’re expected to raise your hand and say something happened.

What triggers the 24-hour report:

• You’ve detected a significant incident (defined below)
• You’re still investigating but have confirmed something occurred
• You’re not sure of the full scope but know it meets severity thresholds

What to include:

• Initial notification that a significant incident has occurred or is suspected
• Contact information for your organization’s incident response team
• Indication of whether you suspect unlawful or malicious action
• Potential cross-border impact if known (which member states might be affected)

Format requirements: Most national competent authorities provide web portals or secure email addresses for initial notifications. Have these bookmarked and accessible to your incident response team. The initial report can be brief—the goal is speed, not completeness.

Practical tip: Create a template with all static information (organization details, competent authority contacts, CSIRT information) pre-filled. During an incident, you shouldn’t be hunting for email addresses or registration numbers.

Stage 2: 72-Hour Incident Notification

Deadline: Within 72 hours of detecting a significant incident

This is where you provide substantive detail about what happened and its potential impact. By 72 hours, you should have completed initial triage and have a clearer picture of the incident.

What to include:

• Updated description of the incident nature, including content and scope
• Initial assessment of severity and impact
• Indicators of compromise (IOCs) if available, to help protect other organizations
• Cross-border impact assessment: which member states are affected or potentially affected
• Status of your response: what containment and eradication steps you’ve taken
• Any assistance needed from the competent authority or CSIRT

Severity assessment considerations:

• Number of users affected
• Geographic spread of impact
• Duration of service disruption
• Impact on critical societal or economic activities
• Extent of data compromised (especially personal data)
• Reputational damage potential

Cross-border coordination: If your organization operates in multiple member states, or if the incident affects systems in other countries, you must indicate this in your 72-hour report. The competent authority will coordinate with counterparts in affected states.

Stage 3: 1-Month Final Report

Deadline: Within one month of the initial incident detection

The final report is your comprehensive account of what happened, why it happened, and what you’re doing to prevent recurrence. This document will be scrutinized by regulators and may be requested by insurers during claims processing.

What to include:

• Detailed incident description: timeline, attack vectors, systems affected, data compromised
• Root cause analysis: how the incident occurred and why controls failed
• Mitigation measures implemented: both immediate containment and longer-term remediation
• Cross-border impact: final assessment of which member states were affected
• Lessons learned: what you discovered about your security posture
• Evidence of notification to affected parties (GDPR requirements may also apply)

What if you’re still investigating? If one month isn’t sufficient to complete your investigation (common in sophisticated attacks), you still submit a final report with available information and indicate that investigation is ongoing. You may be required to provide updates as new information emerges.

Reporting Timeline Comparison Table

Phase	Deadline	Primary Purpose	Key Content
Early Warning	24 hours	Alert authorities, establish contact	Incident occurred, contact info, suspected malicious action, potential cross-border impact
Incident Notification	72 hours	Provide actionable detail	Incident scope, severity assessment, IOCs, containment status, cross-border coordination
Final Report	1 month	Full documentation	Root cause analysis, complete timeline, mitigation measures, lessons learned

What Triggers Reporting: Defining “Significant Incident”

Not every security event requires reporting under NIS2. You’re required to report significant incidents—those that meet specific severity thresholds.

Legal Definition of Significant Incident

Under Article 23, a significant incident is any incident that:

1. Has caused or is capable of causing severe operational disruption of services or financial loss for the entity concerned; OR
2. Has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

This is intentionally broad. The “capable of causing” language means you must assess potential impact, not just actual impact observed.

Specific Triggers That Require Reporting

Consider an incident significant and reportable if it involves:

Operational Disruption:

• Service outage affecting critical functions for more than a few hours
• Significant degradation of service quality affecting users
• Loss of availability for essential systems or data
• Disruption to supply chain partners or customers

Security Compromise:

• Successful ransomware or malware deployment
• Unauthorized access to critical systems or sensitive data
• Data exfiltration (confirmed or suspected)
• Compromise of administrative credentials or privileged access
• Exploitation of zero-day vulnerabilities in your infrastructure

Cascading Effects:

• Incidents affecting multiple organizations or sectors
• Compromise of shared infrastructure (cloud services, data centers, telecoms)
• Supply chain attacks affecting your customers or partners
• Cross-border impact reaching other member states

Examples of Reportable Incidents

Incident Type	Why It’s Reportable
Ransomware attack encrypting critical servers	Severe operational disruption, potential data compromise
Data breach exposing customer personal information	Non-material damage to affected individuals, GDPR implications
DDoS attack taking services offline for 6+ hours	Service availability disruption
Insider threat accessing systems beyond authorization	Potential for data exfiltration, trust violation
Supply chain compromise via compromised software update	Cascading effects, potential cross-border impact
Zero-day exploitation of internet-facing systems	High severity, indicators useful for other organizations

What Doesn’t Require Reporting

Not everything needs to go to your competent authority. You typically don’t need to report:

• Unsuccessful attacks: Attempted intrusions that were blocked by your controls (though track these internally)
• Minor incidents: Events with minimal impact that don’t meet significance thresholds
• Vulnerability disclosures: Unpatched vulnerabilities that haven’t been exploited (different reporting requirements apply)
• Near misses: Events that could have been serious but were caught early through effective controls

However: Document everything. Regulators may ask for evidence of your triage process during audits, and insurers will want visibility into your incident history.

To Whom Reports Go: Competent Authorities and CSIRTs

Knowing where to send reports is just as important as knowing when. NIS2 establishes a network of competent authorities and CSIRTs across member states.

National Competent Authorities

Each EU member state designates one or more competent authorities responsible for NIS2 implementation and oversight. These are your primary contacts for incident reporting.

What competent authorities do:

• Receive and process incident reports
• Coordinate with other member states when incidents cross borders
• Issue guidance and enforce compliance
• Share threat intelligence with the CSIRT network
• Impose penalties for non-compliance

How to find your competent authority: The European Union maintains a list of designated authorities, but you should identify your specific contacts before an incident occurs. Check your member state’s NIS2 implementation legislation or cybersecurity agency website.

CSIRT Network

The CSIRT (Computer Security Incident Response Team) network facilitates information sharing and coordinated response across the EU. While you typically report to your national competent authority, CSIRTs play a crucial role in:

• Receiving and analyzing incident reports
• Disseminating indicators of compromise to other organizations
• Coordinating cross-border incident response
• Providing technical assistance during major incidents

Some member states designate their national CSIRT as the primary incident reporting recipient; others use a separate competent authority. Know which applies to your organization.

Cross-Border Coordination

When an incident affects multiple member states (increasingly common with cloud infrastructure and cross-border services), coordination becomes critical:

1. You report to your primary competent authority (where your organization is established)
2. Your authority coordinates with counterparts in affected member states
3. CSIRTs share indicators across their network
4. Joint response may be orchestrated if the incident is widespread

Your 72-hour notification should clearly indicate which other member states are potentially affected, enabling this coordination.

Practical Step: Build Your Contact List

Don’t wait until an incident to figure out where reports go. For each jurisdiction where you operate:

• Identify the competent authority and their reporting portal
• Register your organization if pre-registration is required
• Save contact information for urgent out-of-hours notification
• Document the CSIRT contact for technical coordination
• Understand any sector-specific reporting requirements (financial services, healthcare, etc.)

Common Mistakes That Lead to Non-Compliance

Even organizations with good security programs struggle with incident reporting. Here are the most common pitfalls and how to avoid them.

1. Missing the 24-Hour Window

The problem: Teams wait too long to escalate, hoping to gather more information before notifying leadership. By the time the decision to report is made, the 24-hour window has closed.

How to avoid it:

• Establish clear escalation triggers that don’t require complete information
• Empower your incident response team to initiate reporting without executive approval for the 24-hour notice
• Set internal deadlines at 12-16 hours to allow buffer for decision-making
• Practice the timeline in tabletop exercises until it becomes automatic

2. Incomplete or Inaccurate Initial Reports

The problem: Organizations submit rushed 24-hour reports with incorrect information, then must issue corrections that undermine credibility.

How to avoid it:

• Distinguish between what you know and what you suspect in your reports
• Use phrases like “preliminary assessment indicates” and “investigation ongoing”
• Update authorities as information changes rather than waiting for certainty
• Focus on accuracy of what you do report rather than comprehensiveness

3. Poor Internal Coordination

The problem: Legal, communications, IT security, and business teams operate in silos, resulting in conflicting information and delayed decisions.

How to avoid it:

• Establish a cross-functional incident response team with clear roles
• Designate a single point of contact for regulatory communications
• Run regular exercises that test coordination between teams
• Document decision-making authority in advance so no one is searching for approval during a crisis

4. Not Preparing Templates in Advance

The problem: During an incident, teams waste precious hours drafting notification text, hunting for competent authority contact details, and formatting reports.

How to avoid it:

• Create pre-approved templates for all three reporting phases
• Pre-populate static information (organization details, contacts, system inventory)
• Include checklists to ensure no required elements are missed
• Store templates in an accessible location known to all incident response team members
• Review and update templates quarterly or when regulations change

5. Underestimating Cross-Border Impact

The problem: Organizations report incidents as domestic when they actually affect systems, customers, or partners in other member states—triggering coordination failures.

How to avoid it:

• Maintain an up-to-date inventory of systems and data locations across jurisdictions
• Understand your data flows: where does customer data reside, which cloud regions are used
• Map your supply chain dependencies across member states
• Include cross-border assessment in your standard incident triage checklist
• When in doubt, report potential cross-border impact and let authorities assess

Building an Effective Incident Reporting Capability

Compliance requires more than understanding the rules—you need operational procedures that work under pressure. Here’s how to build a robust incident reporting capability.

1. Create Notification Templates

Develop templates for all three reporting phases that include:

24-Hour Early Warning Template:

• Organization legal name and registration details
• Competent authority contact information
• Contact details for your incident response coordinator
• Standard language for initial notification
• Checklist of required information
• Template fields for incident description (to be completed during incident)

72-Hour Incident Notification Template:

• Reference to 24-hour report (date, reference number)
• Structured sections for incident scope, severity, IOCs
• Cross-border impact assessment framework
• Status update on response actions
• Request for assistance section if needed

1-Month Final Report Template:

• Complete incident timeline template
• Root cause analysis framework
• Mitigation measures documentation
• Lessons learned structure
• Evidence appendix guidelines

Store these templates in multiple accessible locations: your incident response platform, a secure shared drive, and with your incident response team leads.

2. Establish Escalation Procedures

Define clear escalation paths that enable rapid decision-making:

Level 1 - Incident Detection:

• Security operations or IT detects potential incident
• Initial triage begins immediately
• Timer starts for 24-hour reporting decision

Level 2 - Incident Response Team Activation:

• IR team lead notified for incidents meeting severity thresholds
• IR team assembles and begins investigation
• Legal and communications placed on standby

Level 3 - Reporting Decision:

• IR team lead makes 24-hour reporting recommendation
• If threshold clearly met, report without waiting for executive approval
• If uncertain, escalate to CISO or designated executive with 12-hour deadline

Level 4 - Executive Notification:

• Brief executives on incident and reporting timeline
• Coordinate external communications
• Authorize resources for response

Document decision rights clearly: who can authorize reporting, who must be consulted, and who has final authority on uncertain cases.

3. Test Through Tabletop Exercises

Your incident reporting procedures are only as good as their performance under pressure. Conduct regular tabletop exercises that specifically test reporting timelines:

Exercise Design:

• Include scenarios that clearly require reporting
• Include scenarios where reporting is borderline (test triage)
• Simulate the 24-hour window with compressed exercise time
• Require participants to draft actual reports using templates

Exercise Evaluation:

• Did the team identify the incident as reportable within 4 hours?
• Was the 24-hour report submitted on time?
• Was information accurate and appropriately caveated?
• Were templates used effectively?
• Did coordination between teams work smoothly?
• Were competent authority contacts correct and accessible?

Frequency: Conduct at least one incident reporting exercise per quarter, with participation from all teams involved in the response process.

4. Integrate with Existing Incident Response

NIS2 reporting shouldn’t be a separate process—it should integrate with your broader incident response plan:

• Detection and analysis phase: Include triage questions for NIS2 reporting thresholds
• Containment phase: Document containment actions for 72-hour report
• Eradication phase: Track indicators of compromise for sharing with authorities
• Recovery phase: Document recovery timeline and effectiveness for final report
• Post-incident activity: Root cause analysis feeds directly into final report

5. Maintain Documentation and Evidence

Regulators may audit your incident reporting during supervision activities. Maintain records of:

• All incident reports submitted (including timestamps)
• Internal triage decisions and rationale
• Evidence that supported your assessments
• Communications with competent authorities
• Post-incident reviews and lessons learned
• Improvements made as a result of incidents

This documentation also supports insurance claims and demonstrates due diligence to partners and customers.

Implications for Insurance Professionals

For underwriters, risk managers, and claims professionals, NIS2 incident reporting requirements have significant implications.

How Incident Reporting Affects Coverage

During underwriting:

• Ask prospective insureds about their NIS2 incident reporting procedures
• Evaluate whether they have templates, tested escalation paths, and trained teams
• Organizations with mature reporting capabilities present lower regulatory and reputational risk
• Non-compliance with reporting requirements could trigger policy exclusions or claims complications

During claims:

• Verify that the insured complied with NIS2 reporting requirements for the incident
• Request copies of reports submitted to competent authorities
• Delays in reporting may indicate broader organizational dysfunction
• Evidence of timely, accurate reporting demonstrates good risk management

What Underwriters Should Look For

When assessing cyber risk for NIS2-covered organizations, evaluate:

Policy and Procedure Evidence:

• Written incident reporting procedures that reflect NIS2 timelines
• Pre-approved notification templates
• Documented escalation paths with clear decision rights
• Competent authority contact information compiled and accessible

Testing and Training:

• Tabletop exercise records showing reporting timeline practice
• Training records for incident response team members
• Evidence of lessons learned integration after incidents

Governance:

• Management awareness of reporting obligations
• Clear accountability for compliance
• Regular reporting to board or executive committee on incident readiness

Claims Implications

Scenario 1: Insured Reports Incident Properly

• Organization detects ransomware, reports within 24 hours
• Cooperates with authorities throughout investigation
• Submits final report with root cause analysis
• Claims process proceeds normally; organization demonstrated good faith

Scenario 2: Insured Fails to Report

• Organization experiences breach but delays reporting
• Misses 24-hour and 72-hour windows
• Regulator opens investigation into non-compliance
• Insurer may argue material breach of policy conditions
• Coverage disputes become more likely

Scenario 3: Insured Underreports Cross-Border Impact

• Organization reports incident but minimizes cross-border effects
• Other member states affected but not notified
• Regulatory coordination failure leads to enforcement action
• Reputational damage exceeds what it would have been with proper reporting

For claims professionals, request incident report documentation early in the claims process. Understand whether the insured complied with their regulatory obligations—it affects both the claim assessment and your understanding of the organization’s risk management maturity.

Take Action: Prepare Before You Need It

NIS2 incident reporting requirements are demanding by design. Regulators want organizations to report quickly, share actionable information, and coordinate across borders. That only works if you’ve done the preparation before an incident occurs.

Your immediate action items:

1. Confirm your NIS2 classification: Are you an Essential or Important entity? Use our NIS2 Compliance Checker if you’re not sure.

2. Identify your competent authority: Know exactly where reports go for each jurisdiction where you operate.

3. Create notification templates: Draft templates for all three reporting phases and get them approved by legal.

4. Test your escalation procedures: Run a tabletop exercise that specifically tests the 24-hour reporting timeline.

5. Integrate with your incident response plan: Ensure NIS2 reporting is embedded in your broader response procedures.

6. Brief your leadership: Ensure executives understand their personal liability and the importance of rapid reporting.

Organizations that prepare now will navigate incidents smoothly, maintain regulatory compliance, and demonstrate the maturity that insurers and partners value. Those that wait until an incident occurs will find themselves scrambling under pressure—and risking significant penalties.

Start with a clear assessment of where you stand:

👉 Check Your NIS2 Compliance Status

Our free tool provides instant classification, gap analysis against all NIS2 requirements (including incident reporting), and a prioritized action plan.

---

Need help developing your NIS2 incident reporting procedures or broader compliance program? Resiliently provides cyber risk assessment and compliance advisory services for organizations navigating complex regulatory requirements. Get in touch to discuss your specific needs.

---

Related NIS2 Resources

• NIS2 Penalties & Fines Explained: What Organizations Actually Face in 2026 — Fines for late/missing incident reports
• NIS2 Compliance Checklist: 70+ Action Items — Domain 2 covers incident reporting procedures
• NIS2 Essential vs Important Entities: Classification Guide — Entity tier affects who you report to and penalty risk
• The NIS2 Audit Crunch: What Underwriters Need to Know — How audits will assess your reporting readiness