1. Reporting channels
Define where incident signals can enter and how they become a structured record.
- Security mailbox or queue for user and vendor reports.
- Dedicated Slack or Teams channel for urgent internal reporting.
- Web form or ticket form with required fields.
- SIEM, monitoring, EDR, or cloud alert ingestion path.
- Customer and supplier notification inboxes monitored by named owners.
- Regulatory or CSIRT reporting route, account access, and backup submitter.
2. Minimum triage fields
Every possible NIS2 incident should start with enough context to support severity, impact, and escalation decisions.
| Field | Why it matters |
|---|---|
| Time detected | Starts the operational timeline and helps determine reporting windows. |
| Detection source | Shows whether the signal came from a tool, user, vendor, customer, or review. |
| Affected asset or service | Clarifies scope, ownership, and business impact. |
| Initial impact | Supports significance assessment and management prioritization. |
| Indicators observed | Preserves facts without jumping to conclusions. |
| Actions already taken | Prevents duplicated work and supports the response record. |
| Current owner | Stops tickets from drifting during the first hour. |
| Evidence links | Keeps logs, screenshots, alerts, emails, and tickets connected to the record. |
3. Ownership and escalation
A checklist is weak if nobody owns decisions. Define roles before the incident.
- Incident commander or response owner.
- Technical investigation owner.
- Business service owner.
- Legal or compliance contact for reportability questions.
- Privacy contact for personal-data impact.
- Management sponsor for material business decisions.
- Customer communications owner.
- Supplier contact owner when a vendor system is involved.
4. Reporting decision points
The team should know when to ask whether a NIS2 notification, customer notice, privacy notification, contractual notice, or voluntary report may be needed.
Initial assessment
Ask whether service disruption, financial loss, material damage, malicious activity, or cross-border impact may be present.
24-hour early warning preparation
Prepare the facts available so far, the suspected nature of the incident, cross-border considerations, and contact details.
72-hour update preparation
Update severity, impact, indicators, containment steps, affected services, and ongoing actions.
Final report preparation
Capture root cause, final impact, mitigation measures, lessons learned, and corrective actions.
5. Evidence and RCA
Evidence should be preserved while the incident is active. RCA becomes weaker when teams try to rebuild the record from chat messages weeks later.
- Original alerts and detection details.
- Relevant log exports or query references.
- Screenshots of affected settings or systems where appropriate.
- Email headers or suspicious-message samples where safe and permitted.
- Access changes, containment actions, and recovery actions.
- Decision log with who approved what and when.
- RCA notes, contributing factors, corrective actions, owners, and due dates.
6. Management updates and post-incident review
Management needs enough information to make decisions without drowning in ticket details. Prepare a repeatable summary format.
- Current status and severity.
- Business services affected.
- Known and possible customer impact.
- Actions taken and next actions.
- Reporting or notification decisions under review.
- Resource needs and blockers.
- Lessons learned and control improvements after closure.
This checklist is general operational guidance. Adapt it to your sector, contracts, insurer requirements, national authority guidance, and legal advice.
Quick FAQ
What should a NIS2 incident checklist include?
It should include reporting channels, triage fields, ownership, escalation, evidence, management updates, regulatory decision points, RCA, corrective actions, and post-incident review.
Can an SMB use this checklist as a downloadable lead magnet?
Yes. It is structured as a practical checklist. The operational details should still be adapted to the organization's sector, systems, contracts, and national rules.
Why does evidence belong in the checklist?
Evidence supports significance assessment, response decisions, reporting updates, RCA, customer communication, and later review.
How does IncidentAI support this checklist?
IncidentAI can help structure tickets, preserve context, summarize updates, keep timelines cleaner, and draft RCA notes for human review.
Official sources used
These pages were used for factual grounding. aneo summarizes them in original wording and does not provide legal advice.