Computer Security Incident Response Plan Template: The 6 Sections CIR Annex 3 Expects — and What NIST Leaves Out

Search “computer security incident response plan template” and every result hands you the same skeleton: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. That structure comes from NIST SP 800-61 Revision 2 — a document NIST itself superseded in April 2025 [3].

For an entity inside the EU there is a second, more expensive problem. The phrase “Computer Security Incident Response” appears exactly once in Commission Implementing Regulation (EU) 2024/2690, the regulation that specifies what NIS2 incident handling actually means. It appears in point 3.5.3(a) of the Annex, as the name of the team you have to notify — not the plan you have to write [1]. The plan is specified somewhere else: Annex point 3, six sub-sections, thirty-four instances of the word “shall” and not a single “should”.

This guide names those six sections, shows which parts of your NIST-shaped document already satisfy them, and marks the four requirements that document almost certainly has no home for.

Which Rulebook Actually Binds You

In plain terms: there are two tracks. If you run cloud, DNS, a data centre, an online marketplace, an MSP or MSSP, or you are a trust service provider, one EU regulation dictates the content of your incident plan directly. If you are a hospital, a utility, a manufacturer or a transport operator, that regulation is not binding on you — but it is the only document in which the Commission has written down what it thinks “incident handling” means, so it is what your auditor will be reading.

CIR 2024/2690 was adopted under Articles 21(5) and 23(11) of NIS2 and entered into force on 7 November 2024. It is a regulation, not a directive: directly applicable, no national transposition, and limited to the eleven categories of entity listed in its Article 1 [1].

Track	Who	What Annex point 3 is to you
A — directly bound	DNS providers, TLD registries, cloud providers, data centre providers, CDN providers, MSPs, MSSPs, online marketplaces, search engines, social networking platforms, trust service providers	Binding law. Every “shall” in points 3.1–3.6 is an obligation, and every “where appropriate” you decline to apply triggers a documentation duty under Article 2(2).
B — bound by Article 21(2)(b), not by the CIR	Energy, transport, banking, health, water, public administration, manufacturing, food, chemicals, waste, postal, research	Not directly binding. It is the Commission’s own specification of the same obligation, built on ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319 401 — the expected standard of care until your member state publishes its own.

Track A entities that build to a generic NIST template fail on requirements that framework never contemplated. Track B entities that build to the full CIR without recording why are buying controls nobody asked them for.

The Six Sections Annex Point 3 Expects

Point 3 of the Annex implements Article 21(2)(b) of NIS2 and divides into six sub-sections. This is the section list your plan needs headings for [1].

Annex point	Section heading	What the document has to contain
3.1	Incident handling policy	Roles, responsibilities and procedures for detecting, analysing, containing, recovering, documenting and reporting. Must be coherent with the business continuity and disaster recovery plan at point 4.1, and must include a categorisation system, escalation and reporting communication plans, named competent role holders, and the working documents: response manuals, escalation charts, contact lists, templates.
3.2	Monitoring and logging	Detection procedures and tools, the asset-to-log list derived from your risk assessment, twelve categories of log content, alarm thresholds and the response they trigger, retention for a predefined period, and protection of logs from unauthorised access or change.
3.3	Event reporting	A simple mechanism through which employees, suppliers and customers can report suspicious events, communicated to suppliers and customers where appropriate, with employees trained on it regularly.
3.4	Event assessment and classification	Predefined criteria and a triage setting containment priority, quarterly assessment of whether incidents are recurring within the meaning of Article 4, log review, a log correlation process, and reassessment when new information arrives.
3.5	Incident response	Documented procedures for containment, eradication and recovery where necessary; communication plans with the CSIRT or competent authority and with internal and external stakeholders; logging of response activity and recording of evidence; testing at planned intervals.
3.6	Post-incident reviews	Reviews after recovery identifying root cause where possible, documented lessons learned, a mechanism feeding those into risk treatment and detection procedures, and a periodic check that incidents actually led to reviews.

Two of the six rarely exist as sections in a downloaded template. Point 3.3 is one: a reporting channel open to customers and suppliers, not just staff, is a public-facing commitment with an owner and a service level. Point 3.4.2(b) is the other, and it carries real exposure. Under Article 4, incidents that individually miss the significance bar count collectively as one significant incident where they occurred at least twice within six months, share the same apparent root cause, and together exceed the threshold in Article 3(1)(a) — direct loss above EUR 500 000 or 5 % of the previous year’s turnover, whichever is lower [1]. The quarterly recurrence review is the control that stops four unreported nuisances from becoming one unreported notifiable event.

Note also that 3.1 is a policy requirement and 3.5 a procedure requirement. One document can do both jobs, but governance and runbook answer to different reviewers on different cycles — a distinction worth resolving before an audit resolves it for you. We have covered where the policy, the plan and the playbook divide in detail.

What Your NIST-Shaped Template Already Covers — and the Four Gaps

Start from the document you have rather than a blank page. Most of the NIST structure maps cleanly onto Annex point 3; the value is in seeing precisely where it does not.

