NIS2 incident response plan

The plan has to get a 24-hour early warning out the door. Article 23 requires an early warning without undue delay and in any event within 24 hours of the entity becoming aware of a significant incident. That clock starts at awareness, not at the moment someone finishes triage, so the plan must tell responders what counts as awareness and who decides when a suspected event becomes a reportable one. Write the trigger conditions into the incident categorization system, name a single owner for the significance decision (usually the incident commander or a designated reporting lead, with a named deputy), and attach a short early warning template to the escalation chart. Responders should be able to fill it from the first triage call without waiting for root cause. Confirm with your national competent authority or CSIRT which channel and format they accept, and rehearse that submission path before you need it.

Significance is not always visible in a single event. Article 4 of Implementing Regulation (EU) 2024/2690 treats incidents that are individually not significant as one significant incident when they occur at least twice within 6 months, share the same apparent root cause and together meet the financial loss threshold. A plan that only tests single incidents will miss this pattern. Add a recurring-incident check to the event assessment step, record apparent root causes consistently in the incident log, and assign an owner to review recurring incidents on a quarterly basis, as points 3.4.2(b) of the Annex require. Treat that quarterly review as a standing agenda item in the plan, not an ad hoc task, so a pattern can trigger the 24-hour clock before the second event closes out. Read the NIS2 incident reporting process for the full sequence from detection to final report, including the 72-hour notification and the one-month final report.

The core requirement is simple to state: after a significant incident, the entity must identify the root cause where that is possible, and record what it learned in a documented form. Implementing Regulation (EU) 2024/2690 frames this as a post-incident review, and the wording "where appropriate" and "where possible" means the review is expected to be proportionate, not that every incident needs a forensic investigation. The dated review record is the artifact that matters most. It should state the incident identifier, the date the review took place, the participants, the root cause or a clear statement that it could not be determined, the timeline reconstructed from logs, and the lessons learned, each with a named owner and a due date. A review that ends in a general statement such as "we will be more vigilant" will not satisfy an assessor.

The findings then have to change the plan itself. Ask the review to answer four questions: did the incident fit an existing category in the categorization system, did the runbook for that category contain the steps the responders actually needed, did the contact lists reach the right people at the right time, and did the reporting communication plan allow the 24-hour early warning and 72-hour notification to be met. Each gap should produce a visible change, such as a revised category definition, an updated escalation chart, a corrected phone number or a revised template for the early warning. Keep a change log with version numbers and approval dates so an assessor can see the plan was revised after the incident, not just described as improved. Also confirm that recurring patterns feed the quarterly assessment of recurring incidents, since a root cause that appears twice may be a significant incident under Article 4 of the implementing regulation.

The most common failure is a plan that names no one to make the reporting decision. Assessors look for a single accountable role, with a named deputy, who decides whether an event is a significant incident and starts the clock for the early warning. To check this, ask the incident lead to state, without looking at the document, who makes that call at 2 a.m. on a weekend and what they must record. If the answer depends on who is available, the plan has a gap. Another frequent gap is the absence of a clear 24-hour trigger in the escalation chart. The plan should say when the 24-hour period starts, how quickly an analyst must escalate to the decision owner, and which template is used for the early warning. Walk through a tabletop scenario and time how long it takes to reach the decision owner.

Contact lists and supplier terms fail more often than people expect. A list that was accurate last year, with former staff, departed vendors or unmonitored mailboxes, will not support a 24-hour report. Confirm each contact against the current HR and contract records, test the national CSIRT or competent authority channel, and record the date of the last check on the list itself. Supplier gaps are equally common: if the contracts with managed service providers and cloud providers contain no obligation to notify the entity of incidents affecting its services, the entity may learn of an event too late to meet its own deadlines. Check each supplier contract for a notification duration and a named contact, and confirm that the plan lists how staff and suppliers can report suspicious events.

Plans also fail when containment is written as a separate step from recovery. Assessors expect the procedures to show how containment decisions affect eradication, restoration and the security of systems during a crisis, including what must stay isolated and who approves restoring service. Finally, a plan that has never been exercised is unlikely to pass. The implementing regulation expects response procedures to be tested at planned intervals, and post-incident reviews should produce documented lessons learned with the root cause identified where possible. Look for a dated exercise record, the findings raised and the changes made to the plan afterwards. Without that trail, the plan is a document rather than evidence, and reviewers will treat it as untested.