A cyber incident communications plan helps an organization notify the right people with accurate, appropriately limited information. This reusable communications matrix covers employees, customers, vendors, insurers, law enforcement, regulators, executives, and the board, with decision points for suspected versus confirmed impact, approval ownership, delivery channels, follow-up timing, and recordkeeping.
Overview
Incident communications are part of the response process, not an announcement made after the technical work is finished. A message can reduce confusion, preserve trust, support containment, and create a clear record of what the organization knew and when it acted. Poorly timed or overly specific communications can also expose sensitive details, create inconsistent accounts, or conflict with legal and contractual obligations.
Use this guide as a working security incident communications matrix. Before sending a message, confirm the applicable requirements for the affected locations, people, data types, contracts, insurance policy, and sector. Notification duties vary, so involve the organization’s legal and privacy decision-makers when the incident may involve personal information, regulated systems, material business disruption, or third-party data.
The central rule is simple: communicate what is known, distinguish it from what is being investigated, explain what the recipient should do, and commit to a specific next update. Avoid speculation, blame, and technical detail that does not help the audience make a decision.
What to track
1. Incident facts and confidence level
Maintain a short, approved fact set that every audience can draw from. Track the incident start time or estimated window, detection time, affected systems, suspected access method, containment status, business impact, data potentially involved, and current investigative gaps. Label each item as confirmed, suspected, or unknown. This prevents a preliminary hypothesis from being repeated as an established fact.
For example, “unauthorized access to a customer-facing application is confirmed” is different from “customer records were downloaded.” If exfiltration has not been established, say that the investigation is assessing whether information was accessed or acquired. Update the language when forensic findings change the confidence level.
2. Audience, purpose, and owner
Each communication should have one accountable owner and one defined purpose. Use the following matrix as a starting point:
| Audience | Primary purpose | Information to include | Approval or coordination |
|---|---|---|---|
| Employees | Protect people and support consistent operations | What to avoid, reporting instructions, approved talking points, and work changes | Incident lead, HR, IT, and communications |
| Customers or affected individuals | Explain potential impact and protective steps | Known facts, affected information categories, actions, support channel, and next update | Privacy, legal, communications, and business owner |
| Vendors and partners | Coordinate dependencies and prevent further spread | Required actions, access changes, evidence requests, and response deadlines | Incident lead, procurement, security, and contract owner |
| Insurer | Preserve coverage and meet policy processes | Initial facts, timing, suspected impact, response contacts, and requested documentation | Executive sponsor, legal, and policy owner |
| Law enforcement | Share relevant information and request assistance when appropriate | Timeline, indicators, loss or threat details, and evidence preservation status | Legal and executive incident leadership |
| Regulators or authorities | Meet applicable notification or reporting duties | Required incident, organization, impact, contact, and remediation information | Privacy officer, legal, and designated compliance owner |
| Executives and board | Enable decisions, oversight, and risk management | Business impact, response status, decisions needed, risks, and expected next milestones | Incident commander and executive sponsor |
3. Delivery details and evidence
Track the approved message, sender, recipient group, channel, send time, delivery result, and follow-up owner. Use a verified channel rather than contact information supplied in a suspicious message. For employees, that may mean the established internal alert system and a known help desk route. For customers, use verified account or notification channels and provide a way to confirm that a message is genuine.
Keep an incident communications log separate from informal chat. Record who approved each message, what facts were available at the time, which audiences were excluded, and why. Preserve revisions so the organization can explain how its understanding developed.
For related operational controls, review the business security incident response checklist and the third-party cyber incident response template.
Cadence and checkpoints
Set communication checkpoints before the incident becomes a public story or an internal rumor. The exact timing depends on the facts and applicable obligations, but the following sequence gives teams a practical structure:
- Initial assessment: Notify the incident team, executive sponsor, and relevant technical owners when a credible event is identified. State that the incident is under investigation if impact is not confirmed.
- Stabilization: Provide employees and critical vendors with instructions needed to contain the event, such as preserving evidence, avoiding affected systems, or routing inquiries to one contact.
- Decision checkpoint: Decide whether customers, regulators, insurers, law enforcement, or other parties must be contacted. Document the decision, assumptions, and approvers.
- First external update: Send a concise notification when the audience needs to act or when a confirmed impact requires disclosure. Do not delay necessary protective guidance while waiting for every investigative question to be answered.
- Follow-up cycle: Schedule the next update even if there is no major change. “The investigation remains active; no additional information is available today” is more useful than silence when recipients are waiting for direction.
- Closure and review: Provide remediation information, explain remaining precautions, close open questions where possible, and archive the complete communications record.
Every draft should pass five checks: Is the audience correct? Are confirmed facts separated from uncertainty? Is the requested action clear? Is the channel appropriate? Has the message been approved by the person accountable for the risk?
How to interpret changes
Changes in the investigation should change communications only when they affect recipient decisions, legal analysis, operational risk, or the credibility of an earlier message. A new technical indicator may matter to the response team but not to customers. Conversely, confirmation that a particular data category was involved may require a revised customer or regulator message.
Use consistent uncertainty language. “We have identified evidence of access” is not interchangeable with “we have confirmed acquisition.” “Potentially affected” should be paired with an explanation of what is being assessed and what recipients can do now. Avoid giving a precise number or date when the investigation cannot support it.
If a previous message was incomplete or materially wrong, issue a correction directly to the affected audience. Identify the corrected point without burying it in unrelated updates. Internally, brief support and customer-facing teams first so they can answer questions consistently.
Review communications alongside technical findings, vendor updates, and legal analysis. The cybersecurity advisory checklist can help teams validate a vulnerability-related alert before describing its cause. If a notification may be fraudulent or spoofed, use the data breach notification verification guide before responding through links or phone numbers in the message.
When to revisit
Revisit this communications matrix quarterly and after any significant change to the organization, its systems, vendors, insurance requirements, or privacy obligations. A recurring review should confirm contact ownership, emergency channels, executive and board escalation paths, vendor notification clauses, insurer instructions, regulator links, and approved customer-support language.
Use a tabletop exercise at least as often as the wider incident response plan is tested. Give participants a scenario involving uncertain impact, a third-party dependency, and a need to communicate before the investigation is complete. Measure whether the team can identify audiences, approve a message, protect sensitive information, and record decisions without relying on one unavailable person.
Update the plan immediately after a real incident, near miss, failed delivery, or material legal change. Compare the intended process with what actually happened: Which audience was missed? Which facts changed? Where did approvals stall? Did recipients know what action to take? Turn those findings into named owners and due dates.
For a practical next step, copy the matrix into the incident response workspace and add columns for owner, backup owner, approved channel, legal checkpoint, last review date, and next update time. Link it to the organization’s first-24-hour checklist and personal data recovery guidance. A communications plan is useful only when it is current, rehearsed, and ready to use before the next security incident occurs.