CIR Annex point	Home in a four-phase template	CSF 2.0 Function under SP 800-61r3	Verdict
3.1 Incident handling policy	Preparation	Govern, Identify, Protect	Mostly covered. Missing: the explicit coherence link to the BC/DR plan.
3.2 Monitoring and logging	Detection and analysis	Detect	Covered in principle. Missing: the asset-to-log list tied to the risk assessment, and the twelve enumerated log categories.
3.3 Event reporting	Nowhere	Detect (partially)	Gap. The supplier and customer channel has no equivalent in the NIST model.
3.4 Event assessment and classification	Detection and analysis	Detect	Partly covered by triage. Gap: the quarterly recurring-incident assessment.
3.5 Incident response	Containment, eradication and recovery	Respond, Recover	Well covered. Gap: the statutory notification clock.
3.6 Post-incident reviews	Post-incident activity	Identify (Improvement)	Covered. Sharpen root-cause and lessons-learned wording to match the regulation’s terms.

Four gaps, then: the supplier and customer reporting channel, the quarterly recurrence check, the Article 23 clock, and the exceptions register two sections below. None is exotic. All four were absent from the NIST-derived templates we reviewed on this search term, which is what you would expect: they are EU obligations, and NIST was not writing for them.

A note on the framework itself. SP 800-61r3, published April 2025, supersedes Revision 2 and replaces the four-phase circular lifecycle with a model built on the six CSF 2.0 Functions — Govern, Identify, Protect, Detect, Respond, Recover — because recovery now “often takes weeks or months” and lessons should feed back continuously rather than after closure [3]. Revision 3 does not forbid the old model; it says organisations “should use the incident response life cycle framework or model that suits them best”. But if your plan cites SP 800-61 as its authority, cite the current revision. ENISA’s own final guidance of June 2025 points to r3 in its section 3.1 footnote while its section 3.5 and section 4 footnotes still send readers to Revision 2 [4] — a drafting artefact rather than a trap, but worth knowing before you copy a citation out of a guidance document.

The Reporting Clock Belongs Inside the Plan

In plain terms: the notification deadlines are not a compliance annexe. They are operational instructions that fire during the worst hours of the incident, and they belong in the runbook next to the containment steps. Article 23(4) of NIS2 sets the sequence [2].

Deliverable	Deadline	What it must contain
Early warning	Without undue delay, in any event within 24 hours of becoming aware	Enough for the CSIRT to act; where applicable, whether unlawful or malicious cause is suspected and whether cross-border impact is likely.
Incident notification	Within 72 hours of becoming aware Trust service providers: within 24 hours	Updates the early warning; initial assessment of severity and impact; indicators of compromise where available.
Intermediate report	On request of the CSIRT or competent authority	Relevant status updates.
Final report	Not later than one month after the incident notification	Detailed description with severity and impact; type of threat or likely root cause; applied and ongoing mitigation; cross-border impact where applicable.
Progress report	At the one-month mark, if the incident is still running	Status; the final report then follows within one month of finishing the handling.

The derogation in the second subparagraph of Article 23(4) is the line most templates miss: for significant incidents affecting its trust services, a trust service provider owes the full incident notification at 24 hours, not 72 [2]. If you issue qualified certificates or timestamps, your plan has one deadline where everyone else has two.

Two drafting points. The clock starts on becoming aware, not on confirmation — which is exactly why the point 3.3 channel matters, since a customer’s report can be the moment of awareness. And Article 23(1) states that the mere act of notification shall not subject the notifying entity to increased liability [2]. Put that sentence in the plan; it settles the argument that stalls the 24-hour decision. The deadlines also imply internal ones the Directive never names: building the plan backwards from the 72-hour form sets those out. For the judgement call itself, work through the five questions that settle significant versus non-significant, and the wider NIS2 incident reporting requirements.

The Exceptions Register Nobody Builds

Article 2(2), second subparagraph, of CIR 2024/2690 says that where the Annex applies a requirement “where appropriate”, “where applicable” or “to the extent feasible”, and a relevant entity considers it not appropriate, not applicable or not feasible, that entity “shall in a comprehensible manner document its reasoning to that effect” [1]. The conditional wording is not an exemption. It is a shift from doing the thing to justifying, in writing, why you did not — and it is the register an auditor can ask for on day one.

Counting that wording across Annex point 3 gives ten instances: seven “where appropriate”, one “where applicable”, two “to the extent feasible”. Nine are genuine entity discretion; the tenth, in point 3.5.3(a), is a jurisdictional pointer rather than a choice. Six of the nine sit inside point 3.2 alone.

Annex point	The conditional requirement
3.1.3	Updating roles, responsibilities and procedures after testing, incidents or significant change
3.2.2	Automating monitoring, to the extent feasible
3.2.3	Including each of the twelve enumerated log categories
3.2.4	Setting alarm threshold values
3.2.4	Triggering the alarm automatically
3.2.6	Synchronising time sources across systems, to the extent feasible
3.2.7	Updating the procedures and the logged-asset list
3.3.2	Communicating the event reporting mechanism to suppliers and customers
3.6.1	Carrying out a post-incident review after recovery

