You’ve just received a notification—a major network issue has occurred. Hoping it’s a false positive, you complete an initial triage. Dang it! It’s the real thing.

If you’re like me, your mind likely turns to one thing: fixing the issue as fast as you can.

But hold on! Before you turn completely to fixing it, there’s another important aspect to any incident that you can’t forget, and that’s incident communication. Any time there’s an incident, communication is critical for both internal and external stakeholders.

If your organization already has a major incident management process well defined, you’ll have some basic next steps to follow. But if you’re just in the process of implementing an incident management process, or find yourself in the midst of an incident without a process defined, let’s take a look at some of the things you should be doing.

Everyone should have the ability to flag an incident

Incidents are very unpredictable. There are a variety of causes for an incident, and an endless number of implications. It’s important for your incident communication process to have a way for incidents to be reported by anyone in the organization.

Opening up the reporting pipeline is often facilitated by having dedicated incident management contacts within each department. Ensure everyone knows who their primary contact is. Make sure you have a secondary contact identified as well, in case the primary contact isn’t available. We’ll talk a bit more about this later.

Communicate early

In the early stages of an incident, it’s critical that everyone who needs to be aware of the issue is aware of it. I’ve often seen the reporter of an incident wait until they know the impact of an incident before reporting it. This leads to a delay in communicating and can possibly put the business behind the eight ball on responding. I’ll stress this:

You don’t need to know the full impact of an incident to begin the communication process.

While especially true at the beginning of any incident, the purpose of the communication is not to shame or blame. If you’ve identified the incident, you’ll need help to manage and resolve it. Report the incident early.

Define your communication channels

Here at Auvik, we segment incident communication into two main categories: functional communication and status communication.

Functional communication is the communication between teams working to resolve the incident. These essential communications are typically on the critical path to resolving an issue.

You’ll want to define a dedicated space for this communication, such as a Slack or Microsoft Teams chat, a meeting room, or a voice conference bridge. While it may be tempting to have everyone working on the incident involved in the communication, it’s best to keep the functional communication between primary contacts to keep the people that need to resolve the issue working on that resolution. Any communication between others working to resolve the issue should funnel through the primary contact.

Status communication is the communication outside of the incident team. This could be communication to end users, to leadership, or to external clients. It typically includes information on what’s happening and when the issue will be resolved. This communication can occur in multiple ways, and will depend on the audience, but it could include an internal status page, internal or external emails, and public websites or press releases.

Designate a primary contact for status communication

While the functional communication will be between multiple internal departmental primary contacts, it’s important to limit status communication to one spokesperson. This point person becomes responsible for summarizing and distributing information to the right parties, both internal and external. For that reason, the spokesperson is typically a senior individual driving the messaging with marketing and legal input.

Communicate status often

We’ve all been there at least once—in the dark while it seems like the world around you is burning down. The reality is the world’s not really burning down, but no one likes feeling like they don’t know what’s going on. It’s important that your status communication occurs often.

You may want to ensure every update has really impactful information or tangible results, but during an incident, the frequency is more important than the content. Even if you don’t feel you’ve made much progress, your stakeholders will appreciate being in the loop.

Be as clear and transparent as you can with your status communication. If you have an estimated time to resolution, provide it—but don’t make one up if there isn’t one. No one wants to be told it’ll be fixed soon and then have it take much longer.

Also important is not to speculate in your updates. Provide facts, not conjecture. And keep in mind that “transparent” doesn’t mean you have to share everything. It simply means sharing enough for your users to know you’re working to resolve the issue, and with the highest urgency. Avoid communicating any information that may have legal repercussions.

The communication continues post incident

As the incident wraps up and you have a resolution in place, ensure you keep communicating. Communicate status when the issue is resolved, and when appropriate, communicate out a root cause analysis.

While a detailed root cause analysis may be for limited distribution, share what’s been approved by your legal and marketing teams. It will help build trust and confidence with your stakeholders, demonstrating you have their best interests in mind and will work to prevent similar issues in the future.

Your reality will continuously change throughout the incident as new information becomes available, as new parties get involved, and as parts of the incident are resolved. Keep in mind that even some of the most mature incident communication plans will have “speed bumps.” If you find you’re struggling to perfect your communication plan during an incident, don’t worry—you’re not alone.

A key part of the incident retrospective is to see how well your communication plan worked and identify improvements to the plan. As you continue to iterate, you’ll get better each time.

Steve Petryschuk

About Steve Petryschuk

As Auvik’s Product Strategy Director, Steve works with prospects, clients, and the IT community at large to identify, research, and analyze complex IT Operations challenges, helping guide the Auvik roadmap to better service the IT community. Steve holds a Bachelor of Engineering and Management and is a registered Professional Engineer in Ontario with IT, networking, and IT security experience spanning product management, devops, systems admin, solutions engineer, and technical trainer roles.


Leave a comment

Got something to say? Name and email are required, but don't worry, we won't publish your email address.

*