NIS2 Incident Register: What Should Be Documented Before an Audit

An Incident Register is not a substitute for incident detection. It is not a SIEM. It is not a SOC. It is not an official authority reporting portal. It is the governance record around incidents — showing how the organization captured, assessed, assigned, monitored, and followed through on incidents in a reviewable and reconstructable way.

Incident governance starts before external reporting

Many organizations think about incident documentation only when a reporting obligation is triggered. That is too late. Before an incident can be reported to an authority, the organization must understand whether it is relevant, what happened, which systems or services are affected, whether critical service delivery is impacted, which supplier dependencies are involved, who became aware, and what follow-up is required.

This requires structured internal documentation. A mature incident governance process does not begin with the final report. It begins with the first controlled record. The organization should be able to show that an incident was captured, assessed, assigned, monitored, and followed through in a reviewable way.

An Incident Register is not a detection system

An Incident Register should be clearly separated from technical security tooling. Security tools detect logs, alerts, anomalies, vulnerabilities, intrusions, endpoint events, network behavior, and suspicious activity. A SOC triages and responds to technical events. A SIEM correlates signals across systems. A ticketing tool coordinates remediation work.

A NIS2 Incident Register has a different purpose. It documents the governance layer around incidents. It shows how the organization records incidents, assigns ownership, assesses relevance, tracks reporting status, captures evidence, connects incidents to critical services, and preserves the follow-up path. EAB documents the governance record — it is never positioned as an incident detection or threat monitoring tool.

Why incidents need a governance record

An incident can create operational, legal, cybersecurity, data protection, management, supplier, and reporting implications. If the record is fragmented across tools and emails, the organization may struggle to explain what happened. Security may know the technical event. Legal may know the reporting concern. Management may know the business impact. IT may know the remediation steps. A supplier may hold critical evidence. Compliance may need a documented timeline. If these pieces are not connected, audit readiness becomes weak. A governance incident record gives the organization a structured view of the incident beyond the technical alert.

What should be documented in a NIS2 Incident Register

A strong Incident Register should capture the elements needed to reconstruct the governance history of the incident. This does not mean replacing technical logs — it means preserving the management and compliance record.

Incident title and description

The incident should have a clear title and description. The description should explain what happened in operational terms, not only in technical language. It should be understandable to security, compliance, management, auditors, and responsible owners.

Detected date

The record should show when the issue was detected. Detection may come from a security tool, employee report, supplier notification, customer complaint, internal monitoring, audit finding, or third-party alert. Detection time matters because it helps reconstruct the incident timeline.

Awareness date

The record should distinguish detected date from the moment the organization became aware in a governance-relevant sense. This distinction can matter because awareness may trigger internal assessment, escalation, or reporting review. A technical signal buried in logs is not always the same as accountable organizational awareness. The Incident Register should preserve this distinction.

Potential NIS2 relevance

Not every incident is NIS2-relevant. But potential relevance should be assessed and documented. The organization should record whether the incident may affect critical or important services, cybersecurity risk, service continuity, network and information systems, supplier dependency, or other governance-relevant areas. If the incident is not considered NIS2-relevant, the rationale should be documented.

Severity, affected service, and responsible owner

The record should include a severity assessment reflecting business impact, service disruption, data impact, security impact, supplier dependency, scope, duration, and management concern — not only a technical score. The incident should be connected to the relevant service where possible. Every incident record needs an owner. An unowned incident is a governance weakness. The owner may not personally fix the technical issue, but they are responsible for ensuring the incident is assessed, followed up, documented, and closed from the governance perspective.

Reporting status

The register should show whether reporting review is open, not required, in progress, documented, submitted externally, closed, or still under assessment. This is not the same as technical incident status. A technical issue may be remediated while reporting assessment remains open. The reporting status must therefore be tracked separately.

Evidence notes and follow-up actions

The register should capture what evidence exists and where it can be found — logs, screenshots, supplier notifications, internal tickets, forensic notes, customer communications, management decisions, legal reviews, or remediation evidence. The register does not need to become a full evidence repository, but it should make the evidence state visible. Follow-up actions should show what needs to happen next: technical remediation, supplier review, management escalation, reporting assessment, evidence collection, policy update, or lessons learned. A documented incident without follow-up logic is incomplete governance.

Incident lifecycle and reporting status must be separate

One of the most important design principles is the separation between incident lifecycle status and reporting status. An incident may be technically closed but still open for reporting review. It may be operationally resolved but still missing evidence. It may be internally documented but still awaiting management approval. It may be low technical severity but relevant for supplier governance. It may be high operational impact but not externally reportable.

If everything is collapsed into one status, the organization loses clarity. The Incident Register should distinguish: the technical or operational lifecycle; the NIS2 relevance assessment; the reporting status; the evidence state; the follow-up status; and management review. This distinction is essential for audit readiness.

Why reporting status matters before reporting

Reporting status should not appear only when the organization is ready to submit something. It should exist from the moment the incident enters governance review. The organization should be able to show whether reporting relevance was assessed, who reviewed the question, what information was available, whether the status changed, why reporting was considered not required or required, which evidence supported the conclusion, and whether follow-up documentation was completed.

This protects the organization from retrospective reconstruction. If an auditor later asks why an incident was not reported, the organization should not have to rely on memory. It should have a recorded rationale.

Supplier-related incidents need explicit linkage

Many incidents involve suppliers. A cloud outage, SaaS breach, managed service failure, software vulnerability, hosting disruption, processor incident, or third-party security event may affect the organization's critical services. The Incident Register should therefore allow supplier linkage — showing which supplier was involved, which critical service depended on that supplier, what notification was received, which evidence the supplier provided, what follow-up was required, and whether supplier risk status changed.

This connects incident governance to supplier governance. It also prevents supplier incidents from being treated as external events with no internal ownership. If a supplier affects a critical service, the organization still needs governance visibility.

Incidents can connect to GDPR and AI governance

NIS2 incident governance may overlap with other compliance areas. If personal data is involved, the incident may also become relevant for GDPR assessment. If an AI system supports a critical service, incident handling may connect to AI governance. If an AI vendor or model provider creates a service dependency, supplier risk may link to AI system governance. If cybersecurity controls relate to an AI system, evidence may support both NIS2 and AI Act governance. This is why incident records should not live in isolation — a governance platform should make these connections visible where relevant.

Why an Incident Register matters before an audit

Audits often ask for more than final reports. They may ask how incidents are identified, recorded, assessed, assigned, escalated, reviewed, closed, and evidenced. They may ask whether the organization has visibility over open incidents. They may ask whether reporting relevance was assessed, whether critical services were affected, whether supplier dependency was involved, whether management had visibility, and whether follow-up actions were completed. A structured Incident Register allows the organization to answer these questions without reconstructing the past manually. It creates a point-in-time governance record.

How EAB structures the NIS2 Incident Register

In EAB, the NIS2 Incident Register is part of the Cybersecurity Governance and Evidence Module — not a SIEM, SOC, scanner, or official reporting portal. The register documents potentially relevant incidents in a structured governance context. It captures incident title, description, detected date, awareness date, potential NIS2 relevance, severity, impact summary, reporting status, responsible owner, evidence notes, status, responsible legal entity, affected critical service, and supplier linkage where relevant.

The record connects to Critical Services, Supplier Risks, Responsibilities, Evidence and Gap Tracking, Action Inbox, and Reports. This allows the organization to see not only that an incident occurred, but how it was governed. The purpose is clear: document the governance record around incidents before an audit asks for it.

For a broader view of how the NIS2 governance framework connects critical services, security measures, and supplier dependencies, see the guide on NIS2 Governance Readiness.