Communications During an Incident: Internal + Customer Templates

Why incident communication needs a plan before the incident

Communications during an incident should not start with a blank email drafted under pressure. A strong incident response plan defines roles, contacts, escalation paths, and key activities before an event happens. CISA describes an incident response plan as a formally approved document that guides an organization before, during, and after a suspected or confirmed security incident, including roles and crisis contacts.¹ NIST also emphasizes that effective incident response requires planning, resources, coordination, and repeatable handling processes.²

Communication is the part of that plan that keeps people aligned while facts are still developing. The Canadian Centre for Cyber Security recommends a communications plan that defines how, when, and with whom the team communicates, including a central point of contact for employees to report suspected or known incidents.³ The UK National Cyber Security Centre adds that effective communication before, during, and after a cyber incident shapes how an organization is perceived by staff, stakeholders, customers, and the media.⁴

The first decision: is this an outage, a security incident, a privacy breach, or all three?

Many incidents start with one symptom: users cannot log in, email is down, files are encrypted, a vendor reports suspicious activity, or a customer flags a strange message. Communication improves when the incident lead quickly classifies the situation and updates the label as evidence changes.

The classification can change. A Microsoft 365 outage may become an identity incident if a compromised admin account is discovered. A ransomware event may become a privacy breach if personal information was accessed or exfiltrated.

Canada-specific privacy and reporting considerations

Canadian organizations need a clear privacy decision path inside the communications plan. Under PIPEDA, organizations must report a breach of security safeguards to the Office of the Privacy Commissioner of Canada if it is reasonable to believe the breach creates a real risk of significant harm to an individual.^{6, 7} The OPC states that affected individuals must be notified as soon as feasible after the organization determines that a breach involving real risk of significant harm has occurred.⁶

Recordkeeping matters too. Canada’s Breach of Security Safeguards Regulations require organizations to maintain a record of every breach of security safeguards for 24 months after determining that the breach occurred.¹¹ This does not mean every technical issue requires a customer notice. It means your internal process should capture enough detail to support the decision: what happened, what data or systems were involved, how harm was assessed, who approved communications, and what was sent.

The incident communication team

A small organization does not need a large crisis communications department. It does need named people who know who decides, who drafts, who approves, who sends, and who keeps the record.

If your internal IT team is thin or already overloaded, a managed security partner can help provide the escalation depth, 24/7 monitoring, and active response capacity needed to avoid delays. For context on the operating model behind managed detection and response, see what organizations are actually buying when comparing MDR, EDR, and XDR.

The communication cadence: what to send in the first 24 hours

People do not need every forensic detail in the first hour. They need a reliable cadence. The New Zealand NCSC notes that public communications should be clear and calm, set out when and how to communicate with customers and stakeholders, and avoid creating panic.⁵ In practice, your cadence should provide frequent short updates early, then move to longer intervals as the situation stabilizes.

If the incident involves Microsoft 365 availability or identity, pair the communications cadence with a technical service-health workflow. MSP Corp’s Microsoft 365 service health monitoring and response playbook is a useful companion for separating vendor-side outages from tenant-specific incidents.

What every incident message should include

Good incident messages are short, structured, and repeatable. They should make it easy for a busy executive, employee, or customer to answer three questions: does this affect me, what should I do, and when will I hear more?

The approval workflow that prevents mixed messages

During a live incident, the wrong approval process is either too loose or too slow. Too loose means unapproved statements leak into support tickets, sales emails, and social posts. Too slow means silence while customers are already noticing the impact.

Channel planning: do not rely on the system that might be compromised

An incident can take away the very tools you normally use to communicate. If email is compromised, do not use email as the source of truth. If Microsoft 365 authentication is affected, do not rely only on Teams. If the VPN is unstable, do not bury instructions behind the VPN. Build alternate channels into the plan.

For remote access incidents, review whether users should continue using a VPN or move to a more identity-aware access model. MSP Corp’s ZTNA vs VPN migration strategy explains how teams can reduce exposure while preserving access to critical resources.

Templates for communications during an incident

Use these as working drafts. Replace bracketed text, remove anything you cannot confirm, and route customer, privacy, regulator, or insurer language through the approval workflow before sending.

Subject: Incident response activated: [short issue name]

Team,

We have activated incident response for [short description of issue] as of [time and time zone].

Current status:

* Known impact: [what is confirmed]
* Suspected impact: [what is being investigated]
* Systems involved: [systems/services, if safe to share]
* Current action: [containment, investigation, recovery, monitoring]
* Incident commander: [name]
* Technical lead: [name]
* Communications owner: [name]

Please use [approved channel] for all incident-related updates. Do not create separate side channels unless requested by the incident commander.

Do not share details outside the response team unless approved. The next internal update will be sent by [time].

Subject: Executive update: [incident name] at [time]

Here is the current situation as of [time and time zone].

What we know:

* [confirmed fact 1]
* [confirmed fact 2]
* [confirmed fact 3]

