NIS2 Crisis Management Plan: Mapping CIR Annex 4.3 to a Gold-Silver-Bronze Governance Structure

Article 21(2)(c) of the NIS2 Directive lists three things under one heading: backup management, disaster recovery, and crisis management [1]. Most compliance guidance treats all three as interchangeable pieces of “business continuity.” They are not. Commission Implementing Regulation (EU) 2024/2690 gives crisis management its own Annex section — 4.3 — separate from the business continuity plan (4.1) and the backup regime (4.2) [3]. A BC plan tells your organisation how to restore a system. A crisis management plan tells it who decides, who talks to whom, and when the board gets involved — while the restoration is still happening and the facts are still incomplete.

This article works from CIR Annex 4.3’s own sub-points, not a generic crisis-communications template repackaged for NIS2. It covers what actually distinguishes a crisis from an incident under the regulation, how to structure crisis governance across the Gold-Silver-Bronze tiers 4.3.2 implicitly requires, when and how the board must be told, and the documentation an auditor expects under 4.3.4. For the wider business continuity picture — the BIA, the BC plan itself, and backup requirements — see our business continuity guide.

What CIR Annex 4.3 Actually Requires (and What It Doesn’t)

In short: CIR 2024/2690 Annex 4.3 requires four things — a documented crisis management process, defined roles with crisis-specific decision authority, a channel for using information CSIRTs and authorities send you, and a regular test-and-review cycle. It does not name a governance model, a team structure, or an activation threshold — those are left to the entity to design, proportionate to its size and risk [3].

CIR 2024/2690 splits Article 21(2)(c)’s single phrase into three separate Annex sections — 4.1 (business continuity and disaster recovery plan), 4.2 (backup and redundancy), and 4.3 (crisis management) — each carrying its own sub-requirements [1][2][3]. Treating “crisis management” as a paragraph inside your BC plan, rather than its own documented process, is a structural gap an auditor mapping against the Annex will find immediately.

Here is what Annex 4.3’s four sub-points actually say:

CIR point	Requirement	What it actually says
4.3.1	Establish the process	Entities “shall put in place a process for crisis management”
4.3.2	Define what the process addresses	Roles and responsibilities for personnel — and suppliers/service providers — “specifying allocation in crisis situations including specific steps”; appropriate communication means with competent authorities; measures to maintain network/information system security during the crisis
4.3.3	Use external intelligence	A process for managing and using information received from CSIRTs or competent authorities about incidents, vulnerabilities, threats, or mitigation measures
4.3.4	Test and maintain	Test, review, and update the crisis management plan regularly or after significant incidents or changes

Two things worth flagging. First, 4.3.2’s communication requirement is with competent authorities specifically — it doesn’t cover customer or media communications, which every practical crisis plan needs but which sit outside the CIR’s binding text. Second, 4.3.3 is easy to misread: it isn’t your outbound incident-notification obligation (that’s Article 23, covered below) — it’s an inbound requirement to actually use the threat intelligence and mitigation guidance your CSIRT sends you, not just receive it and file it.

Crisis vs. Incident: The Activation Trigger Criteria

In short: The CIR doesn’t define when a crisis management plan activates instead of standard incident response — that threshold is yours to set, and “we’ll know it when we see it” is not a defensible answer to an auditor.

A server outage is an incident. A ransomware attack that halts production, draws media attention, and forces a same-day ransom decision is a crisis. The regulation doesn’t draw that line — CIR 4.3’s own “where appropriate” qualifier leaves the threshold-setting to the entity, consistent with the proportionality intent CIR 2024/2690’s Recital 4 signals for requirements generally [3]. As a general guideline, organisations that clear an audit without friction define activation using explicit, pre-agreed criteria rather than a judgment call made mid-incident:

Trigger	Why it exceeds standard incident response
Incident handling process (Article 21(2)(b)) hasn’t contained or resolved the disruption within your defined threshold	Escalating, not converging
Confirmed large-scale personal data breach, or exposure of confidentially-classified data likely to require regulatory notification	Legal exposure exceeds the technical response team’s scope
Any ransom or extortion demand tied to the incident	Requires legal, insurance, and law-enforcement input the incident team isn’t resourced to give
Incident meets NIS2’s Article 23(3) “significant incident” threshold — severe operational/financial disruption, or considerable harm to others [4]	The regulatory notification clock is already running
Media coverage has started, or is judged likely within hours	Reputational and legal risk now compounds technical risk
The event threatens the organisation’s ability to continue operating	Existential, not operational

Set specific numeric thresholds against each of these before an incident forces you to improvise one — “service disruption exceeding a defined number of hours, affecting a defined number of users” is auditable; “when things get bad” is not.

Crisis Team Governance: Gold, Silver, and Bronze

In short: CIR 4.3.2 requires you to specify role allocation “in crisis situations including specific steps” [3] — in practice, that means more than a flat list of five job titles with no reporting structure between them.

