Making crisis communications a core security competency

ISJ hears exclusively from Boris Dzingarov, CEO of ESBO Ltd about the importance of crisis communications during a public breach.

Most security teams know what happened during a breach within hours and the public finds out within days, and that information tends to not be released by the company.

A ransomware group posts the victim’s name on its leak site and the data turns up in Have I Been Pwned.

An employee mentions “a rough week” on LinkedIn and someone in the comments joins the dots.

By the time the official statement appears, the story already has a shape, and it is rarely the shape the company would have chosen.

The gap between the incident being understood internally and the incident being explained externally is where most of the lasting damage happens rather than the intrusion itself.

I am the CEO of ESBO Ltd, a digital PR agency that aids companies in earning coverage across multiple media platforms. During my time at ESBO, I have been contacted by companies after a breach that has been made public and the pattern is always the same.

We are sent a statement that was written by lawyers at speed and it covers near to nothing.

Throughout the statement, the attack is described as “sophisticated” when really it started from a phished password.

Due to the little information that the company released, the statement seems like a cover-up and nobody believes it. Every update after this has to climb out of the hole the first one dug.

A better press release on the day will not fix this but crisis communications must sit inside the security function, planned and rehearsed with the same seriousness as containment.

The clocks have changed the job

Communications used to be something you could work out once the technical picture was clear, but regulation removed this luxury.

Under UK and EU GDPR, a personal data breach that puts people at risk has to be reported to the regulator within 72 hours.

NIS2 asks in-scope organisations for an early warning within 24 hours of becoming aware of a significant incident.

In the United States, listed companies must file a Form 8-K within four business days of deciding whether a cyber-incident is material.

Each of those filings is public or becomes public soon after, and each one is a statement about your company that journalists, customers and AI assistants will read.

I have mixed feelings about these deadlines as they force discipline, which is good.

Due to their being limited time, the statements released tend to be the worst statements as they’re written before anyone knows the facts and are worded to limit liability rather than to inform.

The only way to meet a 72-hour clock without saying something you will regret later is to have prepared for this before it has happened.

Decide the decisions before the incident

The most useful document a security team can build with its communications colleagues is a disclosure decision tree.

The disclosure decision tree answers the questions that are otherwise argued out on a bridge call at two in the morning.

It covers:

• Who declares an incident material, and on what evidence? Legal usually owns the word, but they cannot make the call without security telling them what the logs show
• Which incident types go to regulators only, which get a customer notice, and which get a public statement? A credential-stuffing wave against customer accounts is a different animal from a ransomware group holding your HR data
• Who can approve a statement out of hours, and who is the deputy when that person is on a plane?
• What is the trigger for going public before you are ready, because someone else is about to tell the story for you?

None of this is complicated, but it is just rarely written down, and its absence is only discovered at the moment the tree would have been most useful.

Keep two timelines

Every incident response team keeps a timeline.

It is a technical document that contains initial access, lateral movement, the accounts touched and the indicators of compromise.

I believe that it is exactly what the forensics firm needs but is almost useless to whoever has to write the customer notice.

Alongside it, there should be a record of a second timeline that is written in plain language, maintained from the first hour that includes:

• What we knew
• When we knew it
• What we did about it
• Date-stamped
• No adjectives
• Updated as facts are confirmed rather than suspected

This becomes the spine of every external statement and it protects you from the pattern that does more reputational harm than the breach itself: the revised number.

Two thousand affected accounts can turn into twenty thousand or two hundred thousand, and each revision is a fresh news cycle and a fresh reason to doubt everything else you have said.

If the timeline only records what the evidence supports, your statements will also only claim what the evidence supports.

One voice, cleared in advance

In preparation, companies should name a spokesperson and a deputy before they’re needed.

The company should provide the chosen person with holding statements that were drafted, legally reviewed and approved in advance.

The blanks in those templates should be facts (which systems, what data, what the company has done about it), not adjectives.

Remove “sophisticated”, “we take security seriously” and “out of an abundance of caution” from the templates now.

They have become shorthand for having nothing to say.

Then think about who hears from you first.

Employees will talk, so brief them before the statement goes out and tell them what they can and cannot say.

Customers should hear from you before they hear from a breach notification service.

Finally, companies must consider where the statement lives.

A dated, plainly written page on your own domain, updated as the facts firm up, tends to become the source that search engines and AI assistants pull from when someone asks what happened to your company.

If that page does not exist, a leak site post or a Reddit thread fills the gap, and that version becomes the one that gets repeated.

Measuring security

Security teams already track time to detect a breach.

I suggest that companies should add time to the first accurate public statement.

In order for critical communications to flow smoothly in the case of a real attack, a communications scenario should be embedded into the next tabletop exercise.

This could look like handing the team a fictional leak site post naming the company and giving them ninety minutes to produce something that the CEO would be willing to say aloud.

The first run is usually humbling, but the second is usually fine.

The intrusion is the part you may not be able to prevent, the account of it is the part you can.