A workable register is one table: the point, the decision, the reasoning, the date, the approver, the review date. Three lines of honest reasoning per row will do more in a supervisory conversation than a policy that silently claims full conformity.

Ownership, Effort, and the Evidence Each Section Produces

ENISA’s Technical Implementation Guidance v1.0 (June 2025) mirrors the CIR Annex and lists, per requirement, examples of evidence an auditor may look for. It is non-binding guidance, not law, but it is the closest thing to a published marking scheme [4].

Section	Owner	Effort	Evidence it must produce
3.1 Policy	CISO, approved by the management body	Medium	The documented policy containing at least the 3.1.2 elements; cross-references to the BC/DR plan; records of drills covering both.
3.2 Monitoring and logging	SOC or MSSP	High	Logged-asset list traceable to the risk assessment; retention and protection settings; threshold and alarm configuration.
3.3 Event reporting	Service desk plus supplier management	Low	The documented mechanism; evidence of multiple channels; training material; staff who can name the channel when asked.
3.4 Assessment and classification	Incident manager	Medium	Written criteria; the categorisation system; minutes of the quarterly recurrence assessment.
3.5 Response	Incident response lead	Medium	Per-type procedures; the response log with detection, containment, eradication and recovery times, IoCs, root cause and whether Article 23 notification was made; test records.
3.6 Post-incident review	CISO with the risk owner	Low	Review reports; documented lessons learned; proof they fed the risk treatment plan.
Exceptions register	Compliance officer	Low	The register itself, dated and approved.

ENISA suggests testing and reviewing the roles, responsibilities and procedures at least annually, and testing the incident response procedures at least annually with the management body taking part [4]. Those cadences are recommendations, not deadlines — but they are the cadences a supervisor has read. The cheapest way to satisfy 3.1.3 and 3.5.5 together is one annual exercise producing a single dated artefact for both; a structured tabletop with a scoring rubric does this without taking systems offline. If logging is your weak section, the retention windows and detection rules under point 3.2 deserve a separate pass.

A gap analysis is then three columns: what your plan says now, what the Annex point requires, and the effort to close it. Anything in the middle column with an empty left column is either work or a register entry — and deciding which is the whole exercise.

Frequently Asked Questions

Is a NIST-based incident response plan acceptable under NIS2?
Neither NIS2 nor CIR 2024/2690 requires a particular framework, and the CIR’s technical requirements are built on ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319 401 rather than on NIST. A NIST-structured plan is a legitimate starting point; it becomes conformant when the six Annex point 3 topics are demonstrably covered and the EU-specific items are added.

How long must we retain incident logs?
Point 3.2.5 says logs shall be maintained and backed up “for a predefined period” and protected from unauthorised access or change. It sets no figure. The period is yours to define and justify, so the number belongs in your plan alongside the reasoning for it.

Does the CIR apply to us if we are a hospital or a utility?
Not directly. Article 1 limits it to eleven categories of digital and trust service provider. Article 21(2)(b) of NIS2 still binds you through your national transposition, and the CIR remains the Commission’s detailed reading of that obligation.

Is the plan one document or several?
The Annex does not prescribe a document count. Point 3.1 is governance, 3.5 is operational procedure, and 3.1.2(d) expects manuals, escalation charts, contact lists and templates alongside the policy. Most organisations end up with a policy, a plan and per-scenario playbooks, plus a cross-reference table proving the three are coherent.

What actually starts the 24-hour clock?
Becoming aware of a significant incident, not confirming one. Because point 3.3.1 obliges you to give employees, suppliers and customers a channel for suspicious events, awareness can arrive through it before triage is finished. The plan should name who has authority to declare awareness and log the timestamp.

Key Takeaways

• The section list is CIR 2024/2690 Annex point 3: incident handling policy, monitoring and logging, event reporting, event assessment and classification, incident response, post-incident reviews. Annex point 4 is business continuity, not incident handling.
• The regulation binds eleven categories of digital and trust service provider directly. For everyone else it is the benchmark an auditor reads, not binding law.
• A NIST-shaped template covers roughly four of the six. The reliable gaps: the supplier and customer reporting channel, the quarterly recurring-incident assessment, the Article 23 clock inside the runbook, and the exceptions register.
• Nine conditional requirements create a duty under Article 2(2) to document your reasoning when you do not apply them. Six of the nine are in monitoring and logging.
• Trust service providers notify at 24 hours, not 72.
• If your plan cites SP 800-61, cite Revision 3 — Revision 2 was superseded in April 2025.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal of the European Union (Articles 1–4 and Annex points 3.1–3.6).
• [2] Directive (EU) 2022/2555 (NIS2) — EUR-Lex, Official Journal of the European Union (Articles 21(2)(b) and 23).
• [3] NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile — National Institute of Standards and Technology, April 2025.
• [4] Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0 — ENISA, June 2025.