NIS2 Incident Communication Plan: SOC-to-Board Escalation and the Article 23(7) Disclosure Trigger

Most NIS2 “incident communication” advice collapses into one instruction: notify your CSIRT within 24 hours. That’s one piece of a larger obligation. A defensible plan has to move information through three separate channels — up through your own organisation, out to a regulator, and potentially out to the public — and each one has a different owner, a different trigger, and a different failure mode. Get the handoffs between those three channels wrong, and the 24-hour clock in Article 23 starts running before anyone with the authority to sign off on a customer notice even knows an incident is underway.

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.

Who Needs a Documented Incident Communication Plan

If your organisation falls under NIS2 as an essential or important entity, you already need an incident-handling capability under Article 21(2)(b). A written communication plan is the part most organisations skip, because it isn’t listed under a single named article — it’s implied by the Commission Implementing Regulation (CIR) 2024/2690’s incident-handling requirements and by Article 20’s board-oversight duty.

Your situation	Why a documented plan matters
Digital infrastructure entity (DNS/TLD, cloud, CDN, data centre, MSP/MSSP, marketplace, search engine, social platform, trust service)	CIR 2024/2690 Annex Section 3.1.2 binds you directly — a documented escalation and reporting communication plan is a hard requirement, not a suggestion.
Any other essential or important entity (manufacturing, energy, health, transport, digital services, public administration, etc.)	The CIR doesn’t bind you directly, but Article 21(2)(b) plus Article 20’s board-liability duty mean an undocumented, ad hoc communication response is exactly the gap a competent authority will probe first after any reportable incident.

The Three Communication Layers NIS2 Actually Requires

Treating "incident communication" as a single document is the most common structural mistake. In practice it splits into three layers, each with a different audience, legal anchor, and owner.

Layer	Audience	Legal anchor	Owner
1. Internal escalation	SOC → CISO → board	CIR 2024/2690 §3.1.2 (roles + comms plan); Article 20 (board oversight)	CISO, escalating to the board
2. Regulatory notification	National CSIRT / competent authority	Article 23(1)–(6)	Compliance/legal, with CISO input
3. Public & stakeholder communication	Affected customers, press, the public	Article 23(2) (service recipients) and Article 23(7) (public disclosure)	Communications/legal, with board sign-off

The failure pattern is almost always the same: the SOC analyst who first spots the anomaly is not, and should not be, the person deciding what the board hears or what a journalist gets told. Without a documented handoff between these three layers, the 24-hour early-warning clock starts running before anyone with the authority to approve a customer notice has even been told an incident exists.

A useful way to keep the three layers from blurring together is to tie escalation triggers to a severity tier rather than a vague “is this bad?” judgment call. A Sev-3 event (contained, no data or service impact) stays with the SOC and CISO. A Sev-2 event (possible data exposure or partial outage, meeting the Article 23(3) significance test) escalates to the board and starts the regulatory clock. A Sev-1 event (confirmed significant impact, likely cross-border relevance, or an active ransomware/extortion scenario) triggers all three layers simultaneously, including a first pass at draft external messaging before the 72-hour notification is even due. Writing these tiers down — and mapping each one to who gets called — turns escalation from a judgment call into a checklist.

Building the Internal Escalation Matrix: SOC to CISO to Board

CIR 2024/2690 Annex Section 3.1.2 requires an incident-handling policy that includes “assignment of roles to detect and appropriately respond to incidents to competent employees,” “effective communication plans including for escalation and reporting,” and “a categorisation system for incidents.” That’s the legal hook for the escalation matrix — and it’s worded broadly enough to apply as a sound baseline even for entities the CIR doesn’t bind directly.

