Incident Communication Templates for IT Teams and MSPs

Good incident communication needs four things: a template for each stage of the incident, a named person who sends it, a fixed update cadence, and one place where customers look for status. This guide gives you templates for each stage, plus the plan around them. It is written for MSPs and multi-site IT teams who have to tell clients and executives what is happening while engineers are still fixing it.

TL;DR

Use one template per stage: Investigating, Identified, Monitoring, Resolved. Fill in only the placeholders.
Promise the next update time, not a fix time. You control the first. You rarely control the second.
Name the incident lead, the communications lead and a single spokesperson before anything breaks.
Say what you know and what you don't know, in the reader's terms, with a clear action or "no action needed."
Publish to one source of truth and keep every other channel consistent with it.

What an incident communication template should do
The four stages every update follows
Templates you can copy
Write the plan before you need the templates
Wording rules that hold up under pressure
A worked example: branch-office WAN outage
Our perspective: communication starts with detection
Where Netverge fits
Test the plan before an outage does
Checklist before you publish
FAQ
Sources

What an incident communication template should do

A template is not a script. It is a pre-approved frame that removes the slowest part of an outage: deciding how to phrase things while under pressure. The boilerplate stays fixed. The incident-specific facts, such as start time, affected services and incident ID, sit in clear placeholders. PagerDuty's guidance on templatizing communications makes the same split, and it also suggests pointing responders to the internal status page, call bridge and incident chat channel so that the recipient gets a short message while responders know where to collaborate.

A useful template does five jobs:

States the impact in the reader's words ("customers at the Dallas and Phoenix sites cannot reach the VPN"), not the cause in yours.
Gives a time for the next update.
Says what the reader should do, including "nothing."
Names the sender, so there is one voice.
Links to where the latest status lives.

Joint guidance from CISA and international partners, summarized in Communicating Under Pressure: Best Practices for Service Providers, recommends that service providers write an outage communications plan that defines triggers, escalation paths and procedures, and includes templates. The templates below fit inside that kind of plan.

The four stages every update follows

Most incidents move through the same four messages. Writing one template per stage keeps updates short and predictable.

Stage	What the message confirms	What it must include
Investigating	The symptom, in user terms	Who is affected, next update time
Identified	What is broken and who it touches	Workaround if one exists, next update time
Monitoring	A fix is deployed, verification is running	What you are watching, when you will confirm
Resolved	Service is restored	Duration, what happens next (postmortem)

The "Monitoring" stage matters more than teams expect. When a fix is deployed but not confirmed, say so. Declaring "resolved" and then reopening the incident costs more trust than ten minutes of honest caution. The CISA-led guidance describes this same practice: verify performance before you declare an incident closed.

Templates you can copy

Bracketed items are placeholders. Replace them, delete anything that does not apply, and keep each message short enough to read on a phone.

Investigating

Subject: [Service/Site] issue under investigation

We are investigating reports that [affected users or sites] cannot [symptom, in plain terms] since [start time, time zone].

What we know: [one or two confirmed facts]. What we don't know yet: [cause, scope, or duration, if unconfirmed]. What you need to do: [specific action, or "No action is needed at this time."]

Our next update will be at [time, time zone], or sooner if anything changes. Status page: [link] | Incident ID: [ID]

Note what is missing: a root cause and an ETA. Many teams believe they must explain the cause immediately. At this stage you only need to confirm the symptom and commit to the next update. An early ETA that proves wrong turns a technical problem into a trust problem, as this incident communication guide points out.

Identified

Subject: [Service/Site] issue identified

We have identified the cause of the [symptom]: [one-sentence cause in plain language, e.g., "a failed uplink at the [site] edge"].

Impact: [who is affected and how]. Workaround: [steps, or "None available."] Current action: [what the team is doing now].

Next update by [time, time zone].

Keep the cause at the level the reader needs. A client's operations manager needs to know the Phoenix site is on its backup circuit, not the BGP details.

Monitoring

Subject: [Service/Site] fix deployed, monitoring

We deployed a fix at [time]. [Service] is responding normally as of [time]. We are monitoring [metrics or checks] to confirm stability.

If you still see [symptom], contact [support channel] and reference [incident ID].

We will confirm resolution by [time, time zone].

Resolved

Subject: [Service/Site] issue resolved

The issue affecting [users or sites] is resolved as of [time, time zone]. The total duration was [duration].

Summary: [two sentences: what happened, what fixed it]. Next step: we will publish a post-incident review by [date]. Questions: [contact].

Scheduled maintenance notice

