How to build an incident response communication plan

An incident communication plan decides, before anything breaks, who sends updates, to which audiences, through which channels and how often at each severity. It names a communications lead so engineers stay on the fix, gives every update a fixed shape (what’s affected, what’s being done, when the next update comes) and keeps templates ready.

What is an incident communication plan and why every company needs one

No service or team is perfect, which means you’ll inevitably run into incidents. Undoubtedly, your response team will be hard at work to resolve any incident as quickly as possible. However, the perception that impacted users, shareholders, and other teammates have of the incident is just as important as what is actually happening. How you handle an incident can strengthen your relationship with customers and partners and protect your brand reputation. But you can’t improvise communications while managing expectations during and after an incident—you’ll need to have an effective Incident Communication Plan ready.

An Incident Communication Plan is a framework that outlines how and when an organization communicates with different audiences during and after an incident.

An Incident Communication Plan may include:

• Definitions for incident severity levels and their implications on communications.
• A breakdown of the audiences (customers, partners, investors, etc.) that need to be kept in the loop during and after an incident.
• Descriptions of incident response roles and responsibilities for writing and approving messages or addressing impacted accounts.
• A list of communication channels and guidelines on how and when to use each.

However, an Incident Communication Plan is not a list of canned messages or generic copy meant to be sent to customers. In fact, I recommend the SRE teams I coach to avoid those practices. Every incident is different, and your communication should be carefully crafted for each case.

How should teams communicate during a major outage?

Acknowledge within minutes, then update on a fixed cadence even when nothing has changed. Give each audience its own message: technical detail for responders in the incident channel, impact and timeline for leadership and customer-facing teams, and plain status for customers on the status page. A communications lead owns all of it, so the engineers working the fix aren’t interrupted. Rootly runs all three streams from the incident in Slack or Microsoft Teams. The full playbook for major-outage communication covers the audience table and the stakeholder cadence in detail.

In Rootly, all three streams run from the incident in Slack or Microsoft Teams: the status page is updated from the incident channel, reminders flag overdue updates, and Rootly AI drafts each update at the right level of detail for its audience.

Who to update, where and how often

Write this table into your plan before you need it. Each audience gets its own channel, cadence and owner, and the cadence tightens as severity rises. The times below are common starting points; set your own against your severity levels and customer commitments.

Audience	Channel	SEV1 cadence	SEV2 cadence	SEV3 cadence	Owner
Responders	Incident channel in Slack or Microsoft Teams, plus the incident bridge	Continuous, with a commander summary every 30 minutes	Continuous, with a summary every 60 minutes	As work happens	Incident commander
Executives	Stakeholder channel or email summary	Within 15 minutes of declaring, then every 30 minutes	Within 30 minutes, then every 60 minutes	Summary at resolution	Communications lead
Support	Support team channel, with approved wording to reuse with customers	Before or with the first status page update, then with every update	With every status page update	Only if customers can see the impact	Communications lead, with a customer support liaison
Customers	Status page and subscriber notifications; direct email for named accounts	First update within 15 to 30 minutes, then every 30 minutes	Every 60 minutes	Only if customers can see the impact	Communications lead
Regulators	Formal notice through legal or compliance	Within the deadline your regulation sets, such as 72 hours for a GDPR personal data breach	Only if the incident meets a reporting threshold	Usually none	Legal or compliance lead, with facts from the communications lead

Every audience also gets a closing message at resolution. For customers and executives, follow it with the retrospective summary once it is ready.

How to build your incident response communication plan

Identify key stakeholders

An effective Incident Response Communication Plan ensures everyone who needs to know about an incident does so. Thus, you need to identify who those people are and when and how to contact them during an incident. You may also outline the type of details that are relevant to each stakeholder.

Examples of key stakeholders may include:

• Customers
• External partners
• Executives
• Internal teams
• Media partners
• Regulatory bodies

Define incident severity levels and act accordingly

Depending on the incident’s scope and impact, you will have different communication needs. For example, minor incidents may not need to be communicated to unaffected customers, while for security incidents, you may need to coordinate with law enforcement agencies.

While some communication elements may seem “obvious” as you read this, things can get quite confusing when you’re dealing with an active incident. That’s why outlining severity levels and their potential communication implications is a key part of your Incident Response Communication Plan.

Establish internal communication protocols

You’ve established who needs to be contacted and under which circumstances by defining key stakeholders and incident severity tiers. Now, you need to pin down how you’ll get in contact with each of them and set expectations for communication cadence.

