What to say when you have a breach: a practical guide to cyber crisis communication

why communication failures make breaches worse

When an organisation is breached, there are two reputational events. The first is the breach. The second is how the organisation handled it. The second event is often the larger one. Research cited by PwC suggests that companies practising transparent communication during a crisis restored their reputation significantly faster than those that tried to manage or delay disclosure. The organisations that suffered the most lasting damage were not always those that had the worst incidents. They were the ones that communicated poorly: too late, inconsistently, in technical language their audiences could not interpret, or not at all until regulators or journalists forced their hand.

The mechanisms are straightforward. When an organisation goes quiet after an incident becomes public, other voices fill the gap: journalists working with incomplete information, former employees, security researchers, or in some cases the attackers themselves. Once that narrative forms, correcting it requires more effort than establishing it would have. Organisations that communicate early, even before the full picture is clear, keep control of the record. Delayed communication also has a measurable trust cost. Industry research indicates that customer trust drops significantly more when organisations delay their response compared to those that communicate promptly.

the five ways cyber crisis communication differs from standard crisis comms

Most organisations have some form of crisis communication capability. Cyber incidents do not fit cleanly into those frameworks because they have five structural differences.

Motivated, organised adversaries. A cyber incident involves a party who may be actively working to shape the public narrative. Ransomware groups have posted stolen data publicly. Attackers have published communications during ongoing incidents.

Rapid propagation. A breach that starts in one system can affect others in minutes. What you communicate at hour one may be outdated by hour three. Communication cadence needs to match the pace of technical developments.

Technical complexity. Translating what happened into language that employees, customers, and board members can act on, without overstating or understating the severity, is a genuine skill. Most communications functions do not have someone with the technical fluency to do this well under pressure.

Attribution ambiguity. You often do not know who did this, and in many cases you will not know for weeks. Public statements about who was responsible, made before a proper investigation, create legal and geopolitical risk. The guidance from European security agencies is consistent: avoid public attribution without solid evidence.

Heightened reputational sensitivity. A breach involves other people's data. The emotional response from customers and employees is different from a manufacturing quality problem or a service outage. It carries a personal dimension that requires a different communication register.

who needs to hear what and when

Employees. Staff need to know what happened, what they should and should not do, and where to go for updates. This is the audience most likely to answer questions from customers, family, or journalists without intending to. A clear internal briefing early reduces the risk of inconsistent external statements. It needs to reach people through channels that will function if your email is down.

Customers and affected individuals. Where personal data may have been affected, customers need factual information about what happened, what data was involved, the potential consequences, and what they can do. This should be clear, free of technical language, and accompanied by practical guidance. Concrete support measures, such as credit monitoring, shift the communication from acknowledgement to action.

Regulators and supervisory authorities. Regulatory notification is not optional where the legal threshold is met. The content should be factual, transparent, and complete within the constraints of what you know at notification time. Proactive coordination typically results in better outcomes than disclosure that feels forced.

Partners and suppliers. If the incident may affect connected systems or shared data, partners need to know promptly. This is often underprioritised. A breach that started with a supplier, or that could propagate through supply chain connections, creates obligations that run in both directions.

Board and executive leadership. The board needs a clear picture of what happened, the scope, the regulatory obligations triggered or likely, the communication decisions being made, and the decisions that require board-level input. This needs to happen early rather than when the picture is fully formed.

Media. If the incident is publicly known or likely to become so, a proactive press statement is better than waiting for the first journalist call. A prepared spokesperson, a clear statement, and a single point of contact for press reduce the chaos of managing multiple journalists working with different partial information.

the principles: what effective incident communication looks like

Speak early, even without full facts. The most common mistake is waiting. A short factual holding statement acknowledging an incident under investigation, without speculating about scope or cause, is better than silence. Silence gets filled.

Be honest about what you know and what you do not. The statement "we are aware of an incident affecting [systems/data] and are actively investigating; we will share a further update by [time]" is accurate, and reads as honest rather than evasive. Overstating certainty before the investigation is complete creates the worst outcome: a correction that looks like a cover-up.

One source of truth. Multiple spokespersons saying different things is one of the fastest ways to destroy credibility. Every external communication should come through a defined spokesperson or be visibly coordinated. Every internal communication should direct employees to a single, authoritative update source.

Avoid over-promising. Do not commit to timelines you cannot keep. A missed commitment creates a second credibility problem on top of the first. Use ranges or review windows rather than hard dates where there is genuine uncertainty.

Calibrate the register. Technical language appropriate for the security team is not appropriate for a customer email. The customer needs to know what data was involved, what the risk is to them, and what they should do. Translating technical findings into audience-appropriate language is a step that needs to be planned for, not improvised.