Subject: Planned maintenance on [date] for [service/site]

We will perform maintenance on [system] on [date] from [start] to [end], [time zone].

Expected impact: [what users will notice, or "none expected"]. Rollback plan: [one line]. We will post a confirmation when the work is complete: [status link].

Executive summary

Subject: [Severity] incident, [service], executive update [number]

Bottom line: [one sentence on business impact]. Affected: [customers, sites, revenue-relevant systems]. Status: [Investigating / Identified / Monitoring / Resolved]. Decisions needed: [none, or the specific decision]. Next update: [time]. Owner: [name].

"Bottom line up front" is the structure recommended in the Australian Cyber Security Centre's publication of the joint guidance, which also warns against vague phrases like "service degradation." Say which systems are affected and what users cannot do.

Security incident holding statement

We are aware of a security incident affecting [system]. We are investigating with [internal team/external specialists]. At this time, [confirmed facts only].

We recommend that you [specific action, e.g., reset credentials for X], or no action is required at this time.

We will provide our next update by [time]. Contact: [designated channel].

Security incidents change the balance on transparency. For non-malicious outages, openness should be the default. For active cyber incidents, the CISA-led guidance cautions that too much detail can compromise an investigation or containment. Have legal and your security lead approve this template in advance, not during the event.

Write the plan before you need the templates

Templates answer "what do we say." An incident communication plan answers "who says it, how fast, and where." Build these pieces before the first outage.

Roles

The CISA-led guidance recommends defining roles such as an incident lead, a communications lead and a single designated spokesperson, and involving engineering, communications, legal, risk and compliance, and customer support. For a smaller MSP, one person may hold two roles. What matters is that every role has a name and a backup.

Role	Responsibility
Incident lead	Runs the technical response, supplies facts
Communications lead	Drafts and sends updates from templates
Spokesperson	The only voice for press, executives and key clients
Legal/compliance	Checks policy, contractual and regulatory exposure
Support lead	Handles inbound tickets and calls using the same facts

Review without delay

Drafting is quick. Approval is where updates stall. PagerDuty's guide to managing communications is one source for assigning reviewers by what they check: legal for policy compliance, a customer liaison for technical accuracy, and the incident commander for final distribution. Pre-approved templates shorten this loop further, because reviewers only check the filled-in placeholders.

Cadence

An update that arrives on time with little news beats a detailed update that arrives late. A practical starting point many teams use: for the most severe incidents, update every 30 minutes; for moderate ones, every 60 minutes; for minor ones, only when something meaningful changes. One incident communication guide recommends the same pattern. Adjust it to your contracts and SLAs, and write the cadence into your severity definitions. If you are still tuning how severity is assigned, our piece on prioritizing network incidents with seven fields covers that decision.

Incident update intervals by severity

Channels and a single source of truth

Choose one authoritative place, usually a status page, and make every other message point to it. The CISA-led guidance notes this keeps messaging consistent and shields engineers from ad-hoc status requests from individual stakeholders. Add a fallback channel too. The UK's NCSC advises that communication plans include alternative channels, because your usual systems may be unavailable during the incident itself. If your ticketing and email depend on the network that is down, you need a path that doesn't.

Wording rules that hold up under pressure

Lead with impact. "Users at three branch offices cannot access the ERP" beats "We are experiencing degraded performance."
Separate known from unknown. Silence reads as either incompetence or concealment. Stating what is not yet known does neither.
Give an action. Tell people what to do, or tell them no action is required.
Skip marketing language. Avoid heavy reassurance or brand copy. The CISA-led guidance advises against filling gaps with it.
Keep the same facts everywhere. Status page, email, support scripts and social posts must agree, including anything reported to regulators.
Use user terms. "Cannot sign in" works for a client. "Authentication timeout on the RADIUS server" belongs in the responder channel.

A worked example: branch-office WAN outage

Suppose an MSP loses connectivity to a client's three retail sites at 9:12 a.m. Eastern.

9:25 a.m., Investigating. "We are investigating a connectivity loss affecting the Columbus, Dayton and Toledo stores since 9:12 a.m. ET. Card payments may be affected. We don't yet know the cause. Please use cellular backup for payments if available. Next update by 9:55 a.m. ET."

9:55 a.m., Identified. "A carrier circuit failure is affecting all three stores. Stores are on backup links with reduced speed. The carrier has an open ticket. Next update by 10:25 a.m. ET."

10:40 a.m., Monitoring. "Primary circuits restored at 10:32 a.m. We are monitoring link stability and payment traffic. We will confirm resolution by 11:30 a.m. ET."

