NIS2 Incident Response Policy vs. Plan vs. Playbook: The CIR 2024/2690 Distinction Most Templates Get Wrong

Search “NIS2 incident response policy template” and you’ll find dozens of documents that are actually incident response plans wearing a policy’s name tag. That mislabeling isn’t cosmetic. Auditors, insurers, and your own IR team need three distinct documents that answer three distinct questions — and Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690) is the one piece of NIS2 law that actually uses this vocabulary precisely, even though most compliance content ignores it.

This guide draws the line between policy, plan, and playbook using the CIR’s own language, lists the eight elements a NIS2 incident response policy must contain, sets a floor of three scenario-specific playbooks your policy has to reference, and walks through the document structure section by section. It does not repeat the six-phase operational playbook — that’s already covered here — this is about the governance document that sits above it.

Policy, Plan, and Playbook Are Not Interchangeable Words

Article 21(2)(b) of the NIS2 Directive requires incident handling as one of ten minimum cybersecurity risk-management measures, but the Directive itself doesn’t break that requirement into sub-documents [1]. That detail comes from CIR 2024/2690, which sets binding technical and methodological requirements for a specific slice of NIS2 entities. Point 3.1.2 of the CIR’s Annex requires a documented “incident handling policy with roles and processes for detection, analysing and responding to incidents, in coherence with business continuity and disaster recovery plan” [3][4].

Read that sentence again and you’ll notice it already separates two things: a policy (the governance document establishing roles and authority) and processes (the operational steps that turn authority into action). The CIR repeats this “policy and procedures” pairing across roughly ten of its thirteen thematic Annex sections [3] — it is not sloppy phrasing, it’s a consistent structural choice. Extend that logic one layer further, down to the scenario level, and you get the three-tier model this article uses:

Document	Answers	Owner	Changes how often
Policy	Who has authority, what must be classified and reported, and under what legal obligations	CISO / Board sign-off	Annually, or after a material regulatory change
Plan	What sequence of operational steps the IR team follows from detection to recovery	IR Manager	After each major exercise or real incident
Playbook	Exactly what to do for one specific attack type (commands, contacts, decision points)	IT Security Lead / scenario owner	Whenever the underlying threat or tooling changes

A one-page policy without a plan is unenforceable. A plan without playbooks forces your team to improvise the technical response to a live ransomware event from a generic six-phase outline. Regulators and cyber-insurance underwriters increasingly ask for all three as separate artefacts, not one blended 40-page PDF labeled incident response.

Where CIR 2024/2690 Actually Applies — and Where It’s a Best-Practice Reference Instead

Here’s the caveat almost every NIS2 template site skips: CIR 2024/2690 is not binding on every NIS2 entity. Its Article 1 scope covers digital infrastructure providers specifically — DNS service providers, TLD name registries, cloud computing service providers, data centre and content delivery network providers, ICT managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers [3][4]. If you fall into one of those categories, point 3.1.2’s incident handling policy requirement is a direct legal obligation, and your policy needs to name it explicitly.

If you’re in manufacturing, healthcare, energy, water, transport, or public administration, CIR 2024/2690 does not bind you the same way — your obligation still traces back to Article 21(2)(b)’s general incident handling measure and your national transposition law. In practice, though, the CIR’s policy/procedure structure is the most detailed regulatory template available under the whole NIS2 framework, and using it by analogy is defensible, well-documented practice — not a legal requirement. State that distinction inside your own policy document (“this policy adopts the structure of CIR 2024/2690 point 3.1.2 as a governance reference”) rather than implying a binding obligation that doesn’t apply to your sector. Overclaiming a legal basis you don’t have is the kind of detail an auditor — or a competitor’s lawyer — will catch.

The 8 Elements a NIS2 Incident Response Policy Must Include

Whichever legal basis applies to you, these eight elements turn a policy from a compliance checkbox into a document your IR team can actually use during a 2 a.m. call.

