Introduction

When a system incident occurs, all kinds of reports and updates start flying around. “We are currently investigating the incident.” “The cause has not yet been identified.” “Recovery work has begun.” “We are checking the scope of impact.”

These updates reach stakeholders through email, chat, phone calls, and meetings. And yet, despite all this reporting, have you ever been told, “So what exactly is going on?”

Incident response is rarely handled entirely by the IT department or the SIer (the external system integrator that builds and operates the system). Business units, service owners, executives, sales, and customer support all get involved. Different roles mean different information needs.

When an engineer explains that “the database has reached its connection limit,” what the business unit really wants to know is: “So can customers use the service?” “When will it be back?” “Is there a workaround?” Executives, on the other hand, may be asking: “How big is the business impact?” “Is this serious?” “Could it get worse?” “Is there a decision management needs to make?”

So is incident communication simply a matter of avoiding jargon and reporting at a reasonable frequency? That alone is probably not enough.

What matters is not transmitting information, but making sure the recipient understands what they need and can turn it into decisions and actions.

To achieve that, rather than working hard to report once an incident has started, organizations need to design communication itself during normal operations.

Why “we are reporting, but it isn’t getting through”

During incident response, technical information piles up quickly: “API responses are slow.” “CPU usage is rising.” “The number of DB connections has hit its limit.” “Batch jobs are timing out.” “There is an anomaly on the network path.”

This information is essential for engineers. But passing it along as-is to other stakeholders does not mean they will understand the situation.

Imagine an incident on an e-commerce site, where the engineer reports, “Timeouts on the payment API are increasing.” For the technical team, this is highly significant.

The business unit, however, will want to ask: “So can customers buy products?” “Are orders going through?” “Is revenue being affected?”

Neither explanation is more correct than the other. The two sides simply need information at a different layer and level of detail. In incident response, conveying correct information is not enough. The information has to be translated into something meaningful for the person receiving it.

Different stakeholders want to know different things

In designing incident response operations, communication design and information design are both essential.

Communication design means deciding in advance who to contact, through which channels, how escalation works, and who makes decisions. Information design goes further: what information stakeholders need, who collects it and how, and who makes which decisions based on it.

The key point here is not to treat “stakeholders” as a single group. When an incident occurs, what the system maintenance engineer wants to know, what the IT service manager wants to know, and what the business unit wants to know are not the same.

For maintenance engineers, information needed to identify the cause and restore service matters most. For IT service managers, it is the scope of impact, urgency, response status, and next actions. For business units, it is the impact on customers and operations, workarounds, and expected recovery. For executives, it may be business impact, risk, and whether a decision is required.

In other words, even when reporting on the same incident, there is no need to send everyone the same information at the same level of detail. In fact, continuously sending the same information to everyone can undermine the very purpose of communication described earlier: being understood and enabling action.

“Avoid jargon” is not enough

You may have been told by a manager or senior colleague that incident reports should avoid technical terms and be easy to understand. That is sound advice. But simply replacing technical terms with everyday words is not sufficient.

For example, rewriting “A database connection error is occurring” as “There is a problem connecting to the database” still falls short as communication if the business unit cannot find what it actually needs to know.

In this case, you need to convert the technical event into information the recipient can use to make decisions, such as: “Some order processing is currently not completing. We are investigating the cause, but order intake continues to be affected. We are working with the business unit to confirm workarounds.”

So what communication design should focus on is not “avoiding difficult words.” It is thinking about what the recipient will use the information for.

Communicate impact before cause

When an incident occurs, engineers investigate the cause. Once they find it, they naturally want to report it.

Say you discover that “a memory leak in the application server was the cause.” That is important information. But for a business unit in the middle of an incident, it is not enough on its own.

What they actually need is: “What is happening as a result?” “Who is affected?” “How badly?” “When is it likely to be restored?” “What should users do?”

In the incident response process, the key steps are establishing the facts of what happened, investigating cause and impact, and deciding on actions based on the collected information and decision criteria. This also means that collecting information and making decisions based on it are two separate things.

Likewise, the overall incident response becomes easier to design if the purpose of communication is framed not as “we gathered information, so we report it,” but as “enabling the right people to make the decisions they need to make.”

There is no “right” reporting frequency

Another common issue in incident response is reporting frequency. Teams often set rules like “report every 30 minutes” or “hold a status update every hour.”

