An incident response plan that survives the 24-hour clock
Most incident response plans are written for a technical audience and tested against a technical failure. That was enough until October 2024. It is not enough now.
Since NIS-2 came into force, an incident at an essential or important entity starts two processes at once. One is the response you already know: contain, eradicate, recover. The other is a regulatory clock that runs whether or not anyone in the room is watching it — 24 hours to an early warning, 72 to a notification, one month to a final report.
The second process is where organisations fail. Not because the deadlines are unreasonable, but because nobody in the response team is looking at a calendar while the servers are down.
This article gives you a working incident response plan structure, and it is organised around that problem. Everything here is written to be used at three in the morning by someone who did not write it.
In a hurry? The NIS-2 Compliance Suite already contains this procedure written out, with the five Article 23 submissions pre-drafted and the post-incident review form. Editions from €390. If you would rather check where you stand first, the free gap assessment takes ten minutes.
What your plan has to do in 2026
An incident response plan is not documentation of your security posture. It is an operational instrument with four jobs.
Be findable under pressure. If your plan lives on the file server that ransomware just encrypted, you do not have a plan. Keep an offline copy, a printed copy, or a copy in a second cloud tenant.
Remove decisions from the moment of crisis. Every decision you have not made in advance is a decision someone will make badly at speed. Who declares an incident. Who can shut down production without asking. Who talks to the regulator.
Start the notification clock deliberately. Article 23 of the directive requires an early warning within 24 hours of becoming aware that an incident is significant. Awareness is a moment. If nobody records it, you will be reconstructing it from memory when the authority asks.
Produce a record as it goes. A response reconstructed afterwards is the weakest evidence you can offer, and the final report you owe in a month depends on notes taken while the incident was live.
Incident handling is one of the ten risk-management measures required by Article 21(2). It is the only one with a statutory deadline attached, which is why it fails differently from the others.
The six phases, and where teams lose time
The response cycle has been stable for twenty years. What changed is what runs alongside it. ENISA’s technical implementation guidance treats incident handling as one of thirteen areas that must be documented, tested and evidenced — and requires it to be coherent with your business continuity arrangements, not written in isolation.
1. Prepare
Everything that must exist before anything happens: named roles, the contact list, an out-of-band communication channel, the retainer with an external responder if you have one, and the logging that will let you reconstruct events.
The preparation failure we see most often is not technical. It is that nobody has been told they are on the response team. A name in a document its holder has never read is not a role.
2. Detect
Detection comes from monitoring, staff, customers, suppliers, and sometimes law enforcement. All of those routes need to arrive in the same place.
Set one rule: anyone reports anything, the same day, whatever the apparent severity. If the person who notices has to judge whether an event is serious before reporting it, they will under-report — and your 24-hour clock will already have been running for a day when someone finally escalates.
3. Contain
Stop the spread. Isolate the affected systems, revoke the compromised credentials, block the traffic.
Two rules make containment work:
- Containment does not require authorisation. Restoring service does.
- Preserve evidence before you remediate. Once a machine is rebuilt, what happened on it is gone.
4. Eradicate
Remove the cause. Close the vulnerability, remove the persistence, rotate every credential the attacker could have seen.
Recovery before eradication reinstates the compromise. It is the most expensive ordering mistake in this list, and it happens because business pressure to restore service arrives long before the investigation is finished.
5. Recover
Bring the service back, in a controlled sequence, watching for signs that the problem is still present. The recovery time objective you agreed in your business impact analysis is the number you are being measured against now.
6. Review
Within a month of closure, hold a post-incident review. What happened, how long each phase took, what worked, what did not, and what changes as a result.
A review that produces no action has not been held.
Severity classification
Internal severity drives the response. Regulatory significance is a separate decision.
Internal severity drives your response. It is not the same as regulatory significance, and conflating the two is a common and costly error.
| Severity | Meaning | Response | Escalation |
|---|---|---|---|
| Critical | Core service unavailable or compromised; confirmed intrusion; data integrity in doubt | Immediate, full team | CISO and management at once |
| High | Significant degradation, contained intrusion, sensitive data exposure | Same working day | CISO |
| Medium | Limited impact, no service effect | Within two working days | Incident manager |
| Low | No impact; near miss | Recorded and reviewed | Trend review |
Set your own thresholds, but set them in advance and write them down. A severity scale invented during an incident is a justification, not a classification.
Record near misses too. The difference between a near miss and an incident is frequently luck, and the near miss is the one you can learn from without paying for it.
Who decides an incident is significant
Which test applies depends on what kind of entity you are — and the CIR thresholds prevail where they apply.
This is the section most incident response templates do not have, and it is the one that decides whether you meet the 24-hour deadline.
Under Article 23(3), an incident is significant if it:
- has caused or is capable of causing severe operational disruption of the services or financial loss for the entity; or
- has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Two things in that wording matter more than they first appear.
Capable of causing means you do not wait for the harm. An incident contained before it caused any disruption can still be significant. The test is what it could have done, not what it did.
And both limbs are alternatives. You do not need severe disruption and harm to third parties. One is enough.
If you are a digital infrastructure or digital service provider
Commission Implementing Regulation (EU) 2024/2690 applies directly across the Union — no national transposition, identical in every Member State — to specified entity types: DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery networks, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers.
For those entities, Articles 3 to 14 set specific, measurable thresholds per entity type. They replace judgement with numbers, and they prevail. If you fall in that group, your significance test is in that regulation, not in a paragraph you wrote yourself.
Name the person
Whatever your test, one thing has to be true: a named individual, with a named deputy, is authorised to declare an incident significant.
Teams lose hours of the 24-hour window debating whether an event qualifies. Those hours are not recoverable. Decide who decides, before you need them.
And record the moment of awareness to the hour, with the facts known at that moment. Every deadline below runs from it.
The notification timeline
The five submissions of Article 23(4). Awareness is the point zero, and it is recorded to the hour.
Article 23(4) sets five submissions. All periods run from awareness.
| Submission | Deadline | What it must contain |
|---|---|---|
| Early warning | Within 24 hours | Whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact |
| Incident notification | Within 72 hours | An update to the early warning, with an initial assessment of severity and impact, and indicators of compromise where available |
| Intermediate report | On request | Relevant status updates, if the CSIRT or authority asks |
| Final report | Within 1 month | Detailed description, severity and impact; the threat type or root cause; mitigations applied and ongoing; cross-border impact where applicable |
| Progress report | If still ongoing at one month | Status; the final report then follows within one month of handling being completed |
Three practical points make the difference between meeting these and missing them.
Incomplete on time beats complete late. The early warning is an alert, not a report. Submit what you know at hour 23 and correct it at 72.
The clock does not stop because you are busy recovering. The 24-hour early warning is the most commonly missed obligation during a real incident, and it is missed precisely because everyone competent is working on the outage. Assign the notification to someone who is not doing technical recovery.
Filing early buys you help. Under Article 23(5) the CSIRT or competent authority must respond without undue delay, and where possible within 24 hours of receiving your early warning, with initial feedback and — if you ask — guidance on mitigation. Where the incident looks criminal, they also tell you how to report it to law enforcement.
Telling your customers
Separately from the authority, Article 23(3) requires you to inform the recipients of your services of significant incidents likely to adversely affect the provision of that service — and, where a significant cyber threat is involved, to tell them what measures they can take.
Coordinate the wording with what you told the regulator. Two different accounts of the same event in circulation is a supervision problem on top of an incident.
Pre-drafting the five submissions is an afternoon’s work — or none at all. The notification pack in the NIS-2 Compliance Suite has all five Article 23 submissions laid out with the required content per deadline, so at hour 22 you are filling in blanks.
Evidence preservation, before remediation
Everything in this section costs you fifteen minutes during an incident and saves you the final report.
Freeze before you fix. Export the relevant logs to a location outside the affected environment. Snapshot the systems where feasible. Record the versions and configuration in use at the time.
Record the timeline as it happens. Who noticed what, at what time, and what was done in response. Timestamps taken live are evidence; timestamps reconstructed later are recollection.
Synchronise your clocks. If your systems do not share a common time source, your incident timeline is a reconstruction and your 24-hour clock starts from a guess. This is a five-minute infrastructure job that nobody does until it costs them.
Retain logs longer than your detection lag. Article 19(1) requires providers to keep automatically generated logs, where under their control, for at least six months; Article 26(6) places the same duty on deployers. Seven days of retention is useless against an intrusion discovered after three weeks — which is the normal case, not the exception.
The post-incident review
Required by section 3.6 of the CIR Annex, and useful regardless of whether it is required of you. Hold it within a month of closure and cover six things.
- The timeline — occurrence to detection, detection to containment, containment to recovery.
- How it was detected — monitoring, staff, a customer, a supplier, or a third party. If it was anyone other than your monitoring, that is a detection failure whatever your dashboard says.
- Whether the deadlines were met — early warning at 24 hours, notification at 72.
- The root cause, not the proximate one — “phishing email” is a delivery method; the cause is what allowed it to succeed and go undetected.
- Whether the same weakness exists elsewhere — the second instance of the same defect is the most commonly missed finding in the whole discipline.
- The actions, with owners and dates, tracked to closure like any other corrective action.
The purpose is to change something. A review that allocates blame produces under-reporting next time, which is far more expensive than the incident you just had.
The plan, section by section
The fourteen sections. The four highlighted are the ones most plans leave out.
Here is what a working incident response plan contains. Adapt the wording; keep the structure.
- Scope and purpose — which services and systems this plan covers, and who it applies to.
- Roles — incident manager, technical lead, communications lead, legal, the person authorised to declare significance, and a deputy for each. Names, not job titles alone.
- Contacts — internal team, national CSIRT and competent authority, data protection authority, law enforcement, critical suppliers, incident response retainer, insurer. Held offline as well as online.
- Severity classification — the table above, with your thresholds.
- Detection and reporting — how events reach the team, and the same-day reporting rule.
- The response procedure — the six phases, with the specific actions for your environment.
- Significance assessment — the Article 23(3) test, or the CIR thresholds if they apply, and the named decision-maker.
- Notification workflow — the five submissions, with the content of each pre-drafted so that at hour 22 you are filling in blanks, not composing.
- Communication — who says what to staff, to customers, to the authority, to the press. One spokesperson.
- Evidence handling — what to preserve, where to put it, who has access.
- Recovery criteria — how you decide the incident is over, and who declares it.
- Post-incident review — the review template and where the actions are tracked.
- Testing — when the plan is exercised, and by whom.
- Version control — date, owner, approval, and the date of the last exercise.
Sections 3, 7, 8 and 10 are the ones most plans leave out — and they are the four that decide whether you meet the 24-hour deadline. If you write nothing else this quarter, write those.
Four things to do this week
If the plan above is more than you can build right now, these four are the highest return for the least effort.
Name the decision-maker. One person, one deputy, authorised to declare an incident significant. Put it in writing and tell them. Fifteen minutes.
Write the early warning in advance. Not the whole notification pack — just the 24-hour submission, with blanks where the facts go. Half an hour, and it is the deadline you are most likely to miss.
Find your CSIRT contact route. The address or portal your national authority expects, on file, in the plan. Ten minutes now; an hour of searching during an incident.
Check your log retention. If it is shorter than the time it typically takes you to notice an intrusion, extend it. This is the one that costs money, and the one that makes the final report possible.
The mistake to avoid
The most common failure is not a missing plan. It is a plan that has never been used.
An incident response plan that has not been exercised is a hypothesis. Run a tabletop once a year at minimum: pick an uncomfortable scenario, put the team in a room without their systems, and see who reaches for the contact list that is only stored on the intranet.
Exercise the scenarios that go badly, not the ones that go well. An exercise everyone passes has measured nothing.
Frequently asked questions
Do I need a separate incident response plan for NIS-2 and for GDPR? No, but the two notification routes run on separate clocks to separate authorities, and neither substitutes for the other. One plan, two workflows, both triggered from the same assessment step.
How long do I have to report a security incident under NIS-2? 24 hours for an early warning, 72 hours for the incident notification, and one month for the final report — all measured from the moment you become aware the incident is significant, not from when it occurred.
Who decides whether an incident is significant? You do, against the test in Article 23(3) — or, if you are a digital infrastructure or digital service provider covered by Commission Implementing Regulation (EU) 2024/2690, against the specific thresholds in its Articles 3 to 14. In either case, name the individual authorised to make the call before you need them.
What happens if we miss the 24-hour deadline? Missing the deadline is itself a compliance failure, independent of how well you handled the incident technically. Supervisory authorities can issue binding instructions, require remediation and impose administrative fines — for essential entities, up to at least €10 million or 2% of worldwide annual turnover, whichever is higher.
How often should the plan be tested? At least annually, and after any significant change to your services, systems or team. Test restoration as well as decision-making: a plan that reads well and cannot be executed is the worst of both.
Where to go next
Knowing what the plan should contain is one thing. Knowing where your organisation stands against all ten NIS-2 risk-management measures is another.
The free NIS-2 gap assessment asks twelve questions, one per obligation, and scores you measure by measure. It takes about ten minutes and tells you which obligations you can evidence today and which you cannot.
If you would rather start from a complete, written set, the NIS-2 Compliance Suite contains the incident procedure described here, a notification pack with all five Article 23 submissions pre-drafted, and the post-incident review form — as part of thirteen procedures covering all ten Article 21 measures. Editions start at €390.
Sources
Directive (EU) 2022/2555 and Commission Implementing Regulation (EU) 2024/2690 are available on EUR-Lex. ENISA’s Technical Implementation Guidance covers the thirteen areas of the Implementing Regulation Annex with evidence examples.