11:30 a.m., Resolved. "Resolved as of 11:30 a.m. ET. Total duration: 2 hours 18 minutes. A post-incident review will be shared by Friday."

None of the messages promised a fix time. Each one promised the next update, and each one was kept. That is the habit the templates build.

A worked example: branch-office WAN outage — overview diagram

Our perspective: communication starts with detection

Most guides treat communication as a writing problem. In our work with MSPs and multi-site IT teams, it is just as much a data problem. You can't fill in "affected sites" and "start time" if you first have to hunt through five tools to find them.

Three things slow the first message down:

Alert noise. If twenty alerts fire for one failed uplink, someone has to work out whether it is one incident or twenty. Correlating alerts into a single incident gives the communications lead one record to write from. See our walkthrough of six-stage incident correlation.
Scattered documentation. Circuit IDs, site contacts and escalation paths often live in separate documents. When they sit next to the incident, the placeholders fill themselves in.
Unclear impact. Teams often confuse an alert with an incident. We cover how to validate impact before declaring one in Alert vs Incident.

We build Netverge to put monitoring, ticketing, documentation and AI-assisted triage in one place for exactly this reason. The faster your team knows what is affected, the sooner the first honest message goes out. Our broader network incident response guide shows how communication fits with detection, triage and recovery.

One firm opinion: automate the facts, not the voice. Pull impact, timing and affected sites from your monitoring data into the draft, but keep a human accountable for what is sent.

— Jim

Where Netverge fits

If your updates are slow because the facts are scattered, Netverge can help. The platform combines real-time infrastructure monitoring, anomaly detection, ticketing with AI triage, network documentation and multi-tenant management. Vergepoints add on-site visibility at client locations, so you can see a site's state without waiting for the client to call.

Published pricing starts with the Starter Package at $299 per month. Hardware Vergepoints are $49 per month per device and Software Vergepoints are $29 per month per Vergepoint, with add-ons listed on the pricing guide. You can estimate your own monthly cost with the pricing calculator. MSPs can see how the platform is set up for multi-client work on our MSP page. Ready to try it? Start a free trial or request a demo from netverge.com.

Test the plan before an outage does

A plan nobody has practiced is a draft. The NCSC recommends regular tabletop exercises to find gaps, train spokespeople and test alternative channels. A simple 60-minute exercise works:

Pick a realistic scenario, such as a core switch failure at a client's headquarters.
Give the communications lead only the information a real responder would have at minute 10.
Have them send the Investigating message from the template, in full, to a test audience.
Add a complication: a second site fails, the primary email is down, or a client executive calls the CEO.
Record where the template was missing a placeholder or the approval path stalled. Fix both.

Repeat after any change in staff, tooling or contracts. Review your templates after every real incident too. Your own past messages that landed well are the best material for the next revision, which is also PagerDuty's advice on building templates from effective past communications.

Checklist before you publish

Does the first sentence state who is affected and what they cannot do?
Is there a next-update time, in a stated time zone?
Is the ETA claim absent, unless it is confirmed?
Does the message say what the reader should do?
Is the sender named, and is this the approved spokesperson or comms lead?
Does it match the status page word for word on the facts?
For security incidents, has legal or the security lead cleared the detail level?

If you want to reduce how often you need these messages at all, our enterprise playbook on reducing network downtime is the next read.

FAQ

What is the difference between an incident communication plan and a template?

The plan defines who communicates, when, through which channels and with whose approval. The template is the pre-written message used inside that plan. You need both: a template with no owner goes unsent, and a plan with no template slows every update.

How often should we send updates during an incident?

Set the cadence by severity and write it down in advance. A common pattern is every 30 minutes for the most severe incidents and every 60 minutes for moderate ones, with minor incidents updated only on meaningful change. Always state the time of the next update in the current one, and send something even if the news is "no change."

Should we share the root cause in the first message?

No. In the first message, confirm the symptom in user terms, say what is not yet known and commit to an update time. Share the cause once it is confirmed, and give the full explanation in the post-incident review. For active security incidents, hold back detail that could compromise the investigation.

Who should approve incident messages?

Assign reviewers by what they check. Legal covers policy and compliance, a customer liaison or technical lead checks accuracy, and the incident commander approves distribution. Pre-approved templates mean reviewers only check the filled-in details, which keeps the delay short.

Do we need a status page?

You need one authoritative place for current status, and a status page is the most common choice. It keeps messaging consistent and reduces ad-hoc requests to engineers. Keep a backup channel for the case where your primary systems are down.