Step	Who	Action	Effort
1. Detect & triage	SOC analyst (Tier 1)	Log the event, apply your categorisation system to classify severity	Low
2. Escalate to CISO	SOC lead	Escalate immediately if the event meets the Article 23(3) significance test — severe operational/financial impact, or considerable damage to others	Low
3. Confirm significance & start the clock	CISO + compliance officer	Confirm the significance threshold, start the 24-hour early-warning clock, loop in legal	Medium
4. Brief the board & decide on external comms	CISO → board (or named deputy)	Brief per Article 20’s oversight duty; decide whether a public or customer statement is warranted	High
5. Out-of-hours delegation	Pre-named deputy with delegated authority	Execute steps 3–4 without waiting for a full board to convene	Medium

Step 5 is the one most plans miss. The UK’s National Cyber Security Centre puts it plainly in its board incident-planning guidance: "it is critical that people know what authority they have, especially if an incident happened outside of normal business hours," and a response plan needs explicit "delegation of authority to make key decisions" and named "responsibilities for contacting key individuals in the organisation (including board members)." In practice, the plans that fall apart under pressure aren’t missing a CSIRT phone number — they’re missing a named person who can approve a customer email at 2 a.m. without waking the whole board first.

Run this as a gap analysis before you assume your plan is ready: current state is usually an informal Slack thread with no named deputy and no tested handoff; the required state is a contact tree with delegated authority that has actually been rehearsed. CIR 2024/2690 Section 3.1.3 makes that rehearsal a requirement, not a nice-to-have — roles and procedures in the incident-handling policy must be tested and reviewed at planned intervals, and again after any significant incident or major operational change. A written escalation matrix nobody has run through a tabletop exercise is a document, not a capability. See our breakdown of executive responsibilities under NIS2 for how this escalation chain intersects with personal management-body liability under Article 20.

Article 23 Notification Is External Communication, Not Paperwork

Once your internal escalation confirms a significant incident, Article 23 sets a fixed regulatory communication timeline. This is a communication act, not a form-filling exercise — a competent authority reads tone and clarity in these submissions the same way a journalist reads a press statement.

Deadline	What must be communicated
24 hours	Early warning: whether the incident is suspected to involve unlawful or malicious acts, and whether it could have cross-border impact
72 hours	Incident notification: updated severity assessment, initial impact evaluation, and indicators of compromise where available
1 month	Final report: detailed description, threat type, mitigation measures applied, and cross-border impact where applicable

Article 23(2) adds a separate, parallel duty: entities must communicate "without undue delay" to affected service recipients about significant cyber threats, including protective measures they can take. That duty runs independently of the CSIRT timeline — you don’t need to wait for the 72-hour notification to warn customers who are actively exposed. For the full procedural breakdown of thresholds and notification forms, see our Article 23 incident notification guide.

The Article 23(7) Public Disclosure Trigger — When the Choice Isn’t Yours

The provision that actually governs public disclosure is Article 23(7), not the CSIRT-response clause at Article 23(5) that some compliance briefs cite by mistake. The directive’s text is specific: "where public awareness is necessary to prevent a significant incident or to deal with an ongoing significant incident, or where disclosure of the significant incident is otherwise in the public interest," a member state’s CSIRT or competent authority "may, after consulting the entity concerned, inform the public about the significant incident or require the entity to do so."

Two things follow from that wording. First, the authority can make the disclosure itself, or it can direct your organisation to make it — either way, the decision doesn’t sit exclusively with you once the threshold is met. Second, "after consulting the entity concerned" is a consultation requirement, not a veto: your organisation gets input, not final say. That’s why your escalation matrix needs to name someone with authority to engage with a regulator on disclosure terms within hours, not days.

Media Statement Guidance: What to Prepare Before You Need It

Belgium’s Centre for Cybersecurity (CCB) — the country’s NIS2 national competent authority — publishes practical crisis-communication guidance built from real incidents it has coordinated: keep a pre-built contact list covering staff, stakeholders, partners, and press; maintain a ready overview of which communication channels you’ll actually use during an outage; and draft key messages in advance for the attack types most relevant to your sector, so nobody is writing a holding statement from a blank page while the incident is still live.

