Incident Communication Plan Template: Stakeholders and Regulators

In a serious cyber incident the technical response is often recoverable, but a careless first statement, a regulator deadline missed by hours or an update sent over an email system the attacker is reading can do lasting damage. This template is a ready-to-adopt incident communication plan: roles and sign-off, a stakeholder map, out-of-band channels, communication rules, notification timelines for GDPR, NIS2, DORA and the SEC, and fill-in templates for holding statements, regulator notices, customer notifications, press statements and status page updates. It is for heads of communications, CISOs, legal and data protection teams and incident managers who need words and decisions ready before they are needed. It sits under your incident response plan; see the Incident Response Plan Template.

How to use this template

• Use it as the communication annex of your incident response plan, as a crisis communication plan for cyber incidents, or as the breach communication template set for your data protection team.
• Replace text in square brackets, such as [Organisation], [Head of Communications] and [2 hours], with your own names, channels and targets. Target times run from incident declaration unless a section says otherwise.
• "Must" is mandatory; "should" is recommended and may be skipped with a recorded reason.
• Pre-approve sections 7 to 11 with [Legal] and [Executive sponsor] in peacetime, so that during an incident only the facts in brackets need approval.
• Keep printed and offline copies so the plan works when email, chat and the identity provider are down.
• For wider crisis communication within resilience planning, see the Cyber Resilience Guide.

1. Purpose and scope

This plan sets out how [Organisation] communicates during and after a cyber security incident: who decides what is said, to whom, through which channels and by when. It aims to keep staff, customers, partners, regulators and the public accurately informed, to meet legal and contractual notification duties, and to avoid statements that increase risk or later need retracting. It applies to every incident rated [SEV1 or SEV2] under the [Incident Response Plan], to any personal data breach, and to supplier incidents affecting [Organisation] data or services. It supports NIST CSF 2.0 outcomes RS.CO-02 ("Internal and external stakeholders are notified of incidents"), RS.CO-03, RC.CO-03 and RC.CO-04 ("Public updates on incident recovery are shared using approved methods and messaging").

2. Roles and approvals

Each role must have a named deputy. NCSC advises recording "at least 2 contact methods and 2 or more people" for each key contact.

Approval matrix

3. Stakeholder map

Incident stakeholder communication starts from this map: each group, what it needs, how to reach it when normal systems are down and who owns the relationship.

4. Out-of-band communication channels

Assume that corporate email, chat and collaboration tools may be unavailable or monitored by the attacker during any [SEV1 or SEV2]. CISA's federal playbook calls for channels "(chat rooms, phone bridges) and method for out-of-band coordination" and for notifying users of compromised systems by phone rather than email. In the Co-op cyber attack, staff were warned that their communications might be monitored.

• Response bridge: [conference number or service], with a PIN held offline.
• Secure messaging group: [service] on devices not enrolled in the affected identity provider, with accounts not federated to it.
• Alternate email: [separate tenant or domain] for regulator and customer notices if the main domain is compromised.
• Status page: hosted on [provider] outside the production estate and the corporate identity provider, with [2] named publishers using phishing-resistant MFA.
• Printed contact sheet: sections 2 and 3 contacts, held by [roles] and refreshed [quarterly].
• Verification rule: confirm any unexpected instruction received during an incident (a payment, a password reset, a "new" channel) by calling back a number from this plan. Attackers impersonate executives and help desks during incidents.

5. Communication rules

1. One source of truth: every message is built from the incident manager's verified facts log, stamped with time (UTC) and version.
2. Say what is known, what is being done and when the next update will come. NCSC asks for communications that are "clear, consistent, authoritative, accessible and timely".
3. Do not speculate on cause, attacker, scale or timescales, and do not say "no evidence of data access" until the investigation can support it. NCSC warns against statements that may later need retracting. Co-op's early message to members in 2025 said attackers had accessed "a limited amount of member data"; it later confirmed that data on all 6.5 million members had been stolen.
4. Do not disclose details that increase risk, such as unpatched weaknesses, security tooling or containment plans, or that could prejudice regulator or law enforcement investigations.
5. Reflect real impact on people (cancelled appointments, delayed payments, manual processes), not only systems.
6. Stay consistent: core facts must match across staff, customer, regulator and press messages, because detailed information shared with any group may reach the media.
7. Do not comment on ransom demands, negotiations or attribution unless [Executive sponsor] and [Legal] approve.
8. Record every message sent: audience, channel, approver, time and version.

6. Notification timelines

Record the time [Organisation] became aware of the incident: most clocks start then, not when the investigation ends. The table summarises common regimes; [Legal] confirms which apply to each legal entity.

Under DORA, a deadline falling on a weekend or bank holiday may move to noon on the next working day, but not for initial notifications and intermediate reports by credit institutions, central counterparties, trading venue operators or NIS2 essential and important entities. If a DORA deadline cannot be met, tell the competent authority before it passes. See the Data Breach Notification Checklist, the DORA Guide and the SEC Cybersecurity Disclosure Rules Guide.

7. Holding statements

Pre-approve one version per scenario ([outage], [ransomware], [data breach], [supplier incident]). NCSC advises that templates "should be adaptable to different types and attack severity".

