How to communicate with customers after a security incident

TL;DR — After a security incident, send three customer messages in order: an initial notice within hours, a follow-up when facts are confirmed, and a resolution update with exact customer actions. The most common fix is to stop trying to explain everything at once: publish only confirmed facts, what you are doing now, what customers must do now, and when the next update will arrive. Reading time: ~5 min

Goal

When you finish, you will have a customer-ready incident communication pack: one initial message, one follow-up update, one resolution message, a single source-of-truth status page or help-center post, and a short checklist that confirms every customer-facing channel says the same thing.

Prerequisites

• Access to your company email tool or shared inbox (for example, Google Workspace Gmail, Microsoft 365 Outlook, or your email provider)
• Access to your public status page or website editor; if you do not have one, access to your help-center or blog editor
• Access to the customer messaging channel you will use: email list, in-app banner tool, or CRM (customer relationship management, your customer contact system)
• Your incident lead's name and contact method for approvals
• A confirmed list of facts: what happened, when it started, what systems were affected, what customer data was involved, what is still unknown
• A list of customer actions, if any, with literal steps such as "reset your password" or "ignore suspicious emails claiming to be us"
• Your legal/compliance contact if regulated data may be involved
• A plain-text document or note where you will draft the messages before publishing

Steps

Step 1: Create one source of truth for updates

Use one public page for all updates. In your provider's dashboard, open your status page or website editor and create a new post titled exactly:

Security incident update - [YYYY-MM-DD]

If you do not have a status page, use your help-center or blog. Put this exact structure at the top of the page:

Current status: Investigating
Started: [YYYY-MM-DD HH:MM TZ]
Affected service(s): [service names]
Customer impact: [one sentence]
What we are doing: [one sentence]
What customers should do now: [one sentence or "No action required at this time"]
Next update by: [YYYY-MM-DD HH:MM TZ]

What you should see when this succeeds: a public URL you can paste into email and support replies.

Step 2: Draft and send the initial customer notice

Open your email tool and create a message to affected customers. Use this exact template and replace the bracketed fields:

Subject: Important: Security incident affecting [service name]

Hello,

We are investigating a security incident affecting [service name].

What we know now:
- Incident start time: [YYYY-MM-DD HH:MM TZ]
- Affected service(s): [service names]
- Customer impact: [plain sentence]
- Data involved: [confirmed data types, or "We are still confirming this"]

What we are doing now:
- [action 1]
- [action 2]
- [action 3]

What you should do now:
- [literal action, e.g. "Reset your password using [URL]"]
- [literal action, or "No action required at this time"]

We will post updates here: [public status/help-center URL]
Next update by: [YYYY-MM-DD HH:MM TZ]

We are sorry for the disruption and will share confirmed facts as we have them.

Send it to the affected segment only. If your email tool asks for a recipient list, choose the list that matches the affected product, region, or account group.

What you should see when this succeeds: the message appears in your sent items and the status/help-center URL in the email opens correctly.

Step 3: Publish the same message on your public update page

Open the page from Step 1 and paste the same facts from the email into the page body. End with this exact line:

We will update this page by [YYYY-MM-DD HH:MM TZ], even if our investigation is still in progress.

If you also use an in-app banner, use this exact short version:

We are investigating a security incident affecting [service name]. See updates: [URL]. Next update by [HH:MM TZ].

What you should see when this succeeds: the public page, email, and any banner all show the same status and same next update time.

Step 4: Prepare the follow-up update with confirmed facts only

When your team confirms more details, edit the public page and send a follow-up email. Use this exact structure:

Subject: Update: Security incident affecting [service name]

Hello,

This is an update to our earlier notice about the security incident affecting [service name].

What we have confirmed:
- Root cause: [plain sentence, or "Still under investigation"]
- Affected time window: [start] to [end or "ongoing"]
- Data involved: [exact confirmed data types]
- Data not involved: [exact confirmed exclusions]
- Service status: [restored/degraded/investigating]

