A cyber attack hits your organisation. Your security team jumps into action, containment protocols kick in, and technical recovery begins. But within minutes, the real chaos starts, employees panic, customers demand answers, regulators expect notifications, and journalists start calling. Without a solid incident response communications plan, even a well-handled technical response can spiral into reputational and legal damage that far outlasts the breach itself.
Most organisations invest heavily in detection and response tooling but treat communications as an afterthought. That’s a costly mistake. Poorly timed disclosures, contradictory statements, or silence during a crisis erode trust faster than the incident itself. Regulatory frameworks such as GDPR and NIS2 impose strict notification deadlines, and failing to meet them carries penalties. Your stakeholders, from board members to customers, need clear, coordinated messaging at every stage.
At TrustedIA, our CyberSOS Incident Response service has put us at the centre of live cyber incidents alongside insurers, loss adjusters, and affected businesses. We’ve seen firsthand how prepared communication separates a controlled recovery from a public crisis. That experience, combined with over 30 years in managed cybersecurity services and ISO 27001 implementation, informs every recommendation in this guide.
This article walks you through building an incident response communications plan from scratch, covering roles, message templates, escalation triggers, stakeholder mapping, and testing. By the end, you’ll have a practical framework you can adapt to your organisation’s size, sector, and risk profile.
What an incident response communications plan includes
An incident response communications plan is a documented, pre-approved framework that defines who says what, to whom, through which channel, and when during a security incident. It sits alongside your technical incident response plan but focuses entirely on the human side of a crisis: keeping stakeholders informed, managing regulatory obligations, and protecting your organisation’s reputation while your team works to resolve the underlying problem.
The six core components
Most plans share six building blocks regardless of organisation size or sector. Each one serves a distinct purpose, and gaps in any of them tend to surface at the worst possible moment.
| Component | Purpose |
|---|---|
| Stakeholder register | Identifies every internal and external audience, their information needs, and who owns the relationship |
| Communication roles | Assigns spokesperson, approver, drafter, and channel owner responsibilities |
| Escalation triggers | Defines the severity thresholds that activate different levels of communication |
| Message templates | Pre-approved draft statements for customers, staff, regulators, and media |
| Channel map | Specifies which platform to use for each audience and what the backup is if primary channels are compromised |
| Post-incident report | Outlines how and when you communicate lessons learned, remediation steps, and final status |
Having these six components documented before an incident means your team won’t have to write from scratch under pressure. Pre-approved templates, in particular, reduce decision-making time during the first critical hours, when every minute of delay increases both reputational and regulatory risk.
What separates a plan from a document
Many organisations confuse having a document with having a plan. A document lives in a folder; a plan lives in your team’s habits. The distinction matters because, during an incident, people revert to what they have practised. If your communications plan has never been tested through a tabletop exercise or a live drill, it will fail when you need it most.
A communications plan only works if the people responsible for executing it have rehearsed it under realistic conditions.
Your plan also needs clear ownership at every layer. Someone must be authorised to approve external statements without waiting for a committee. Someone else must own regulatory notifications and know the exact deadlines imposed by frameworks like GDPR’s 72-hour breach notification window. Without that clarity, approvals stall, deadlines slip, and you create additional legal exposure on top of the technical incident itself.
Why templates are non-negotiable
Writing under pressure produces vague, inconsistent, or legally risky statements. Pre-built message templates give your team a starting point that has already passed legal and senior leadership review, so you adapt them to the specific facts of the incident rather than drafting from a blank page while under threat.
A basic template for an initial customer notification looks like this:
Subject: Important security notice from [Organisation Name]
We are writing to inform you that we recently identified a security incident affecting [brief description of affected systems or data]. We took immediate steps to [contain / investigate / resolve] the issue and are working with cybersecurity specialists to assess the full scope.
At this stage, we [have/have not] identified evidence that your personal data was accessed. We will provide a further update by [date/time].
If you have any concerns or questions, please contact [dedicated contact point].
Keep templates short, factual, and free of speculation. Avoid committing to causes or scope until your technical team has confirmed the details in writing.
Step 1. Define scope, triggers, and audiences
Before you write a single template or appoint a spokesperson, you need to establish the foundation of your incident response communications plan: a clear definition of what events require communication, at what severity level, and to which audiences. Without this groundwork, your team will spend critical time debating whether something counts as an incident, who needs to know, and how urgently they need to know it.
Scope: what counts as a notifiable incident
Not every security alert requires stakeholder communication. A failed login attempt is handled internally; a ransomware attack encrypting your customer database is not. Defining scope means drawing a clear line between operational noise and genuine incidents that activate your communications process.
Common events that should fall within scope include:
- Confirmed or suspected data breach affecting personal or sensitive data
- Ransomware or malware deployment affecting business operations
- Unauthorised access to critical systems or administrative accounts
- Third-party supplier breach with potential impact on your data
- Denial-of-service attack causing customer-facing service outages
Trigger levels and thresholds
Severity tiers give your team a shared language for escalation decisions. Most organisations use a three-tier model, and you can adapt the labels to fit your existing terminology.
| Tier | Description | Communication action |
|---|---|---|
| Low | Contained issue, no data exposed, no service impact | Internal notification only |
| Medium | Potential data exposure or partial service disruption | Internal plus selected stakeholders |
| High | Confirmed breach, significant disruption, or regulatory trigger | Full plan activation, regulator notification |
Map each tier to a specific time window for initial communication. For example, a High-tier incident should trigger an internal alert within one hour and an external holding statement within four hours. These windows keep your team accountable and prevent delays caused by uncertainty about whether the situation is serious enough to act on.
The clearer your trigger thresholds, the less debate you have during a live incident when every hour of delay increases both regulatory and reputational risk.
Mapping your stakeholder audiences
Your stakeholder map identifies every group with a legitimate interest in knowing about an incident, what information they need, and how quickly they need it. Group them by relationship rather than seniority or alphabetical order.
Internal audiences typically include your executive team, IT and security staff, legal counsel, HR, and customer-facing teams. External audiences cover customers, regulators such as the ICO under UK GDPR, insurers, and potentially the media. Document a named owner for each audience group, so there is no ambiguity about who picks up the phone when your plan activates.
Step 2. Assign roles, approvals, and escalation paths
Your incident response communications plan will stall the moment two people assume the other is handling a critical notification, or when no one has the authority to approve an external statement without a committee sign-off. Assigning named roles, documenting approval chains, and establishing clear escalation paths before an incident occurs removes that ambiguity entirely. You want your team to execute decisions, not debate who has the right to make them.
The core communication roles
Every organisation, regardless of size, needs at least four distinct roles covered during a live incident. Larger organisations may split these across multiple individuals; smaller teams may have one person covering two roles. What matters is that each function is explicitly assigned, and the assigned person knows their responsibilities in advance.
| Role | Responsibility | Who typically fills it |
|---|---|---|
| Incident Communication Lead | Coordinates all messaging, owns the master log, and ensures consistency across channels | CISO, IT Manager, or senior security lead |
| Spokesperson | Delivers all external statements to media, customers, and regulators | CEO, Communications Director, or pre-designated senior leader |
| Legal Approver | Reviews all external-facing communications before release | In-house counsel or retained legal adviser |
| Stakeholder Liaison | Manages direct outreach to specific audience groups (insurer, ICO, key accounts) | Named account manager or compliance officer |
Document the name, direct phone number, and out-of-hours contact for each role in a printed copy of your plan, not just a shared drive. During a ransomware attack, your systems may be inaccessible.
Escalation paths and approval chains
An escalation path defines who gets notified, in what order, and within what timeframe when an incident moves up a severity tier. Without a documented path, decisions bottleneck at the top because every message waits for senior leadership approval, even routine internal updates.
The fastest way to miss a regulatory deadline is to require the CEO to approve every communication at every tier.
Structure your escalation so that Low-tier incidents are approved by the Incident Communication Lead, Medium-tier require the Legal Approver’s sign-off, and High-tier notifications trigger the Spokesperson and a mandatory board briefing. A simple escalation matrix works well here:
- Low: Incident Communication Lead approves, notifies IT, team within 1 hour
- Medium: Legal Approver reviews, Incident Communication Lead notifies selected stakeholders within 2 hours
- High: Legal Approver plus Spokesperson sign off, full plan activates within 4 hours, regulatory notification initiated within 24 hours
Rehearse this chain in a tabletop exercise at least once a year so every named individual understands their trigger point before a real incident puts them under pressure.
Step 3. Set channels and a single source of truth
The communication channels you rely on every day may be exactly what an attacker has compromised. Ransomware frequently encrypts shared drives and disables cloud collaboration tools; a phishing compromise may put your email under adversary control. Your incident response communications plan must specify both primary channels and pre-agreed backup alternatives for each audience, so your team can coordinate and communicate accurately even when your normal infrastructure is unavailable or untrusted.
Choose channels by audience, not by convenience
Every audience in your stakeholder map has a preferred channel and a specific information need. Mapping these in advance ensures your team sends the right message through the right medium, rather than defaulting to whatever feels fastest under pressure. Build a channel map as part of your plan and store a printed copy alongside your escalation matrix.
| Audience | Primary channel | Backup channel |
|---|---|---|
| Executive team | Encrypted messaging app (e.g., Signal) | Direct phone call |
| IT and security staff | Incident management platform | Out-of-band group call |
| Customers | Website status page | |
| Regulator (ICO) | Secure email with read receipt | Recorded phone call plus written confirmation |
| Media | Press statement via official website | Spokesperson phone briefing |
| Insurer | Named account contact via email | Direct phone to claims handler |
Test every backup channel at least once during your annual tabletop exercise. Discovering that nobody knows the Signal group PIN or who manages the website status page during a live incident is an entirely preventable failure.
Build a single source of truth
During a fast-moving incident, version control and message consistency collapse quickly when multiple people draft and distribute communications independently. You need one central location where every approved statement, update, and regulatory notification is logged, timestamped, and version-controlled before it leaves your organisation.
A single source of truth is not a convenience; it is your legal record of what you communicated, to whom, and when.
In practice, this means designating one document or incident management log as the master communication record. Every draft, approval, and sent message gets recorded there with the approver’s name and a timestamp. Your existing incident management platform works well for this, provided your team has out-of-band access if primary systems go down. Assign one named individual to own this log, because when everyone is responsible, nobody maintains it. Those records become critical evidence if regulators or insurers review your response after the fact.
Step 4. Build templates, cadence, and post-incident comms
Your incident response communications plan needs more than a set of templates sitting in a folder. You need a communication cadence: a pre-agreed schedule that tells every role how often to send updates, what format to use, and when to move from active incident mode to post-incident reporting. Without a cadence, stakeholders fill the silence with speculation, and your team fields distraction calls instead of managing the response.
Set your update schedule
Frequency matters as much as content during a live incident. For a High-tier event, send internal updates every two hours and external holding statements every four hours, even when the only update is that your team is still investigating. Silence reads as incompetence or concealment.
A basic cadence looks like this:
| Phase | Internal updates | External updates |
|---|---|---|
| First 4 hours | Every hour | Initial holding statement |
| Hours 4-24 | Every 2 hours | Every 4 hours or on confirmed development |
| Days 2-7 | Twice daily | Daily or on material change |
| Resolution | Single final brief | Customer and regulator close-out notice |
The moment stakeholders stop receiving updates from you, they start forming their own conclusions about what is happening and why.
Draft your core templates in advance
Pre-approved templates cut response time and prevent your team from writing under pressure. Build at least four: an internal staff alert, a customer holding statement, a regulatory notification, and a media statement. Each should have clear placeholders for incident-specific facts rather than anything speculative.
Here is a straightforward internal staff alert template:
To: All staff
From: [Incident Communication Lead]
Subject: Security incident update – [Date/Time]
Our security team is currently managing a security incident affecting [brief description]. Please do not discuss this matter externally or on personal devices.
What you should do: [specific action, e.g., log out of all systems / avoid clicking email links]
We will send the next update by [time]. Direct any questions to [named contact].
Close the loop after the incident
Post-incident communication is not optional. Once your team resolves the incident, send a close-out notice to each stakeholder group confirming what happened, what you did, and what you have changed. Regulators expect it, insurers review it, and customers remember whether you followed through. Keep it factual, avoid over-promising on future security, and distribute it within two weeks of resolution.
Quick wrap-up
Building a solid incident response communications plan is not a one-time project. It is a living framework that you review at least annually, test through tabletop exercises, and update whenever your team structure, systems, or regulatory obligations change. The steps in this guide give you a clear starting point: define your scope and triggers, assign named roles with documented approval chains, map your channels and establish a single source of truth, then build templates and a communication cadence that works before, during, and after an incident.
The organisations that recover well from cyber incidents are not necessarily the ones with the most sophisticated technical defences. They are the ones who communicate clearly and consistently when it matters most. If you want expert support building your plan or need a response partner ready when an incident hits, speak to the TrustedIA team about our CyberSOS Incident Response service.