Update regularly, even when there is nothing new. Silence between initial disclosure and resolution reads as concealment or confusion. Regular updates that say "investigation ongoing, no significant new developments, next update at [time]" signal that someone is in control.

the regulatory clocks: GDPR and NIS2

GDPR: 72-hour notification. Under GDPR (Article 33), where a personal data breach is likely to result in a risk to the rights and freedoms of individuals, the controller must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. The clock starts when you become aware, not when the investigation is complete. The notification does not require complete information: GDPR explicitly allows notification in phases. Where the breach is likely to result in a high risk to individuals, Article 34 requires direct communication to the affected individuals as well, without undue delay. Not every incident triggers the obligation; the threshold is risk to individuals, and the assessment needs to be documented either way.

NIS2: incident reporting for covered entities. For organisations within the scope of NIS2, the incident reporting obligations are more detailed. NIS2 requires covered entities to submit an early warning to the competent authority within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours updating the early warning with an initial assessment of severity and impact, and a final report not later than one month after the notification covering the full description, root cause, mitigation measures, and cross-border impact. These timelines run in parallel with any GDPR obligations.

The practical implication of both frameworks: the first 72 hours of an incident are not just a technical window. They are simultaneously a regulatory window. The documentation you generate during that period, including the internal records of when you became aware and what steps were taken, serves both the technical response and the regulatory reporting.

preparing before an incident

The most consistent finding across incident post-mortems is that organisations whose communication response went well had prepared before the incident. The ones that struggled were improvising.

Pre-drafted holding statements. Write them before you need them. A holding statement for "incident under investigation, limited information available" is generic enough to apply to almost any incident and specific enough to be useful immediately. Scenario-specific templates require more preparation but are more useful.

A named spokesperson. Decide who speaks externally before an incident. The conventional answer is the CEO, and this is often the wrong answer. When the most senior executive becomes the public face of a crisis, every subsequent development becomes a personal credibility issue, and the organisation's response becomes their story. A senior leader who is not the CEO, properly briefed and trained, is typically a better choice.

An internal communications tree. Who tells the board, the management team, department heads? Who is responsible for staff briefings, and through which channel? This needs to be mapped and tested, not invented during the incident.

Channels that work if your email is down. A ransomware attack that encrypts your servers may also take down your email. If your primary communication channels were unavailable, how would you reach your staff, customers, and the press? Backup channels need to be defined before the incident. Stakeholders should also be told in advance which channels you will use in a crisis, so emergency communications are recognisable as legitimate and fraudulent imitations can be identified.

Regular testing. Communication preparation that has never been tested is only as good as the assumptions behind it. A simulated incident exercise that runs the communication response in real time surfaces problems while they can still be fixed.

managing communication during a live incident

Hours 0-2: initial notification. Acknowledge the incident internally as soon as confirmed, with an instruction about what staff should and should not do immediately. Issue an initial external holding statement if the incident is or may become publicly known.

Hours 2-24: stabilisation. Update on a regular cadence, even when the news is "investigation ongoing." Regulatory notification under GDPR and NIS2 needs to be prepared and submitted within the applicable windows.

24-72 hours: regulatory completion and customer communication. By 72 hours, GDPR supervisory authority notification should be filed if the threshold is met, and NIS2 incident notification submitted for covered entities. Where customer communication is required, it should be going out, not being drafted. Partners and suppliers whose operations or data may be affected should receive direct communication.

Beyond 72 hours: resolution communication. As the incident is contained and recovery begins, the focus shifts from "what happened" to "what we have done and are doing." Where timelines remain uncertain, say so plainly.

what not to say

Do not speculate about cause or attribution before investigation. Statements about a sophisticated nation-state attack or a specific group, made before the investigation supports them, create the conditions for a damaging correction. Say what you know.

Do not minimise. "A small number of records" may be accurate and still create a credibility problem if the final count is significantly larger. Calibrate the language to the known facts.

Do not over-commit on timelines. "All systems will be fully restored by [date]" becomes front-page news if missed. Use "we expect to have more information by [date]."

Do not use technical language for non-technical audiences. The customer email is not the place for CVE numbers or threat actor identifiers. Translate.

Do not go silent. A gap in communication during an active incident reads as confusion, concealment, or loss of control.

Do not use hedging language that sounds like legal protection but reads as evasion. "We take security very seriously" and "we apologise for any inconvenience this may have caused" are the two phrases most associated with organisations that are not taking the situation seriously. Replace them with facts and actions.

the after-action review

The post-incident review of how communication was handled is as important as the technical post-mortem. What you learned about who knew what, and when, shapes the next iteration. Retain the full record of how you communicated: what was said, when, to whom, through which channel, and by whom it was approved. That record is both the input to the review and part of the evidence base for regulatory and audit purposes.