What we have done:
- [action 1]
- [action 2]
- [action 3]

What you should do now:
- [literal action]
- [literal action]

Support contact:
- Reply to this email or visit [support URL]

Next update by: [YYYY-MM-DD HH:MM TZ]

Do not add guesses, attack details that help copycats, or phrases like "everything is secure now" unless your incident lead has approved that exact claim.

What you should see when this succeeds: the follow-up message answers the top customer questions without contradicting the first notice.

Step 5: Send the resolution message

When containment is complete and customer actions are final, send a resolution update. Use this exact template:

Subject: Resolved: Security incident affecting [service name]

Hello,

We have completed our response to the security incident affecting [service name].

Resolution summary:
- Incident window: [start] to [end]
- Services affected: [service names]
- Data involved: [exact confirmed data types]
- Containment completed: [YYYY-MM-DD HH:MM TZ]

What we changed:
- [control 1, e.g. "Revoked affected credentials"]
- [control 2, e.g. "Forced password resets for affected accounts"]
- [control 3, e.g. "Added additional monitoring"]

What you should do:
- [literal action, or "No further action required"]

Reference page:
- [public URL]

We are sorry. If you need account-specific help, contact [support URL or email].

What you should see when this succeeds: customers have one final message with the incident window, impact, and exact next action.

Step 6: Check every customer-facing channel for consistency

Open your email, public page, support macro library, and any in-app banner. Confirm these literal fields match everywhere:

Status
Affected service(s)
Customer impact
What customers should do now
Next update by / Resolved at
Public URL

If your support team uses saved replies, update the macro text to this exact one-line answer:

For the latest confirmed information about this incident, use this page: [URL]. If your account needs a password reset or account-specific review, reply here and we will help.

What you should see when this succeeds: support replies, public updates, and outbound messages all point to the same URL and same current status.

Verify it works

Use this checklist after publishing:

1. Open the public update URL in a private/incognito browser window.
2. Confirm the page shows: Current status, customer impact, customer action, and next update time.
3. Open the sent email and click the public update URL.
4. Confirm the URL opens without requiring a login.
5. Ask one teammate to read the email and answer two questions:
   - "What should the customer do right now?"
   - "When is the next update?"
6. If the teammate cannot answer both in under 15 seconds, edit the message and resend only if needed.

Expected result: a customer can read any one of your messages and immediately understand the impact, the action required, and where future updates will appear.

Common pitfalls

Sending before you have a customer action line

Mistake: you send a notice that explains the incident but does not say what the customer should do.

Symptom: support tickets immediately ask, "Do I need to reset my password?" or "Am I affected?"

Fix: add a literal line that says either What you should do now: Reset your password at [URL] or What you should do now: No action required at this time.

Mixing confirmed facts with guesses

Mistake: you include suspected causes or estimated impact as if they are final.

Symptom: your second update contradicts the first, and customers lose trust.

Fix: replace any unconfirmed statement with We are still confirming this and move details to the next scheduled update.

Different channels say different things

Mistake: the email says one update time, but the status page or support macro says another.

Symptom: customers reply with screenshots and ask which message is correct.

Fix: update the public page first, then copy the same status line and timestamp into email, banner, and support macros.

Hiding the next update time

Mistake: you promise updates "soon" or "as available".

Symptom: customers keep asking for progress because they do not know when to check back.

Fix: publish an exact timestamp like Next update by: 2026-10-30 18:00 UTC even if the next update is only "investigation continues."

Sending one giant message to every customer

Mistake: you email your full customer base when only one product, region, or account group is affected.

Symptom: unaffected customers panic and support volume spikes.

Fix: send the detailed notice to affected customers only, and use the public page for broader visibility if needed.

Explaining technical details instead of customer impact

Mistake: the message focuses on logs, tokens, endpoints, or malware names without saying what it means for the customer.

Symptom: customers read the message and still do not know whether data, access, or billing is affected.

Fix: rewrite the first four lines to cover affected service, customer impact, data involved, and customer action in plain language.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.