NIS2 Incident Reporting: 24-Hour, 72-Hour, and Final Report Guide
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
NIS2 Incident Reporting: 24-Hour, 72-Hour, and Final Report Guide
NIS2's incident reporting framework is the most operationally demanding requirement in the directive. Article 23 creates a three-phase reporting structure: 24-hour early warning, 72-hour incident notification, and one-month final report (Directive 2022/2555, 2022). According to ENISA (2024), only 38% of EU entities had fully operational NIS2-aligned incident reporting processes by mid-2025, highlighting the complexity even for directly regulated organisations. For Indian IT companies supporting these EU entities, understanding and executing this timeline is critical.
Key Takeaways
- NIS2 requires three-phase reporting: 24 hours, 72 hours, one month
- Only 38% of EU entities had NIS2-aligned reporting by mid-2025 (ENISA, 2024)
- "Significant incident" threshold triggers reporting; not every incident qualifies
- Indian vendors must support their EU clients' reporting obligations with timely data
- Cross-border incidents require coordinated reporting to multiple CSIRTs
What Triggers NIS2 Incident Reporting?
Not every security event requires reporting. NIS2 Article 23(3) defines a "significant incident" as one that has caused or is capable of causing severe operational disruption or financial loss to the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage (Directive 2022/2555, 2022).
Significance Criteria
ENISA and national CSIRTs evaluate significance based on:
- Number of users affected: Incidents impacting a large number of users or recipients of the entity's services
- Duration: Prolonged service disruption or degradation
- Geographic scope: Incidents affecting services across multiple EU member states
- Financial impact: Significant financial losses to the entity or its users
- Data impact: Compromise of sensitive, personal, or confidential information
- Service availability: Disruption to critical services relied upon by other entities
- Cascading potential: Risk of the incident spreading to other sectors or entities
Examples of Significant Incidents
- Ransomware encrypting production systems serving EU clients
- Data breach exposing EU customer personal data
- DDoS attack causing sustained service unavailability (hours, not minutes)
- Supply chain compromise affecting multiple EU entities
- Insider threat resulting in data exfiltration
- Critical vulnerability actively being exploited in production systems
Examples That Likely Don't Meet the Threshold
- Contained phishing attempt that didn't compromise accounts
- Brief service interruption resolved within minutes
- Vulnerability discovered but not exploited
- Malware detected and blocked by endpoint protection
- Single account compromise quickly contained
The threshold is deliberately ambiguous to avoid gaming. When in doubt, report. Under-reporting carries more regulatory risk than over-reporting.
Citation capsule: NIS2 defines a "significant incident" as one causing or capable of causing severe operational disruption, financial loss, or considerable damage to others (Directive 2022/2555, Article 23(3), 2022), with thresholds assessed on user impact, duration, geographic scope, and cascading potential.
What Happens in the First 24 Hours?
The early warning is your first obligation. According to ENISA (2024), the 24-hour early warning is designed to alert authorities quickly, enabling coordinated response before the full impact is understood. It's deliberately lightweight to avoid delaying notification.
Early Warning Requirements
The early warning must be submitted within 24 hours of the entity becoming "aware" of the significant incident. It must include:
- Confirmation that an incident has occurred (or is suspected)
- Whether the incident is suspected to be caused by unlawful or malicious acts
- Whether it could have cross-border impact
That's it. The early warning is intentionally brief. You don't need root cause analysis, full impact assessment, or remediation status at this stage.
What "Becoming Aware" Means
Awareness starts when the entity has reasonable certainty that a significant incident has occurred. This isn't when a single alert fires. It's when initial investigation confirms that something material has happened.
For Indian IT companies supporting EU clients, awareness typically means:
- SOC team confirms the alert is a true positive
- Initial assessment suggests the incident meets significance criteria
- Management is informed per the incident response procedure
The Clock Starts
The 24-hour clock begins at awareness, not at incident start time. An incident that began at 2 AM but wasn't detected until 8 AM triggers the 24-hour window at 8 AM.
Practical Steps for Indian IT Vendors
Your EU client is responsible for submitting the early warning to their CSIRT. Your job is to provide them with the information they need fast enough for them to meet their deadline. If your incident notification to the EU client takes 8 hours, they have 16 hours left. If yours takes 18 hours, they have 6 hours, a dangerously tight window.
Target: Notify your EU client within 4-6 hours of your own awareness, giving them at least 18 hours to prepare and submit their early warning.
In incident response engagements we've supported, the most common delay is between SOC detection and management awareness. SOC analysts detect the issue but escalation to management (who authorise client notification) takes 2-4 hours. Pre-authorising SOC teams to notify clients for specific incident categories eliminates this bottleneck.
Need expert help with nis2 incident reporting?
Our cloud architects can help you with nis2 incident reporting — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
What Must the 72-Hour Notification Contain?
The incident notification deepens the early warning. According to Directive 2022/2555, Article 23(4) (2022), the 72-hour report must update the early warning with an initial assessment of the incident's severity and impact, plus indicators of compromise where available.
Required Content
The 72-hour notification must include:
- Updated assessment of the incident including severity, impact, and scope
- Indicators of compromise (IoCs) where available (IP addresses, domains, file hashes, attack signatures)
- Number of affected users/services with initial quantification
- Duration of the disruption or degradation
- Geographic spread if the incident affects multiple member states
- Initial assessment of root cause (not full analysis, but initial indications)
Practical Challenges
The 72-hour window is where most organisations struggle. At 72 hours, you may still be actively containing the incident. Gathering accurate impact data while managing response is resource-intensive.
What Indian IT Vendors Must Provide
Your EU client needs from you:
- Technical details of what happened in your systems
- Scope of affected EU client data or services
- Indicators of compromise from your investigation
- Timeline of events within your environment
- Containment actions taken and current status
- Estimated recovery timeline
Target: Provide detailed incident data to your EU client within 48 hours, giving them 24 hours to compile and submit the formal notification.
[PERSONAL EXPERIENCE] The 72-hour notification is the most operationally challenging phase. Indian IT companies that maintain pre-built incident report templates with structured data fields complete this phase 40% faster than those drafting reports from scratch during the incident. Build templates now, not during a crisis.
What Goes Into the Final Report?
The final report is due within one month and must be comprehensive. According to ENISA (2024), the final report is the document regulators use to assess whether the entity's risk management measures were adequate and whether the incident response was appropriate.
Required Content
Article 23(4)(d) requires the final report to include:
- Detailed description of the incident including severity, impact, and attack vector
- Type of threat or root cause that likely triggered the incident
- Applied and ongoing mitigation measures to address the incident and prevent recurrence
- Cross-border impact assessment where relevant
What Makes a Good Final Report
Beyond the minimum requirements, strong final reports include:
- Complete timeline from initial compromise to full recovery
- Root cause analysis identifying the specific vulnerability, misconfiguration, or process failure exploited
- Impact quantification covering affected users, data volume, service downtime, and financial impact
- Control effectiveness assessment evaluating which controls worked, which failed, and why
- Improvement actions with specific changes implemented or planned, with deadlines and owners
- Lessons learned documented for incorporation into the entity's risk management programme
Indian Vendor's Contribution
Your EU client's final report will include analysis of your systems and response. Provide:
- Complete forensic investigation results from your environment
- Root cause analysis for components within your responsibility
- Control improvement plan for your systems
- Evidence that improvements have been implemented
- Updated risk assessment reflecting the incident
Target: Deliver your complete investigation findings to the EU client within 3 weeks, giving them 1 week to incorporate into their final report.
How Do Cross-Border Incidents Complicate Reporting?
Cross-border incidents multiply reporting complexity. According to ENISA (2024), incidents affecting services in multiple EU member states require coordinated reporting to multiple national CSIRTs, with ENISA facilitating coordination.
When Cross-Border Reporting Applies
An incident has cross-border impact when:
- Services in multiple EU member states are disrupted
- Data subjects in multiple member states are affected
- The incident exploits a vulnerability present in multiple states' infrastructure
- The incident's effects cascade across borders
Coordination Mechanism
The entity reports to its primary CSIRT (in the member state where it's established or its representative is located). That CSIRT coordinates with CSIRTs in other affected member states through the CSIRTs network. ENISA provides technical support and situational awareness.
Implications for Indian IT Vendors
If your services support EU clients in multiple member states, a single incident in your infrastructure could trigger cross-border reporting. Your EU clients in different member states may each need to report to their respective national authorities.
Practical requirement: Assess incident impact per EU member state. Provide state-specific impact data to each affected EU client. Maintain awareness of which clients operate in which member states.
[UNIQUE INSIGHT] Indian IT companies with multi-country EU client portfolios should pre-build "impact matrices" mapping their infrastructure to EU clients and member states. When an incident occurs, the matrix instantly reveals which clients in which countries are potentially affected, enabling rapid per-client, per-country impact assessment rather than scrambling to determine the scope.
Citation capsule: Cross-border NIS2 incidents require coordinated reporting to CSIRTs in all affected EU member states, facilitated by ENISA and the CSIRTs network (ENISA, 2024), creating multi-jurisdiction reporting obligations that Indian vendors with multi-country EU client portfolios must pre-plan.
What Reporting Templates Should Indian Companies Prepare?
Preparation eliminates delays during incidents. According to SANS Institute (2024), organisations with pre-built incident reporting templates reduce notification times by 35% compared to those creating reports during active incidents.
Template 1: Initial Client Notification (Hour 0-6)
- Date and time of detection
- Brief incident description
- Systems potentially affected
- Initial severity assessment (critical/high/medium)
- Containment actions underway
- Expected next update time
- Contact details for the incident response team
Template 2: Detailed Client Update (Hour 6-48)
- Updated incident timeline
- Confirmed scope and impact
- Indicators of compromise identified
- Containment actions completed and in progress
- Affected data/services specifics
- Root cause hypothesis
- Estimated recovery timeline
Template 3: Investigation Summary (Week 1-3)
- Complete incident timeline
- Root cause analysis findings
- Full impact assessment
- Control effectiveness evaluation
- Remediation actions completed
- Improvement plan with deadlines
- Lessons learned summary
Template 4: CERT-In Report (Hour 0-6)
- Parallel track report using CERT-In's prescribed format
- Incident category per CERT-In's classification
- Affected systems and networks
- Impact assessment
- Actions taken
Build these templates now. Customise per EU client where their contracts specify particular formats or content requirements.
Frequently Asked Questions
What happens if the 24-hour early warning deadline is missed?
Missing the 24-hour deadline is itself a compliance failure. The entity may face enforcement action from its national authority. However, late reporting is better than no reporting. Submit the early warning as soon as possible with an explanation for the delay. Authorities consider cooperation and transparency when assessing enforcement responses.
Must Indian IT vendors report directly to EU CSIRTs?
Generally no, unless you're directly in NIS2 scope (for example, as a cloud provider or MSSP). Most Indian IT vendors support their EU clients' reporting by providing incident data quickly enough for the client to meet their own CSIRT deadlines. The EU client submits the formal reports.
How does GDPR's 72-hour breach notification interact with NIS2 reporting?
GDPR requires notification to data protection authorities within 72 hours for personal data breaches. NIS2 requires a 24-hour early warning and 72-hour incident notification to CSIRTs. If an incident involves personal data, both notifications must be made independently to different authorities. Build parallel notification tracks in your incident response process.
Can EU entities delegate incident reporting to their Indian vendors?
NIS2 places the reporting obligation on the EU entity, not its vendors. However, some EU entities may contractually require vendors to handle parts of the reporting process, particularly providing technical data and IoC sharing. Your contract will define your specific obligations.
What if the root cause is unknown at the one-month final report deadline?
Submit the final report with the best available analysis and note that the investigation is ongoing. NIS2 allows for additional follow-up reports. It's better to submit a thorough report acknowledging unknowns than to miss the deadline waiting for complete root cause analysis.
Key Takeaways on NIS2 Incident Reporting 24-Hour 72-Hour
NIS2's three-phase incident reporting is demanding but structured. The 24-hour early warning flags the incident's existence. The 72-hour notification provides initial analysis. The one-month final report delivers comprehensive findings.
For Indian IT companies, the obligation is indirect but critical. Your EU clients depend on your speed and thoroughness. Pre-build reporting templates. Pre-authorise SOC notification processes. Pre-map client impact matrices.
The companies that prepare for incident reporting before incidents occur will respond effectively. Those that first encounter the requirements during a crisis will struggle with timelines, formats, and coordination.
Your next step: build your incident reporting templates and test them in a tabletop exercise simulating a NIS2-reportable incident affecting an EU client.
For hands-on delivery in India, see nis2 compliance guide for Indian enterprises.
About the Author
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.