The UK’s Gold-Silver-Bronze command model, used across British emergency services and now widely adopted for corporate crisis governance including alongside ISO 22301, structures that allocation into three tiers instead of one [8]. This isn’t a private-sector-only construct: Germany’s BSI operates its own National IT Crisis Response Centre using a similarly tiered, coordinated model for severe incidents affecting federal administration and critical infrastructure — a structural precedent for treating crisis response as layered rather than flat [7].

Tier	Focus	Who sits here	Reports to
Gold (Strategic)	Sets direction, engages the board, allocates resources, approves external statements above a defined severity	Crisis Commander / Executive Sponsor, Legal, Communications lead, Finance	Board
Silver (Tactical)	Converts Gold’s objectives into an executable plan; coordinates across departments running the BC plan	Crisis Coordinator, BC team leads, HR	Gold
Bronze (Operational)	Detects and contains the incident on the ground; executes technical recovery; usually first to know something is wrong	IT Security Lead, incident response team, specialist/production teams	Silver

A flat role table tells you who’s responsible; a tiered structure tells you who escalates to whom, and at what point Gold gets pulled in rather than left running the business as usual. Our business continuity guide covers the flat five-role model most NIS2 entities start with — Executive Sponsor, Crisis Coordinator, Technical Lead, Communications Lead, Legal/Compliance Contact. Mapped onto Gold-Silver-Bronze, the Executive Sponsor and Legal/Compliance Contact sit at Gold, the Crisis Coordinator anchors Silver, and the Technical Lead operates at Bronze alongside the team running your Article 21 incident handling process. What the flat model doesn’t specify — and what auditors increasingly ask for — is the reporting cadence between tiers: Gold convening within a defined window of activation (commonly one hour), Silver reporting to Gold at a fixed interval, Bronze running continuously.

Board and Management Body Notification: What Article 20 Requires During a Crisis

In short: Article 20 doesn’t mention “crisis” by name, but it makes management-body involvement in your crisis governance a matter of personal liability, not courtesy.

Article 20(1) requires that management bodies “approve the cybersecurity risk-management measures taken by” essential and important entities and “oversee its implementation,” and members “can be held liable for infringements” [5]. A crisis management plan is one of the Article 21(2)(c) risk-management measures the board must approve — which means the board isn’t just a stakeholder to inform during a crisis; it’s accountable for whether the plan now running was adequate in the first place. That accountability carries real exposure: essential entities face fines of up to EUR 10,000,000 or 2% of worldwide annual turnover, whichever is higher, for Article 21 or 23 infringements — important entities up to EUR 7,000,000 or 1.4% [6].

That creates two distinct board obligations during an active crisis, not one:

• Being informed — Gold-tier crisis governance should specify exactly what triggers a board notification and within what window. An incident meeting the Article 23(3) significant-incident threshold, or any event carrying material financial or reputational exposure, should trigger notification — not wait for the post-crisis debrief.
• Being asked to decide — decisions carrying liability consequences should require explicit board (or designated Crisis Commander) authorisation: whether to pay a ransom, whether to engage law enforcement, and the content and timing of any public statement. Delegating these to Silver or Bronze tier without a documented, pre-authorised limit is the same gap examiners flag in ordinary Article 20 governance reviews — undocumented delegation of a decision the board is liable for.

See our Article 20 board liability guide for the full governance-accountability picture beyond crisis scenarios, and our CISO board reporting guide for the reporting cadence outside active incidents.

Communicating With CSIRTs and Competent Authorities: CIR 4.3.3 vs. Article 23

In short: these are two different obligations that get conflated constantly. Article 23 is what you tell your CSIRT. CIR 4.3.3 is what you do with what your CSIRT tells you.

Article 23 sets the outbound notification clock: an early warning within 24 hours of becoming aware of a significant incident, a full incident notification within 72 hours, and a final report within one month of that notification [4]. Most NIS2 crisis-planning content stops there. CIR Annex 4.3.3 sets a separate, inbound obligation: entities shall implement a process for managing and making use of information received from CSIRTs or competent authorities concerning incidents, vulnerabilities, threats, or possible mitigation measures [3].

In practice that means your crisis management plan needs a defined path for threat intelligence and mitigation guidance to reach the people who can act on it — not just a mailbox that receives CSIRT advisories. During an active crisis, that’s typically the Bronze-tier technical lead for mitigation guidance and the Silver-tier coordinator for anything affecting recovery sequencing. Document who monitors the inbound channel, who triages what arrives, and how it feeds into the crisis’s ongoing decisions — the same rigor CIR 4.3.2 requires for your outward-facing communication with authorities. See our Article 23 notification guide for the full 24-hour/72-hour/one-month timeline and what each report must contain, and our “significant incident” definition guide for how the threshold that starts that clock is determined.

Testing, Review, and the Evidence Auditors Expect (CIR 4.3.4)

In short: CIR 4.3.4 requires you to test, review, and update the plan “regularly” or after significant incidents or changes — it sets no fixed interval, and “regularly” without documentation reads to an auditor exactly like never.