For example, for internal communication, I recommend you keep incident collaboration within your usual platforms, such as Slack or Microsoft Teams. That may mean having a dedicated incident channel where responders actively collaborate, while higher-level updates can be shared by a Slack bot like Rootly’s in a different channel for org-wide visibility.

Establish guidelines on what information should remain confidential and what can be shared externally, as well as how to manage those communications.

Develop external communication strategies

While your response team needs to remain nimble and not overly bound by protocol to collaborate and mitigate an incident, communication with third parties should be very intentional. You want to avoid triggering unnecessary panic from your customers and ensure there are no misunderstandings from your partners or investors.

External communications are best handled by a teammate with a strong grasp of technology, a deep understanding of your business, and, ideally, media training. It is common to have individuals responsible for each external stakeholder, such as Investor Relations, Customer Relations, or Press Relations.

Collaborate with each of them to develop an external communications strategy that the response team can rely on during an incident. This ensures they will feel comfortable reaching out to the right person at the right time.

Incident update templates

Templates give every update the same shape so readers know where to look. Copy these into your plan, then rewrite the specifics for each incident: a template that still reads like a template is the canned message readers ignore. Replace everything in square brackets.

1. Investigating

Investigating: [Service or feature] [is unavailable / is slow / is returning errors]

We are investigating reports that [what customers see] for [which customers, regions or plans].
[Workaround, if one exists: "In the meantime, you can ..."]
We will post the next update by [time and time zone].

2. Identified

Identified: [Service or feature] [impact]

We have found the cause of [what customers see]: [one plain-language sentence, no internal system names].
We are [rolling back / deploying a fix / failing over] now.
[Customers affected] may continue to see [symptom] until the fix is in place.
Next update by [time and time zone].

3. Monitoring

Monitoring: [Service or feature] recovering

A fix is in place and [service] is [working normally again / recovering].
We are watching [error rates / queue backlog / sync status] to confirm the fix holds.
[Anything customers need to do: "If you still see ..., try ..."]
Next update by [time and time zone], or sooner if anything changes.

4. Resolved

Resolved: [Service or feature] [impact]

This incident is resolved. Between [start time] and [end time, time zone], [what customers experienced] for [who was affected].
The cause was [plain-language cause]. [Data was not lost / Any delayed items have been processed.]
We are reviewing this incident and will [publish a summary / share follow-up actions] by [date].
If you are still seeing problems, contact [support channel].

For executives, keep the same four stages and swap the customer detail for business impact: affected accounts, revenue or contractual exposure, and what support should tell customers.

Incident communication best practices

Prioritize clarity and transparency

Transparency does not necessarily mean sharing specific technical details of an incident. While technical details may clarify the situation for a few people, it’s unlikely to help others—even those within your organization—understand what to expect.

Instead, I recommend writing messages that make sense to your audience. For example, when writing a status page update, provide details on what users can expect from the degraded services. When explaining the situation to executives, focus on explaining the impacted accounts.

Keep in mind that not all your audiences are technical but still require updates that help them understand what’s going on and how you’re mitigating the situation. Try to translate technical issues into simplified terminology that your audience can grasp intuitively.

Ensure timeliness in communication

Too frequent communications can become noise and take away too much of your time. However, not enough communication can be misunderstood by stakeholders as a lack of progress in mitigating the incident.

Your Incident Response Communication Plan can include details on how frequently each audience and channel should be updated. This can help alleviate tensions with stakeholders by setting clear expectations.

Tools like Rootly AI can also help you shorten the time needed to write updates for each audience, as they can generate summaries for specific stakeholders based on the incident’s context. Use those summaries as a starting point to save up to 51% of the time writing them, as Google has done.

Sound like a human

You can skip the “Dearest customer, we sincerely regret any inconvenience caused” in most cases. Nobody appreciates corporate jargon or generic phrases being thrown at them while they’re in distress.

Include a section on style and tone in your Incident Response Communication Plan so everyone is aligned on how to provide a cohesive voice for your company. Emphasize making your messaging sound empathetic, showing you’re human and care about those affected.

Own it

You’ve seen the typical “an error was made” in incident communication messages. For your audience, this language is unhelpful and can come across as if you’re deflecting responsibility for what is happening.

Acknowledge the issue directly and provide details that reassure your audience you’re doing everything possible to resolve the incident. Be specific if you need action from your reader—for example, if you need your customers to reconnect their authentication service.