What we are still validating:

* [unknown 1]
* [unknown 2]

Business impact:

* Employees: [impact]
* Customers: [impact]
* Operations: [impact]
* Revenue/contractual exposure: [known or under review]

Current response:

* [containment action]
* [forensic or log review action]
* [recovery action]
* [communications action]

Decisions needed:

* [decision 1]
* [decision 2]

Next update: [time].
Owner for questions: [name/contact].

Subject: Action required: [plain-language incident instruction]

We are investigating [plain-language issue]. At this time, [brief confirmed impact].

Please take the following actions now:

1. [Action 1]
2. [Action 2]
3. [Action 3]

Please do not:

* [Do not action 1, such as reboot affected devices]
* [Do not action 2, such as click unexpected password reset messages]
* [Do not action 3, such as contact vendors directly outside the response process]

Report anything unusual to [single reporting channel]. Include your name, device, location, time observed, and a screenshot if safe.

The next update will be sent by [time and time zone].

Use these talking points if your team asks about [incident name]:

* We are aware of the issue and the response team is actively investigating.
* The confirmed impact right now is [impact].
* The team should continue using [approved workaround] and avoid [do-not-do instruction].
* Please direct questions and reports to [channel]. This helps the response team see patterns and avoid duplicate work.
* We will share the next update by [time].
* If a customer asks, use the approved customer language only. Do not speculate about root cause, data impact, timelines, or blame.

Approved response for tickets and calls:

Thanks for contacting us. We are currently investigating [brief issue]. The confirmed impact is [impact]. Our response team is working on [containment/recovery action] and the next update is expected by [time].

For now, please [workaround or user action]. Please do not [unsafe action].

I will add your report to the incident record. Can you confirm:

* Your name and department
* Device or service affected
* Approximate time the issue started
* Any error message or screenshot
* Whether this affects a customer-facing activity

Escalate immediately if the user reports:

* Suspicious login prompts
* Ransom note or encrypted files
* Unauthorized financial request
* Customer data exposure
* Executive, finance, HR, legal, or admin account involvement

Subject: We are investigating [service/issue]

We are currently investigating an issue affecting [service, portal, system, or process]. Customers may experience [plain-language impact].

Our team has activated our incident response process and is working to [investigate, contain, restore, or monitor] the issue.

What you can do now:

* [Customer action or workaround]
* [Support path]
* [Security instruction if relevant]

We will provide the next update by [time and time zone], or sooner if there is a material change.

Thank you for your patience while we work through this.

Status update: [investigating/identified/monitoring/resolved]

Time: [time and time zone]

Current impact:
[Who is affected and what they may experience.]

Current status:
[What is confirmed. Example: We have identified the affected service and are applying a fix. Or: We have contained the issue and are validating restoration.]

Customer action:
[What customers should do or avoid doing.]

Next update:
We will update this page by [time], or sooner if the status changes.

Subject: Notice regarding [incident/service]

We are writing to inform you about an incident involving [system/service]. We identified the issue on [date] and immediately began an investigation.

What happened:
[Plain-language description of confirmed facts.]

Information involved:
[Describe categories of information involved. Do not include unconfirmed data categories.]

What we have done:
[Containment, investigation, password reset, access review, monitoring, third-party support.]

What you can do:
[Steps the recipient can take to reduce potential harm, such as changing passwords, monitoring accounts, watching for phishing, contacting their financial institution, or using dedicated support.]

Who to contact:
If you have questions, please contact [contact method].

We regret the concern this may cause and will continue to provide updates as appropriate.

Subject: Urgent escalation: [incident name/service]

We are responding to an incident involving [service/system] and need escalation support.

Request:

* [Logs needed]
* [Containment action requested]
* [Account/session review requested]
* [Backup/recovery support requested]
* [Confirmation of vendor-side status requested]

Time window:
The relevant time period is [start time] to [end time] in [time zone].

Please provide:

* Named escalation contact
* Ticket number
* Current status
* Estimated response time
* Any actions taken on your side
* Any known customer or tenant impact

Please do not make configuration changes without approval from [technical lead/contact], unless required to stop active harm.

Incident intake summary for review

Organization: [company]
Date/time discovered: [date/time/time zone]
Reported by: [name/role]
Incident commander: [name/contact]
Technical lead: [name/contact]
Legal/privacy lead: [name/contact]

Summary:
[Plain-language incident summary.]

Known systems involved:

* [system 1]
* [system 2]

Known or suspected data involved:

* [data category]
* [unknown or under review]

Containment actions taken:

* [action 1]
* [action 2]

Business impact:

* [operations]
* [customers]
* [employees]
* [revenue/service commitments]

Current communications:

* Internal messages sent: [yes/no/details]
* Customer messages sent: [yes/no/details]
* Regulator messages sent: [yes/no/details]

Immediate questions:

* [question 1]
* [question 2]

Subject: [Service/incident] recovery update