Three practical rules follow from that:

• Name a spokesperson who isn’t the CISO. The person best placed to contain the technical incident is rarely the person best placed to field media questions under pressure — and pulling the CISO into press duty slows the technical response.
• Draft holding statements before an incident, not during one. A generic, legally-reviewed holding statement that can be filled in with specifics buys hours you don’t have if you’re starting from a blank page.
• Keep internal and external messaging consistent. If the board hears one version of severity and customers or press get a different one, the mismatch itself becomes the story — and it undermines the "early and openly" standard regulators and journalists both expect.

What Your Board Actually Needs to See

Article 20 makes the management body accountable for overseeing cybersecurity risk-management measures — which means the board needs a documentation trail it can point to after the fact, not just a verbal briefing during the incident. At minimum, keep:

• The escalation matrix itself, with named deputies and delegated authority, plus evidence it has been tested
• A timestamped log of the incident classification decision and who made it
• The Article 23 notification timeline status (early warning / notification / final report, with submission dates)
• Copies of every external communication drafted and sent, including who approved each one
• A sign-off record showing who approved what, and when

This documentation trail complements ongoing board reporting rather than replacing it — see our guide to the board metrics auditors expect between incidents for how incident-time evidence fits into your regular governance cadence.

Frequently Asked Questions

Is an incident communication plan a legally required, separate NIS2 document?

NIS2 doesn’t name "incident communication plan" as a standalone deliverable. CIR 2024/2690 Section 3.1.2 requires digital-infrastructure entities to document escalation and reporting communication plans as part of incident handling; for other essential and important entities, Article 21(2)(b) and Article 20’s oversight duty make an equivalent documented plan the practical expectation, even without a named article requiring that exact document.

Who decides whether to make a cyber incident public under NIS2?

Under Article 23(7), the CSIRT or competent authority may inform the public itself, or require your organisation to do so, once public awareness is necessary to prevent or manage an incident, or disclosure is otherwise in the public interest. Your organisation is consulted first, but the final call isn’t exclusively yours once that threshold is met.

Does the 72-hour Article 23 deadline include a public statement?

No. The 72-hour deadline under Article 23(4) is a notification to your CSIRT or competent authority, not a public statement. A separate duty under Article 23(2) requires informing affected service recipients "without undue delay" about significant cyber threats — independent of the regulator timeline. Public disclosure under Article 23(7) is a third, distinct trigger.

Who should be the media spokesperson during a NIS2-reportable incident?

National cyber authorities recommend naming and training a spokesperson in advance who is not the person leading technical containment — typically a communications or legal lead, briefed by the CISO but not managing the incident directly. That separation keeps technical response and public messaging from competing for the same person’s attention.

How does the internal escalation matrix relate to the Complete Toolkit’s incident templates?

The escalation matrix is the roles-and-communication-plan layer that CIR 2024/2690 Section 3.1.2 requires alongside your incident handling policy — it names who does what, in what order, before a single Article 23 form gets filled in. Pairing it with a structured incident log and pre-built notification forms, rather than drafting either from scratch mid-incident, is what turns a compliance obligation into something your team can actually execute under pressure.

Sources

• "NIS 2 Directive Article 23: Reporting obligations" — nis-2-directive.com
• "NIS2 Article 23. Reporting obligations" (full paragraph structure) — streamlex.eu
• "Art. 23 Reporting obligations" — springlex.eu
• "Article 20 of NIS 2 Directive — Governance" — nis-2-directive.com
• "CIR 2024/2690 Annex — Technical and methodological requirements" — advisera.com
• "Planning your response to cyber incidents" — National Cyber Security Centre (UK) Board Toolkit — ncsc.gov.uk
• "Crisis communication in the event of a cyber attack" — Centre for Cybersecurity Belgium, Belgium’s NIS2 national competent authority (ccb.belgium.be)