Incident communication: who says what while the technical team still has no answers
Reputational damage from an incident begins before the technical answer arrives. The communication plan needs to exist before it is needed.
When a serious technical or information security incident occurs - a service outage, a data breach, a critical system going dark - most companies follow the same script. The technical team goes into fix mode. Everyone else waits for the team to "sort it out." Communication with the outside world and with internal stakeholders stalls.
The reputational damage forms in that pause - the gap between the incident's start and the first clear signal from the company. Who makes decisions in the first 30 minutes of a failure is the operational side; what follows here is the communication side that must run in parallel.
Silence in a crisis reads as concealment. This is unfair, but it is how human perception works.
Why the technical response and the communication response are separate processes
During an incident, the technical team is focused on diagnosis and recovery. That requires concentration, speed, and narrow focus. Asking an engineer to simultaneously write customer-facing messages and answer management questions means disrupting both processes.
The communication response is a separate discipline. It starts before there are technical answers, and it operates at a different level: what we know, what we do not know, what we are doing, when the next update will arrive.
These two processes must run in parallel from the first minutes of an incident. They do not compete - they address different tasks for different audiences.
Four questions that need an answer immediately
Even when there are no technical answers, four communication questions can and should be addressed:
What happened - to the extent known at this moment. "At 14:23 we detected an outage of the primary service" is a concrete fact available immediately.
Who is affected - which systems, which users, which processes. Even approximately, this is better than nothing.
What we are doing right now - the team is working on resolution, these specific people are involved. Not promises - a description of actions.
When the next update will arrive - a specific time, not "as soon as we have information." This is the most important element: it replaces silence with structure.
These four answers can be provided within fifteen to thirty minutes of the incident beginning. Before the cause is understood. Before recovery time is known.
Who speaks - and on whose behalf
During an incident, speed matters, but so does who is the voice of the company. This must be determined in advance, not decided in the middle of a crisis.
For the internal audience - employees, management - communication can be less formal, but no less timely. People need to understand what is happening, not learn about the incident from external sources or from clients.
For clients and partners - an official channel, in the company's name. A status page, a mailing, a direct message - depending on the type of relationship. But the channel must be established in advance.
For regulators - if the incident touches personal data or regulated processes - a separate notification protocol, with its own deadlines and form.
Mixing audiences and channels is a mistake that makes the situation harder to manage.
What to say when the cause is unknown
The most common mistake is to stay silent until the full picture is available. Waiting for complete information before communicating is not caution - it is losing control of the situation.
It is acceptable and correct to say: "We are investigating the cause. Our current working assumption is this. We will communicate when the picture becomes clearer."
What is not acceptable: giving false assurances ("the data is safe") before that has been confirmed, or downplaying the scope of an incident to manage audience reaction.
The first destroys trust immediately. The second destroys it with a delay - but completely.
How to prepare before an incident happens
A communication plan for incidents is not a document for large companies. It is two or three pages that answer the questions: who makes the decision to begin communicating, through which channels, with what first-message templates.
Three things to define in advance:
- Who is responsible for communication during an incident - a specific person, not a job title.
- Which channels are used for which audiences - and who has access to those channels outside business hours.
- What the threshold for external communication is - not every technical failure requires a public statement, but the criteria need to be written down.
An incident is a bad time for organisational decisions. Everything that can be decided in advance should be.