Keep customers informed without pulling engineers off the fix

Engineers lose time on the fix when every status update needs their input. Two changes stop that: one person owns communication, and the tooling gives that person a draft, a reminder and a one-step way to publish.

1. Assign a communications lead on every customer-facing incident. The communications lead writes and sends every update outside the incident channel. They read the incident channel and timeline for facts and ask the incident commander only when the timeline doesn’t answer the question. On large incidents, a customer support liaison handles support and account teams.
2. Draft from the incident record. Each update starts from what is already in the timeline, the affected services and the current status, so nobody retypes it.
3. Publish from where the incident runs. A status page that needs a separate login and editor falls behind. Posting from the incident channel keeps it current. The guide to better incident status pages covers what the page itself should show.
4. Get prompted when an update is due. A reminder at the cadence in your table catches the gap before customers do.
5. Keep a person on the publish button. Automate the drafting and the reminders. A human confirms what customers read.

How teams do this in Rootly

Rootly runs these steps from the incident in Slack or Microsoft Teams:

• Communications Lead role. Incident roles are customizable, and workflows can assign them automatically by severity, service, incident type or on-call schedule. Roles can carry predefined tasks that become action items on every incident.
• Status page updates from the incident channel. Run /rootly statuspage in the incident channel, or ask @Rootly to post an update. @Rootly fills in the pages, status and affected components, and nothing is posted until someone confirms. One update can go to several status pages at once, and subscribers are notified by default. See publishing incidents.
• Stakeholder communications. Communications in Rootly send email, SMS and Slack messages from templates with stages, such as Investigating, Monitoring and Resolved, with separate text per channel. Liquid variables fill in incident details like severity at send time. Recipient groups set which stakeholders receive a message based on severity, service, team or incident type, and a draft can be shared to a Slack channel for review before it goes out.
• Reminders. Workflows can post periodic reminders to keep status pages and stakeholders updated.
• Atlassian Statuspage. Teams that keep their existing Statuspage can connect it through the Statuspage.io integration.

How Rootly can help you manage incident communication

Rootly is an on-call and incident management solution that helps you orchestrate communication during and after an incident. You can set up automated workflows to notify relevant stakeholders when certain conditions are met, or generate AI-powered summaries based on the incident context.

Frequently asked questions

What is an incident communication plan?

A predefined plan that sets communication roles, audiences, channels, message guidelines, and update cadence so teams can share accurate information under pressure.

Who owns communication during an incident?

Usually a dedicated communications lead who turns technical status into useful updates for responders, leadership, customers, and other stakeholders while the technical team focuses on recovery.

How often should incident updates be sent?

Cadence should increase with severity and customer impact. Every update should say what is known, what the team is doing, and when readers can expect the next update.

How should teams communicate during a major outage?

Acknowledge within minutes, update on a fixed cadence, and give each audience its own message: technical detail for responders, impact and timeline for leadership, and plain status for customers on the status page. Rootly runs all three from the incident in Slack or Microsoft Teams, with Rootly AI drafting each update.

How can we keep customers informed without distracting engineers during an outage?

Give status page and stakeholder updates to a communications lead and draft them from the incident timeline. Rootly AI drafts customer-facing updates from the timeline, so the communications lead edits a draft instead of interrupting responders.

What should an incident status update include?

What is affected and for whom, what the team is doing now, any workaround, and the time of the next update. Leave out the root cause until it is confirmed, and give a time for the next update instead of a resolution estimate.

Do regulators need to be told about incidents?

Only when the incident meets a reporting threshold in your jurisdiction or industry. A personal data breach under GDPR, for example, goes to the supervisory authority within 72 hours of the company becoming aware of it. Legal or compliance owns that notice, using facts from the communications lead.

Should status page updates be automated?

Automate the prompts and the drafting, and keep a person on the publish button. In Rootly, workflows post reminders when an update is due, and @Rootly in Slack prepares a status page update from the incident that the communications lead confirms before it goes live.

How can a SaaS company improve incident communication during outages?

Acknowledge the problem publicly within minutes, make the status page the single source of truth, and update it on a fixed cadence set by severity. Keep internal coordination in the incident channel and customer messaging with a communications lead, and use pre-approved templates so the first update doesn't wait on wording. In Rootly, workflows post reminders when an update is due, and @Rootly in Slack prepares the status page update from the incident for the communications lead to confirm before it goes live.