NIS2 Incident Response and Reporting Checklist

NIS2 incident readiness is not only about knowing where to report. The team also needs to create a reliable record of what happened, when it was detected, who assessed it, what evidence exists, which decisions were made, and how the incident is being contained and recovered.

Direct answer

Use a NIS2 incident response checklist to open one structured incident record, confirm the reporting channel and applicable deadline, capture detection and impact facts, assign an accountable owner, preserve evidence, escalate uncertainty, coordinate required notifications, maintain management updates, and complete a post-incident review.

The exact reporting threshold, authority, timing, and required information depend on the organisation’s sector, jurisdiction, role, and facts. Confirm those details against the applicable national implementation and professional advice. This guide is an operational planning aid, not legal advice.

Article 23 of the NIS2 Directive is the EU-level source for significant-incident reporting. It sets staged notifications, including an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report generally within one month of that notification. National rules, sector-specific requirements, and the incident facts determine the actual reporting path. The checklists below are Aneo’s suggested way to organise the work; they are not the text of the Directive.

Before an incident: prepare the operating model

Document these items before an incident creates time pressure:

• The person or role accountable for incident response
• The people authorised to make reporting and communication decisions
• The relevant national authority or sector reporting channel
• Internal escalation contacts and out-of-hours arrangements
• Customer, supplier, insurer, legal, privacy, and communications contacts
• The systems used for tickets, evidence, timelines, and approvals
• The definition and indicators used to assess significance
• The information needed for an initial notification and follow-up
• The review and exercise schedule

Contact details should be tested and reviewed. A reporting plan that exists only in a policy but has not been used or exercised may fail under pressure.

Use one incident record

Create one authoritative record for:

• Incident summary and current status
• Detection time and reporting source
• Affected systems, services, users, data, and locations
• Known impact and potential impact
• Severity and significance assessment
• Owner, contributors, and approvers
• Timeline, decisions, actions, and communications
• Evidence references and preservation steps
• Reporting status and submission history
• Open questions and next review time

Keep facts, assumptions, and decisions distinguishable. A changing assessment is normal; an undocumented change is difficult to defend or explain.

Initial response checklist

Intake and triage

• Open an incident record as soon as the signal may require coordinated response
• Record what was observed and how it was detected
• Record the first known time and the time the organisation became aware
• Identify affected assets, services, accounts, users, and data
• Separate confirmed facts from assumptions and unknowns
• Assign a preliminary severity and confidence level
• Identify whether the activity is active, contained, or still spreading

Ownership and escalation

• Assign one accountable incident owner
• Identify technical, business, security, privacy, legal, and communications contributors
• Confirm who can approve containment and external communication decisions
• Escalate when privileged access, sensitive data, critical services, or multiple customers may be involved
• Set the next update time and the people who need it
• Record every material handoff and decision

Evidence

• Preserve relevant logs, tickets, alerts, messages, configurations, and files
• Record the source, timestamp, scope, and custodian for important evidence
• Avoid altering or deleting evidence during investigation
• Restrict access to sensitive incident records
• Record evidence gaps and the action needed to close them
• Maintain an ordered timeline of facts and decisions

Reporting decision checklist

The response owner and authorised decision makers should assess:

• Whether the event meets the organisation’s definition of an incident
• Whether the incident may meet the relevant significant-incident criteria
• Which services, systems, data, users, customers, or suppliers are affected
• Whether the incident caused or may cause substantial operational disruption
• Whether financial, reputational, physical, or other material harm is possible
• Whether the incident involves a supply-chain dependency
• What is known, unknown, and still being investigated
• Which authority, customer, insurer, or other party may need communication
• Which deadline, format, language, and channel apply
• Who approves the reporting decision and the submitted information

Do not delay a required early notification because every detail is not yet known. Do not submit unsupported claims simply to appear complete. Record the information available, the confidence level, and the planned follow-up.

Organise the reporting information

The exact form varies by authority, but a prepared record commonly needs:

Use the authority’s required channel and format. Keep the submission, approval, timestamp, recipient, and any response in the incident record.

Management update structure

Management updates should support decisions rather than repeat the entire investigation. A concise update can include:

1. What happened and when it was detected
2. Current severity and confidence
3. Affected services, systems, data, and customers
4. What the team has done
5. What remains unknown
6. Reporting and communication status
7. Decisions needed from management
8. Next update time

Avoid false certainty. “No customer impact is confirmed at this time; investigation continues” is more useful than an unsupported conclusion.

During containment and recovery

Record:

• The reason for each material containment action
• The person who approved or performed it
• Expected and observed effects
• Dependencies or risks introduced by the action
• Evidence captured before and after the change
• Recovery validation and service owner confirmation
• Any communication made to affected parties

Containment may reduce immediate harm but can also affect evidence or business operations. Coordinate actions with the people who understand the system and record the trade-offs.

Closure and post-incident review

Do not close the record only because the alert stopped. Confirm:

• The incident scope and impact are understood as far as reasonably possible
• Containment and recovery actions are complete or transferred to tracked work
• Required reporting and follow-up communication are recorded
• Evidence and decisions are retained appropriately
• Customers, suppliers, insurers, or authorities have received agreed updates
• Corrective actions have owners and target dates
• A post-incident review is scheduled when severity or learning requires it
• Related controls, policies, risks, and evidence registers are updated

Common NIS2 readiness mistakes

Preparing only the reporting form

A form does not create facts, evidence, ownership, or decision history. Build those into the response workflow.

Waiting for perfect certainty

Use preliminary assessments, confidence levels, and follow-up updates. Do not allow uncertainty to become inaction.

Ignoring suppliers and dependencies

An incident in a supplier or cloud service may affect your own service, customers, evidence, and reporting decisions.

Treating the deadline as the whole process

Timely reporting matters, but so do accurate records, continued coordination, impact assessment, and follow-up information.

Leaving decisions in chat

Important decisions made in Slack, email, or calls should be summarised in the incident record with the decision maker and time.

Where IncidentAI fits

IncidentAI helps teams structure reports from tickets or email, enrich incidents with asset and user context, maintain timelines, suggest triage and next steps, prepare summaries, and draft RCA notes. Humans remain responsible for verifying facts, assessing significance, approving notifications, and making legal or operational decisions.

For broader context, see the NIS2 compliance and incident readiness guide and the security incident response first-hour checklist.

Frequently asked questions

What should an organisation prepare for NIS2 incident reporting?

Prepare reporting contacts and channels, incident ownership, significance criteria, detection timestamps, impact information, evidence handling, approval roles, management updates, and a process for follow-up reporting.

Does every security alert need to be reported?

No. An alert, event, and reportable incident are different things. The organisation needs a documented process to assess whether the facts meet the applicable incident and reporting criteria.

What if the organisation does not know the full impact yet?

Record what is known, what is uncertain, and what is being investigated. Follow the applicable reporting process and provide additional information through the required channel when the facts develop.

Who approves a NIS2 incident report?

The organisation should define authorised roles before an incident. The appropriate approver depends on the entity, sector, incident facts, internal governance, and applicable national requirements.

How can a small team exercise its NIS2 response process?

Run a short scenario using a realistic alert, test the intake and escalation path, confirm reporting contacts, create a timeline, make a mock significance decision, and record the improvements.