This can work, but deciding on frequency alone is not enough. If a major incident is underway and recipients are told “the next update will be in one hour,” they will grow anxious.

Conversely, if nothing has really changed and the same update arrives every five minutes, both the responders and the readers become exhausted.

What matters is reporting not only by time, but also in response to changes in the situation.

For example, when the scope of impact expands, the severity changes, the recovery estimate changes, a new fact comes to light, or a decision becomes necessary, share it immediately without waiting for the scheduled update. When nothing significant has changed, provide status updates at regular intervals.

Combining time-based reporting with event-based reporting in this way leads to a design that fits real-world operations better.

Decide “who, what, at what level of detail, and when”

To summarize, communication design requires thinking through at least four things.

First, who you are communicating with. System engineers, IT service managers, business units, or executives. Consider what each of them cares about.

Second, what you are communicating. Organize the information the recipient needs, whether technical details, scope of impact, recovery status, risks, or decisions to be made.

Third, at what level of detail. The same information requires different depth for engineers than for executives.

Fourth, when you communicate. Decide whether to report at regular intervals, when the situation changes, or when a decision is needed.

With these organized in advance, responders do not have to start from scratch every time an incident occurs.

Communication design builds trust

At this point, you might think communication design is simply about making incident response more efficient. But if you think about it a little more deeply, communication design also leads to trust.

Consider a case where, after an incident occurs, the only update that keeps arriving is “The cause is under investigation.” Recipients gradually grow uneasy. They start wondering: “Is this really being handled?” “Do they understand what is going on?” “When will it be fixed?”

Now suppose they are told: “The impacts we have confirmed so far are A and B. The cause is still under investigation, but we are looking into C as a possibility. At this point, we have not seen the impact spread further. Next, we will check D and update the estimated recovery time by around 3 p.m.” Even though the cause is still unknown, recipients can understand the situation.

Trust does not come from having every answer. It can also come from sharing what is known, what is not yet known, and what happens next, at the right time.

In incident response, the cause is sometimes not immediately clear. Recovery time sometimes cannot be promised. That is exactly why “how to communicate what you don’t yet know” matters so much.

Communication can be designed before an incident happens

Some organizations may think: “Incident reporting can only be figured out on the spot. Every situation is different, so there are limits to what we can prepare.”

But during an incident, information is already scarce. The cause is unknown. The scope of impact is unknown. The recovery estimate is unknown. Working out who to tell what, from scratch, under those conditions is not easy.

That is why designing it in advance, during normal operations, is so valuable. For example, organize ahead of time: “If this service goes down, who do we contact first?” “If severity increases, who else do we notify?” “What information do we give the business unit?” “At what level of detail do we report to executives?” “In what situations do we contact people without waiting for the scheduled update?”

In other words, communication is not something to leave to an individual’s communication skills. To a meaningful extent, it can be designed as a system.

From “telling” to “being understood”

In incident response, attention naturally goes to solving the technical problem. But the bigger the incident, the more problems arise that technology alone cannot solve. Questions like these: Do we keep the service running? Do we suspend some features? Do we notify customers? Do we ask the business unit to switch to a workaround? Do we escalate to executives?

Many stakeholders are involved in these decisions. That is why communication in incident response is more than just “reporting and updating.” It is the work of connecting information to the people who need it, so they can understand the situation and take the decisions and actions required.

To do this, you have to understand what the receiving organization cares about. System engineers need technical information, while business units care about the impact on operations and customers. Executives will ask about business impact.

The same incident calls for different angles depending on who is looking. Think about “who, what, at what level of detail, and when.” Then keep improving that design little by little, reflecting on actual incidents. This may well be the essence of communication design in incident response.

The next time an incident occurs, instead of first asking yourself “What report should I write?”, try asking “What does the person receiving this report want to know?” That small shift in perspective alone will change what you write. And when reports change, so do the decisions stakeholders make.

In incident response, no one has to solve every problem alone. If you can connect the right information to the right people, the whole organization can respond together.

Communication is not an “add-on task” of incident response. It is a vital mechanism in its own right for responding to incidents as an organization.

So before the next incident happens, why not take a moment to review how your team reports and communicates? “Who, what, at what level of detail, and when.” Simply starting with this question can gradually change how you respond to incidents.