What should a NIS2 incident register contain?
A NIS2 Incident Register is the governance record around security incidents — not a SIEM, SOC dashboard, or notification portal. It captures the structured evidence of how incidents were detected, assessed, reported, responded to, and resolved.
The register must track the full incident lifecycle with separate fields for detection timeline, severity assessment, reporting status, response actions, root cause analysis, remediation, and responsible persons at each stage.
Key points
- NIS2 Art. 23 requires initial notification within 24 hours and a full incident report within 72 hours. The register must track both deadlines and actual reporting status.
- Incident lifecycle and reporting status are separate governance tracks. A resolved incident with incomplete reporting is still a compliance gap.
- Each incident record must identify affected services, severity classification, and the link to critical service mapping.
- The register must exist and be structured before an authority requests it. Retrospective assembly is not governance.
Why it matters
When a competent authority reviews an organization's NIS2 compliance, the incident register is one of the first things they examine. It demonstrates whether the organization has operational governance around incidents or is merely reacting to events. A well-structured register shows that the organization manages incidents as a governed process, not an ad-hoc response.
How EAB approaches this
The NIS2 Module includes structured incident recording with lifecycle tracking, reporting deadline monitoring, and service linkage. It connects to the Cybersecurity Governance layer to maintain the relationship between incidents, affected services, and security measures.