7.1 External incident holding statement

"[Organisation] is responding to a cyber security incident affecting [some of our systems / service name]. We took immediate steps to [contain the incident / take systems offline as a precaution] and are working with [specialist incident response partners]. [Service] is [unavailable / operating with reduced functionality]. Our investigation is ongoing and we will share verified information as soon as we can. [We have informed the relevant authorities.] Customers can find updates at [status page URL] and contact [support line]. Our next update will be by [time and date]."

7.2 Internal staff message

"We are dealing with a cyber security incident affecting [systems]. Please: do not [log in to / switch on] [systems] until told; report anything unusual to [number]; do not discuss the incident on social media or with media, and refer all enquiries to [press office]; expect updates through [out-of-band channel] at [times]. Verify any call or message asking for passwords, codes or payments by calling [number]."

8. Regulator notification template

Use the regulator's own form or portal where one exists; keep these fields ready. The ICO lists the content of a breach report as follows.

• Reporting organisation: [legal entity, registration number], contact point [DPO name, phone, email].
• Timeline: date and time of the incident (if known), of becoming aware and of this report; reasons for any delay.
• Description: nature of the incident and of the breach, categories and approximate number of individuals and of records concerned.
• Likely consequences: [for example, risk of fraud, phishing, loss of access to services].
• Measures: taken or proposed to address the breach and reduce adverse effects, including notifications to individuals.
• Status: [initial / follow-up / final] report; further information expected by [date].

9. Customer breach notification template

Subject: Important information about your [Organisation] account

"Dear [name], we are writing to tell you about a security incident that affects your personal information. On [date] we discovered that [plain description of what happened]. The information involved is [data categories]. [It did not include data categories.] We have [actions taken] and reported the incident to [regulator]. What this means for you: [likely consequences]. What you should do: [specific steps, for example reset your password, be alert to emails or calls that mention this incident, check statements, rotate any API keys or tokens issued by [Organisation]]. We will never ask you for your password or payment details by phone or email. Questions: [dedicated line, hours, email] or our [DPO] at [contact]. We are sorry this has happened. [Name, role]"

The ICO expects individuals to be told in "clear and plain language", with the contact point, likely consequences, measures taken and specific advice on protecting themselves. Prepare the support script and FAQ page before sending, and send from a domain and system confirmed clean, because attackers follow breach notices with phishing that copies them.

10. Incident press statement and Q&A

Issue an on-the-record statement built from section 7.1 plus confirmed facts, and keep a Q&A for the spokesperson. NCSC's examples of likely questions are the first five below.

11. Incident status page and update cadence

Each status update states the affected services, current status (investigating, identified, monitoring, resolved), what customers should do and the time of the next update. Always give the next update time, even if there is nothing new to report.

12. After the incident

• Publish a closing update covering recovery, impact on data and the steps taken to prevent recurrence (CSF 2.0 RC.CO-04).
• Expect the story to return, for example when stolen data is published or a regulator acts, and keep reactive lines ready for [12 months].
• Review the communications response within [10 business days] with feedback from staff, customers and the communications team, and update this plan.

13. Testing and maintenance

• Contacts: verify every contact and out-of-band channel [quarterly].
• Exercise: include a communications injection (journalist call, regulator deadline, leaked data claim) in [annual] tabletop exercises. See the Tabletop Exercise Guide.
• Spokesperson: media training for the spokesperson and deputy every [year].
• Review: after every [SEV1 or SEV2], after regulatory change and at least [annually].

Implementation guidance

1. Fill sections 2, 3 and 4 first: named people, deputies and working out-of-band channels decide the first hour.
2. Map notification duties per entity: list which section 6 regimes apply to each legal entity, who decides materiality or significance, and where each regulator's form lives.
3. Pre-approve the words: agree sections 7 to 10 with [Legal] and the executive sponsor so that only bracketed facts change during an incident.
4. Stand up the status page and alternate email, and test publishing from them with the main identity provider unavailable.
5. Exercise and fix: run a tabletop within [90 days] and measure time to first holding statement, time to approval and regulator deadlines met.

Small organisations can combine the communications lead and spokesperson roles and use a retained communications adviser, but still need a deputy and an out-of-band channel. Large or listed organisations should add a disclosure committee, regional regulator contacts and translated templates, and track: time from declaration to first holding statement, percentage of notifications made within deadline, number of retracted or corrected statements (target zero), and contacts verified in the last quarter. For ransomware-specific messaging, see the Ransomware Playbook Template.

Standards and references

• NCSC: Guidance on effective communications in a cyber incident
• NCSC: Incident management, cyber incident response processes
• ICO: Personal data breaches, a guide
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• EUR-Lex: Commission Delegated Regulation (EU) 2025/301 (DORA incident reporting time limits)
• SEC: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks

This template summarises communication practice and notification duties for guidance and must be adapted to your organisation; it is not legal advice. Related NHI Mgmt Group resources: Incident Response Plan Template · Cyber Resilience Guide · Incident Response Guide · NIS2 Directive Guide · Leaked Credential Response Playbook