_1762866128417-DS2_OO1j.png)
Legal basis and scope
Reporting obligations are set out in Article 23 of the NIS2 directive (EU) 2022/2555 and specified by national implementing laws. Reports go to the competent authority or national CSIRT – in Germany, for example, to the BSI via its reporting portal. For certain digital services – such as cloud providers, data centres, managed service providers or online marketplaces – Implementing Regulation (EU) 2024/2690 also defines when an incident counts as significant.
The obligation applies to essential and important entities. Whether your company is one of them is determined by the scoping check – more on the page NIS2 compliance.
When is an incident "significant"?
Only significant incidents must be reported. Under Article 23(3), an incident is significant if it:
- has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or
- has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Criteria such as duration and scope of the disruption, number of affected users, criticality of affected services, data exfiltration, financial impact and cross-border consequences help with the assessment. Document the assessment even if you conclude that no report is required.
| Example | Typical assessment |
|---|---|
| Ransomware encrypts production systems; manufacturing stops for two days | Significant – severe operational disruption |
| Phishing email reaches mailboxes but is recognised and deleted | Not significant – no damage |
| Compromised administrator account with access to customer data | Likely significant – possible damage to third parties |
| Short DDoS attack, website slow for 20 minutes | Usually not significant – depends on service and impact |
Reporting deadlines
| Report | Deadline | Content |
|---|---|---|
| Early warning | Without undue delay, at the latest 24 hours after becoming aware | Whether the incident is suspected to be unlawful or malicious and whether it could have cross-border impact |
| Incident notification | Without undue delay, at the latest 72 hours after becoming aware | Update of the early warning, initial assessment with severity and impact, indicators of compromise where available |
| Intermediate report | On request of the authority | Relevant status updates |
| Progress report | If the incident is still ongoing after one month | Current status; final report follows within one month of handling the incident |
| Final report | At the latest one month after the incident notification | Detailed description, type of threat and root cause, mitigation measures, cross-border impact |
Trust service providers have a shortened deadline of 24 hours for the incident notification. What counts is the moment you became aware of the significant incident – not when the analysis is complete.
Informing recipients of your services
Besides the authority, you may also have to inform the recipients of your services without undue delay about significant incidents likely to affect the provision of the service. For significant cyber threats, tell potentially affected recipients which measures they can take themselves. Prepare text templates and distribution lists for this.
The reporting process step by step
- 1
Detect and record
A possible security incident is detected – through monitoring, employees, service providers or customers – and recorded centrally at once. Note the time of awareness.
- 2
Assess significance
A designated team assesses against prepared criteria whether the incident is significant. The rationale is documented.
- 3
Send the early warning
If significant, within 24 hours via the competent authority's reporting portal. Better early with little information than too late.
- 4
Handle the incident
Contain, preserve evidence, restore systems. In parallel collect information for the incident notification.
- 5
Incident notification
Within 72 hours submit the initial assessment with severity, impact and indicators.
- 6
Final report
At the latest one month after the incident notification, fully describe cause, measures and impact.
- 7
Learn
Eliminate causes through corrective actions, update the risk assessment and continuity plans.
Example: timeline of a ransomware incident
| Time | Event | Reporting step |
|---|---|---|
| Monday 06:40 | Night shift reports that several production PCs are encrypted | Incident recorded, time of awareness noted |
| Monday 08:00 | Crisis team assesses: production halted, outage likely to last several days | Significance confirmed, rationale documented |
| Monday 11:30 | Initial analysis by the IT provider under way | Early warning to the authority: suspected malicious act, no known cross-border impact |
| Wednesday 15:00 | Attack vector identified, systems restored from backups | Incident notification with severity, impact and indicators |
| Wednesday 16:00 | Customers with delayed deliveries are informed | Information to recipients of services |
| Four weeks later | Forensics complete, measures implemented | Final report with root cause and mitigation |
The example shows that the early warning is sent long before the cause is known. What matters is that assessment and reporting path are prepared and the time of awareness is documented traceably.
Preparation: what must be in place before an incident
- Reporting process and roles: who assesses significance, who reports, who decides on communication? With deputies.
- Significance criteria: thresholds for downtime, affected users, data exfiltration and damage, tailored to your company.
- Access to the reporting portal: registration complete, credentials available to several people.
- Templates: text blocks for early warning, incident notification, customer information and internal communication.
- Contact list: IT providers, forensics, legal counsel, insurer, data protection officer – also available offline.
- Exercise: at least one tabletop exercise per year with a realistic scenario, including the report.
Use the NIS2 checklist to check whether these points are in place in your company.
What to document
| Item | Why |
|---|---|
| Time of detection and awareness | Start of the reporting deadlines |
| Significance assessment with rationale | Evidence for inspections, even when not reporting |
| Times and content of all reports | Proof of meeting deadlines |
| Measures taken | Basis for the final report and improvement |
| Root cause and lessons learned | Effectiveness of risk management |
From incident to improvement
Reporting is only part of the obligations. Article 21 of NIS2 also requires incident handling and assessing the effectiveness of risk management measures. Every significant incident should therefore lead to a structured review: which controls failed, which worked, and what do we change in technology, processes and training? The results belong in the risk assessment and the next management review.
Common mistakes
- Waiting for a complete analysis: the early warning doesn't need complete information – reporting too late is worse than too early.
- Unclear responsibility: in a crisis nobody knows who reports, or everyone waits for management.
- Missing access: credentials for the reporting portal sit with one person who cannot be reached.
- IT-only view: impact on customers, production and data protection is not assessed.
- No final report: after the incident is handled, the report is forgotten.
Recording incidents with docxpert
With NIS2 incident reporting you record security incidents centrally, assess severity and significance and see the deadlines for early warning, incident notification and final report at a glance. Actions and lessons learned are tracked through CAPA management. The report itself is submitted through the competent authority's portal.
Frequently asked questions
How quickly must a NIS2 incident be reported?
An early warning without undue delay, at the latest within 24 hours of becoming aware; the incident notification at the latest after 72 hours; and the final report at the latest one month after the incident notification.
Must every security incident be reported?
No, only significant incidents. The assessment should still be documented for every incident.
Who do I report to?
To the competent authority or national CSIRT in your member state – in Germany, for example, the BSI via its reporting portal.
What happens if I report too late?
Breaches of reporting obligations can be fined, and the supervisory authority can issue orders. A documented, traceable assessment protects you against accusations.
Does the NIS2 report replace the GDPR breach notification?
No. If personal data is affected, a notification to the data protection authority within 72 hours is also required. Both reports should be coordinated.
What goes into the early warning?
Essentially that a significant incident has occurred, whether it is suspected to be unlawful or malicious and whether cross-border impact is possible.
Do I also have to inform customers?
Where applicable, yes – recipients of your services must be informed without undue delay if the incident is likely to affect the provision of the service.
Can docxpert report directly to the authority?
No. docxpert supports recording, assessment, deadlines and documentation; the report is submitted through the authority's portal.
What information should I preserve during the first assessment of a potentially significant incident?
Record when the organisation became aware of the possible incident and who received the information. Describe affected systems or services, initial impacts on availability, confidentiality or integrity and any known signs of malicious activity. Separate confirmed facts from assumptions and mark details still missing. Document who assessed significance against your criteria and why; the assessment may change as more evidence arrives. Preserve relevant logs and communication records without obstructing the response. In parallel, owners should check whether other duties, such as a privacy notification, may apply. Do not wait for a complete root cause analysis before checking deadlines. A clear timeline allows later updates and shows what information supported the initial decision.