4.3.4’s text mirrors the “regular… and following significant incidents or changes” pattern running through nearly every CIR Annex sub-section [3]. The interval is left to your own risk assessment, but the artefact an auditor asks for is consistent regardless of cadence: a documented tabletop exercise, its scenario, the gaps it surfaced, and management sign-off. A crisis plan nobody has rehearsed is, functionally, a set of assumptions about what would happen — not a demonstrated capability.

A ransomware tabletop is the most common and most useful exercise scenario, because it forces every tier to engage at once: Bronze detects and contains, Silver coordinates recovery sequencing against the BC plan, and Gold makes the ransom-payment and disclosure calls under time pressure. Run at least one per year, and after any real activation, capture in writing:

• Scenario, participants, and date
• Time to Gold-tier assembly against your target (commonly within one hour of activation)
• Decisions made, with timestamps — the scribe log CIR 4.3.2’s decision-authority requirement effectively demands
• Gaps identified, and the corrective action, owner, and due date for each
• Sign-off from the plan owner

Gap Analysis: From Ad Hoc Crisis Response to CIR-4.3-Aligned

Current state	Required state	CIR ref	Effort to close
Crisis handled as an extension of the incident response team, no separate process	Documented, standalone crisis management process	4.3.1	Medium — mostly a documentation and governance-design exercise
Flat role list with no tiered escalation or reporting cadence	Gold-Silver-Bronze (or equivalent tiered) structure with defined reporting lines	4.3.2	Low-Medium — reorganising existing roles into tiers, minimal new hires
No pre-authorised spending or decision limits; every crisis decision waits for full board	Documented decision-authority table with pre-authorised limits per tier	4.3.2	Low — a policy and documentation change
CSIRT advisories received but not routed to anyone accountable for acting on them	Defined inbound-intelligence process with a named owner	4.3.3	Low — process and ownership assignment, no new tooling required
Crisis plan exists but has never been tested	Annual tabletop exercise with documented results and corrective actions	4.3.4	Medium — requires scheduling, facilitation, and participant time
Board informed only after resolution	Pre-defined board-notification triggers and window built into Gold-tier activation	Art. 20	Low — a documentation and sign-off change

Conclusion

CIR 2024/2690 Annex 4.3 asks for four things: a documented process, role allocation with crisis-specific decision steps, a channel for using CSIRT intelligence, and a regular test-and-review cycle [3]. None of that requires a specific governance model — Gold-Silver-Bronze is one well-established way to meet the role-allocation requirement, not the only one, but it gives you tiered escalation and reporting lines a flat role list doesn’t.

Start by checking whether your current plan documents activation triggers with numbers attached, not adjectives; whether board-notification windows are defined before a crisis rather than negotiated during one; and whether you have a dated tabletop-exercise record, not just a plan nobody has rehearsed. Those three gaps are the ones auditors find first, and they’re also the cheapest to close — mostly documentation and governance design, not new infrastructure.

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.

Frequently Asked Questions

Does NIS2 require a crisis management plan separate from my business continuity plan?
Yes, structurally — CIR 2024/2690 gives crisis management its own Annex section, 4.3, distinct from the BC plan (4.1) and backup regime (4.2) [3]. A single combined document can satisfy both if it clearly addresses each section’s sub-points, but a crisis paragraph buried inside a BC plan usually leaves 4.3.2’s role-allocation and 4.3.3’s CSIRT-intelligence requirements unaddressed.

What actually triggers crisis management plan activation instead of standard incident handling?
CIR 2024/2690 doesn’t set a fixed threshold — that’s left to the entity’s own risk-based judgment [3]. In practice, defensible triggers include the incident handling process failing to contain the disruption within a defined window, any ransom demand, likely media attention, and meeting NIS2’s Article 23(3) “significant incident” criteria [4]. Set numeric thresholds in advance; don’t decide mid-incident.

Who has the authority to activate the crisis management plan?
CIR 4.3.2 requires the plan to specify allocation of roles “including specific steps” [3], which should name exactly who can declare activation — typically the Gold-tier Crisis Commander or their designated deputy, with a documented backup if the primary is unreachable.

Does the board need to be told about every crisis, or only severe ones?
Article 20 makes the management body accountable for approving and overseeing the Article 21(2)(c) crisis management measure [5], which means board-notification thresholds should be built into your Gold-tier activation criteria — not left to case-by-case judgment during the event itself. Not every activation needs full board involvement, but every activation meeting your pre-defined severity threshold should trigger notification within a documented window.

Sources

1. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
2. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
3. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
4. NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com
5. NIS 2 Directive, Article 20: Governance — nis-2-directive.com
6. NIS 2 Directive, Article 34: Penalties — nis-2-directive.com
7. National IT Crisis Management — BSI (Bundesamt für Sicherheit in der Informationstechnik)
8. BC command structures – Gold, Silver and Bronze — Databarracks