Of all the requirements NIS2 introduces, the incident reporting obligations are among the most operationally demanding. Unlike many compliance controls that can be put in place gradually, incident reporting requires your organization to be ready before anything goes wrong — because when an incident occurs, you have hours, not days or weeks, to notify your national authority.
Article 23 of NIS2 establishes a structured, multi-stage reporting process with legally binding timelines. Missing these deadlines is not a technical failure — it is a compliance breach that can trigger significant fines and regulatory scrutiny independently of the incident itself.
What Counts as a "Significant Incident"?
Not every security event triggers NIS2 reporting obligations. NIS2 requires notification for significant incidents — those that have or could have a significant impact on the provision of services. When assessing significance, regulators consider:
- Service disruption: Has the incident caused or could it cause a major disruption or outage to the organization's services?
- Number of affected users: How many natural or legal persons are affected, particularly those relying on the service?
- Duration: How long has the disruption lasted or is it expected to last?
- Geographic scope: Does the impact extend across regions or member states?
- Financial loss: What is the actual or estimated financial impact on the organization?
- Reputational damage: Has the incident caused or could it cause significant reputational harm?
- Data breach component: Does the incident involve unauthorized access to personal or sensitive data?
The Three-Stage Reporting Process
NIS2 Article 23 establishes a clear, three-stage reporting process. Each stage has its own timeline and content requirements:
Stage 1: Early Warning
As soon as you become aware of a significant incident, you must submit an early warning to your national competent authority (NCA) or CERT/CSIRT. At this stage, you don't need all the answers — the early warning is simply an initial notification that an incident has occurred or is suspected. It should include: type of incident, whether you suspect malicious intent, and any cross-border impact. The clock starts from the moment your organization has awareness of the incident, not from the moment you finish your internal investigation.
Stage 2: Incident Notification
Within 72 hours of becoming aware of the incident, you must provide a detailed incident notification. This report should include an initial assessment of severity and impact, indicators of compromise (if available), the nature of the incident, and measures already taken or planned. If your investigation is still ongoing, submit what you know and indicate that the report will be updated.
Stage 3: Final Report
Within one month of submitting the incident notification, you must provide a final report containing a full description of the incident, the root cause analysis, the impact assessment, the measures implemented to address the incident and prevent recurrence, and any cross-border implications. If the incident is still ongoing at the one-month mark, submit an interim progress report and provide the final report within one month of incident resolution.
Who Do You Report To?
Reports go to your National Competent Authority (NCA) — the designated regulator for NIS2 in the EU member state where you are established. In some countries, this is a dedicated cybersecurity agency; in others, it is a sector regulator (e.g., for energy, transport, or health).
In practice, many member states route initial reports through their national CERT/CSIRT (Computer Emergency Response Team / Computer Security Incident Response Team). Your CERT/CSIRT can also provide technical assistance during an active incident. Check your member state's implementing legislation to confirm the exact reporting channel.
If the incident affects multiple EU member states, you may need to notify authorities in each affected country. The NCA in your home member state typically coordinates with counterparts in other states, but you remain responsible for direct notification where required.
What Happens If You Miss the Deadline?
Failing to meet NIS2 reporting timelines is treated as a compliance breach — separate from the incident itself. Consequences can include:
- Financial fines: Up to €10 million or 2% of global turnover for Essential Entities; up to €7 million or 1.4% for Important Entities
- Reputational damage: Regulators may publicly disclose the organization's non-compliance
- Increased regulatory scrutiny: A missed deadline is likely to trigger a more intensive supervisory review of your entire compliance posture
- Management liability: Senior executives can be held personally accountable for failures in incident reporting processes
How to Prepare Before an Incident Occurs
The worst time to design your incident reporting process is during an active incident. Build readiness now:
- Develop an Incident Response Plan (IRP): Document detection, triage, escalation, and notification procedures. Identify who is responsible for triggering NIS2 notifications and who approves them.
- Identify your NCA and CERT/CSIRT: Know the exact contact details, reporting portal URLs, and required formats before you need them.
- Designate a NIS2 reporting contact: A named individual (and backup) who is authorized to communicate with authorities and who understands the reporting requirements.
- Invest in detection capabilities: You cannot report what you don't know about. SIEM tools, network monitoring, and endpoint detection help ensure incidents are identified quickly.
- Run tabletop exercises: Simulate significant incidents and practice the 24-hour and 72-hour notification workflow with your team.
- Integrate with GDPR reporting: Many incidents that trigger NIS2 reporting will also trigger GDPR breach notification obligations (72 hours to the data protection authority). Coordinate these processes to avoid duplication and inconsistency.
Build a Compliant Incident Response Process
BALTUM Bureau helps organizations design and implement NIS2-compliant incident response procedures — from initial detection protocols to national authority reporting workflows. Don't wait for an incident to find the gaps.
Contact BALTUM for Incident Response Support