As of [time and time zone], [service/system] has been restored for [audience/scope].

What changed:

* [restoration action]
* [validation step]
* [remaining limitation, if any]

What you should do:

* [user/customer action]
* [how to report lingering issues]

We will continue monitoring [service/system] and will provide another update if there is a material change.

Thank you for your patience.

Subject: Follow-up on [incident/service issue]

We are following up on the [incident/service issue] that affected [service/audience] on [date].

What happened:
[Clear, approved summary.]

Impact:
[Confirmed customer impact and duration.]

What we did:

* [response action]
* [containment action]
* [recovery action]
* [monitoring action]

What we are improving:

* [control improvement]
* [process improvement]
* [monitoring or alerting improvement]
* [training or governance improvement]

What you need to do:
[Action required, or state that no action is required.]

We appreciate your patience and understand the importance of keeping you informed when issues affect your business.

Incident-specific wording examples

The best template depends on the type of incident. Use these examples as starting points and keep language aligned with confirmed facts.

Phishing or compromised mailbox

If phishing is suspected, speed matters because employees and customers may receive malicious messages before the investigation is complete. Tell users exactly what not to click and where to forward suspicious messages. If your organization runs simulations, follow trust-preserving practices so employees report quickly instead of hiding mistakes. MSP Corp’s guide to running phishing simulations without damaging trust can help shape that culture.

Identity or MFA incident

If the incident involves sign-ins, account takeover, or repeated MFA prompts, avoid implying MFA alone is enough. Attackers may still exploit session tokens, legacy authentication, weak conditional access, or social engineering. For prevention planning, see how to add Conditional Access the right way.

Server, application, or network failure

Not every incident is a breach. Some are operational failures that still require disciplined updates. If server availability is the immediate issue, combine the message cadence in this article with a practical server failure incident playbook so teams know who validates backups, who tests dependencies, and who approves restoration.

Ransomware or extortion

Ransomware communication needs extra care. The Canadian Centre for Cyber Security advises organizations to report ransomware incidents to local police, the Canadian Anti-Fraud Centre, and the Cyber Centre.⁹ CISA’s StopRansomware guidance provides a response checklist that moves from detection and analysis through containment, eradication, recovery, and post-incident activity.¹⁰

Business continuity or prolonged outage

When an incident disrupts operations for more than a short period, communications should align with your business continuity plan. ISO 22301 provides a framework for organizations to plan, operate, monitor, maintain, and improve a documented business continuity management system that supports recovery from disruptive incidents.¹² MSP Corp’s business continuity plan template for IT leaders can help connect technical recovery with stakeholder updates.

Customer communication: when to say less, when to say more

Silence creates suspicion, but over-disclosure creates risk. Customer communication should become more detailed as facts become more reliable.

If the event reveals a pattern of recurring outages, slow support, weak security follow-through, or poor provider communication, it may be time to evaluate the relationship. MSP Corp’s transition checklist for switching MSPs safely outlines red flags and planning steps.

What to log for every message

The message log is not administrative busywork. It protects the organization from conflicting recollections and gives leadership a reliable record for customers, insurers, regulators, and the post-incident review.

The same discipline helps root cause analysis after recovery. If recurring incidents keep returning, connect the communication log to ticket history, monitoring signals, and remediation tasks. For operational structure, MSP Corp’s guidance on designing a scalable Tier 1 to Tier 3 support model can help define who owns triage, escalation, resolution, and customer follow-up.

Communications checklist for the incident lead

Use this checklist during the first response meeting and repeat it at every scheduled checkpoint.

Preventing communication breakdowns before the next incident

The best communications plan is the one your team has already rehearsed. NIST’s incident handling guidance emphasizes the need for established capability, coordination, and continuous improvement.² Public Safety Canada’s federal cyber incident response plan also describes cyber incident management in terms of stakeholders, escalation triggers, and response levels, which are useful concepts for private organizations building their own plans.¹³

How MSP Corp helps before, during, and after an incident

Strong incident communication depends on strong incident readiness. MSP Corp helps Canadian organizations reduce response confusion with cybersecurity assessments, Microsoft-focused security hardening, managed detection and response, incident planning, backup and recovery guidance, and ongoing managed IT support.

If your current provider is slow to communicate, slow to resolve tickets, or unclear during security events, use the templates above as a benchmark. A provider should be able to explain who owns the incident, what is known, what is being done, when the next update will arrive, and how the business can reduce risk now. To understand support expectations, review what is typically included in 24/7 IT support.

Clear communication is a security control

During an incident, people are part of the response system. Employees can prevent additional clicks, customers can take protective steps, vendors can accelerate containment, and executives can make faster decisions when communication is clear. The opposite is also true: silence, speculation, and conflicting updates can increase harm.

Prepare the templates now. Assign owners now. Test the channels now. Then connect the communications plan to a broader incident response program that includes monitoring, containment, recovery, privacy review, and post-incident improvement.