Cyber incident communication: plan before rumours take over

An organisation can run a technically competent incident response and still lose trust. Employees, customers and partners see an unavailable service, a worrying email or reports on social media, but do not know what has happened. Rumours, unsafe advice and impersonators quickly fill that information gap.

On 16 October, CERT Polska published new guidance on cyber crisis communication. It highlights four questions audiences need answered: what happened, whether they are affected, what the organisation is doing and how they can protect themselves. The guidance is aimed at communications and crisis-management staff as well as senior leadership.

Breachroad’s conclusion: the first statement does not need a complete diagnosis, but it must be truthful, useful and owned. Remaining silent until the investigation is finished is rarely neutral—it leaves people without safe instructions and gives misinformation room to grow.

Communication is part of response, not an appendix

A message can reduce the impact of a technical event. Where accounts may be exposed, users can receive safe instructions to change passwords, enable MFA or watch for follow-on phishing. During an outage, customers can learn which alternative channel is genuine. If criminals are using stolen information to impersonate the organisation, an early warning can interrupt some attempts.

That requires three workstreams to meet:

• the technical team establishes facts, scope and confidence;
• legal and risk owners assess obligations and the consequences of disclosure;
• communications turns confirmed findings into clear instructions for each audience.

No one team should operate alone. Communication without evidence may mislead people, while an investigation without communication may leave them exposed to repeatable harm. CERT Polska also notes that some organisations have legal duties to inform service users. The applicable deadlines, recipients and content should be established with the organisation’s compliance and legal owners.

What the first statement should contain

The initial version should be concise. Its purpose is not to tell the whole story but to establish order. A useful first statement includes:

1. when the event was detected or occurred, if confirmed;
2. the service or business process affected;
3. the known impact and a clearly marked area still under investigation;
4. actions the organisation has taken;
5. a concrete instruction for the reader, or confirmation that no action is currently required;
6. the official update channel and time of the next statement.

Do not present a cause, actor or data scope as fact before evidence supports it. Instead of saying “no data was leaked”, state that the assessment of data impact is ongoing when that is the actual position. Rather than promising an exact restoration time, commit to the next update time.

One message does not fit every audience

An employee needs to know how to work and where to report suspicious messages. A customer wants to understand service and data impact. A technical partner needs a coordinated channel. A regulator or CSIRT may require different detail, timing and format. Journalists need an authorised spokesperson.

Prepare an audience map and message owners in advance. This does not mean creating contradictory narratives. The factual core should remain consistent, while instructions and detail reflect each audience’s role.

The communication channel itself may fail. If corporate email or the website is part of the incident, a prepared status page, call centre or secondary employee channel becomes a business-continuity control. Introduce backup channels before a crisis; a new domain announced during an incident may itself look like phishing.

Update people even when little has changed

No breakthrough does not justify hours of silence after a promised update. A short statement that the investigation continues, service remains limited and advice is unchanged reassures people that the official channel is still operating.

Give each message a number or publication time. If earlier information was wrong, correct it explicitly and explain what changed. Silently deleting an old statement allows screenshots to circulate and undermines the credibility of the new version.

Record the approval basis as well: who supplied the technical fact, who assessed the impact and who authorised publication. That trail maintains consistency when shifts change and helps improve the process afterwards.

A no-tools exercise

Use this scenario: at 08:15 on Monday, some customers cannot sign in, the help desk sees an unusual increase in password resets and an unconfirmed data-breach claim appears on social media. The technical team does not yet know the cause.

Within 30 minutes, decide:

• who activates the crisis team and approves publication;
• which facts are confirmed and which remain unknown;
• what employees and customers should do;
• where the first statement appears if email is untrusted;
• when the next update will be issued;
• who monitors false messages impersonating the organisation.

This is a Breachroad scenario, not an incident described by CERT Polska. Its purpose is to reveal missing phone numbers, authority and channels before a real event forces decisions under pressure.

Facts about the new publication and its central guidance come from CERT Polska. The proposed first-statement structure, approval record and exercise scenario are Breachroad recommendations. Connect them to an incident response plan and test them in an incident-response tabletop exercise.