1. Scope and purpose. Which systems, subsidiaries, and third-party-managed services the policy covers, and which legal instrument it’s answering (NIS2 Art.21(2)(b), and CIR 2024/2690 §3.1.2 if applicable).
2. Named roles, not job titles. The CISO holds significance sign-off authority; a named IR Manager coordinates response; a named Legal/Compliance Officer owns the Art.23 notification from the moment of awareness; an IT Security Lead executes technical containment; a Communications Lead manages internal and external messaging. Pre-assign backups — a policy that only works when one specific person answers their phone is not a policy.
3. Severity classification and escalation triggers. The thresholds that convert “we saw something odd in the SIEM” into a formally declared incident, and who has authority to make that declaration.
4. Article 23 trigger criteria and the notification clock. See the table below — this is the single most consequential timing element in the whole document.
5. Evidence preservation and chain of custody. Who is authorised to touch affected systems, what must be logged before containment begins (timestamps, hash values, access records), and how custody is documented if law enforcement or a forensics vendor gets involved later.
6. External communication protocol. Exactly which role contacts the national competent authority or CSIRT, and through which channel — most member states operate a 24/7 clearinghouse for exactly this purpose, the way Germany’s BSI runs its National IT Situation Centre in coordination with CERT-Bund [5].
7. Coordination with business continuity and disaster recovery. CIR §3.1.2 explicitly requires the incident handling policy to be in coherence with your BCP/DR plan [3] — cross-reference the two documents rather than duplicating content.
8. Testing cadence and review triggers. A fixed annual review date, plus a mandatory review after any incident that invoked the policy and after any material regulatory change.

Article 23 Trigger Criteria: What Starts the Clock, and When

Article 23(3) defines a significant incident as one that has caused, or is capable of causing, severe operational disruption or financial loss to the entity, or that has affected or could affect others through considerable material or non-material damage [2]. Your policy needs to translate that legal language into concrete, pre-agreed thresholds — service downtime past a stated duration, number of affected users past a stated count, or confirmed data exfiltration — because severe is not a number your IR Manager can act on during an active incident.

Deadline	Trigger point	What must be filed
24 hours	From the moment of awareness — when a qualified assessment concludes the significance threshold is met or likely met	Early warning: is malicious intent suspected, is cross-border impact possible
72 hours	From the same awareness moment	Incident notification: initial severity/impact assessment, indicators of compromise where available
1 month	After the 72-hour notification is filed	Final report: full description, root cause, mitigation measures applied, cross-border impact

The national competent authority or CSIRT must, in turn, respond to your early warning without undue delay and where possible within 24 hours [2]. Your policy should name that expectation too — it sets your team’s expectation for guidance, and it’s a data point worth having on record if the authority’s response is unusually slow during a live incident.

The 3 Playbooks Every Policy Must Reference at Minimum

A policy that lists roles and deadlines but points to zero scenario-specific playbooks is the single most common gap this article’s competitive research found — one widely-cited NIS2 IR-plan guide covers reporting channels and evidence preservation in detail but includes no ransomware, DDoS, or supply-chain procedures at all. Set a floor of three playbooks your policy must reference by name, chosen for how differently each one breaks the standard six-phase response:

• Ransomware. Containment means isolating backup infrastructure before anything else — a generic “contain the threat” instruction gets backups encrypted right alongside production. This is the scenario most likely to force a genuine business-continuity failover.
• Supply chain compromise. The affected system may not be yours — Art.21(2)(d)’s supply chain security obligation means your policy needs a path for declaring an incident that originates at a third-party supplier, including how you request evidence from a vendor who may be slower or less cooperative than your own team.
• DDoS. The decision tree runs on infrastructure and SLA terms, not forensics — upstream scrubbing, CDN failover, and a different set of external contacts (your ISP or CDN provider) than a data-breach scenario would need.

Ransomware and DDoS are the two scenarios most generic IR templates already anticipate in some form; supply chain compromise is the one this article’s competitive research found missing from nearly every template, even though Article 21(2)(d) makes supply chain security a standing NIS2 obligation. If your sector carries additional material risk — OT/ICS disruption for manufacturing and energy, or insider threat for entities handling sensitive personal data — add a fourth and fifth playbook, but three is the floor, not a suggestion.

Template Structure: The 9 Sections Your Policy Document Needs

With the elements and playbook references defined, here’s how they map onto an actual document skeleton, in the order an auditor will expect to read them:

1. Purpose, scope, and legal basis — which entities, systems, and legal instruments this policy answers to
2. Definitions — incident, significant incident, awareness, matched to Article 23(3)’s own language rather than a paraphrase
3. Governance and roles — the named-role table from Element 2 above, plus backups
4. Classification and severity thresholds — the pre-agreed numeric triggers from Element 3
5. Escalation and notification procedures — the 24h/72h/1-month table, embedded directly rather than cross-referenced, because this is the section your team reads under the most time pressure
6. Evidence preservation and chain of custody — Element 5’s logging and access-authorisation rules
7. Playbook references — a short index naming your minimum three scenario playbooks by title and document location, not their full content
8. Testing, review, and version control — the annual review date, post-incident review trigger, and a change log
9. Approval and sign-off — CISO and, for Essential entities, board-level sign-off, since Article 20(1) requires management bodies to approve cybersecurity risk-management measures and holds them liable for Article 21 infringements [6]

The Gap Most Organisations Have Today

The most common failure pattern isn’t a missing document — it’s one document trying to do three jobs. A single incident response plan that mixes governance language, six-phase procedure, and technical playbook detail in one file is hard to maintain (a playbook update shouldn’t require board re-approval of the whole policy) and hard to audit (a reviewer can’t quickly confirm role sign-off authority buried on page 14 of an operational runbook).

Current state	Required state	Effort to close
One blended IR document, no named backups for roles	Separate policy (governance) + plan (procedure) + playbooks (scenario), each with named owners and backups	Medium — mostly a re-organisation of existing content, plus filling named-backup gaps
Art.23 deadlines mentioned narratively, no fixed thresholds	Numeric severity thresholds pre-agreed and embedded in the escalation section	Medium — requires a workshop with IT, Legal, and business-unit owners to agree numbers
Zero or one scenario playbook	Minimum three (ransomware, supply chain, DDoS), referenced by name in the policy	High — each playbook needs its own technical review and tabletop test
No fixed review date	Annual review date plus mandatory triggers (post-incident, post-regulatory-change)	Low — a calendar entry and a policy clause

Frequently Asked Questions

Is an incident response policy legally required for every NIS2 entity?
Article 21(2)(b) requires incident handling as a minimum measure for all Essential and Important entities [1]. The specific documented-policy requirement in CIR 2024/2690 §3.1.2 is binding only for the digital infrastructure entities named in the CIR’s Article 1 scope [3][4]; other sectors satisfy Art.21(2)(b) through their national transposition law, and typically demonstrate this with an equivalent documented policy even without CIR’s specific wording forcing it.

Can the policy and the plan be one document?
Nothing in the Directive text forbids it, but CIR §3.1.2’s own “policy and procedures” phrasing treats them as distinct layers [3], and separating them makes both easier to maintain and audit — a plan update from a tabletop exercise shouldn’t require re-running board approval of the governance policy.

How often must the policy be reviewed?
NIS2 doesn’t set a fixed cadence for this specific document. Annual review is standard practice, alongside mandatory review after any incident that invoked the policy and after material regulatory or organisational change.

Who has to sign off on the policy?
At minimum the CISO. Article 20(1) requires management bodies of essential and important entities to approve the cybersecurity risk-management measures taken under Article 21 and permits them to be held liable for infringements [6], which in practice means board-level sign-off on the policy itself, even if operational plans and playbooks are approved at a lower level.

Key Takeaways

Treat policy, plan, and playbook as three documents with three owners, not three sections of one file. Ground the distinction in CIR 2024/2690 §3.1.2’s own “policy and procedures” language where it legally applies, and use it by analogy — clearly labelled as such — everywhere else. Build the escalation section around fixed, pre-agreed numeric thresholds rather than narrative language, embed the 24h/72h/1-month timeline directly in the policy, and reference a minimum of three scenario playbooks by name. A policy that only lists roles and deadlines without naming its playbooks is the gap this article’s own competitive research found most often — close that one first.

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

• NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com (Directive (EU) 2022/2555)
• NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com (Directive (EU) 2022/2555)
• NIS 2 Directive, Article 20: Governance — nis-2-directive.com (Directive (EU) 2022/2555)
• OpenKRITIS, NIS2 Implementing Act mapping (CIR 2024/2690)
• nisd2.eu, CIR 2024/2690 technical measures wiki
• Bundesamt für Sicherheit in der Informationstechnik (BSI), National IT Situation Centre