Tell customers four things: what is affected, what you have done, what they need to do, and when the next update comes. Keep each message short and dated. Do not speculate about cause or promise timing you do not control. Silence is usually read as either neglect or concealment.
The four parts
| Part | Content | Example |
|---|---|---|
| Impact | Which products, versions and data are involved | "Self-hosted versions 2.0 to 2.4.2" |
| Action taken | What you already did | "A fix is released as 2.4.3" |
| Customer action | Steps with a clear order | "Upgrade, then rotate the API keys" |
| Next update | A time, not "soon" | "Next update by 16:00 UTC Thursday" |
A cadence that works
- First notice: as soon as you know customers are affected and have something useful to say, even if the fix is not out. State what you know and what you do not.
- Fix notice: when the fix is available, with exact versions and steps.
- Progress update: at the promised time, even if nothing changed. "No change, next update at X" is a valid message.
- Closing notice: when the issue is resolved, with a short summary and, if appropriate, a fuller write up later.
Channels
Use the channel customers already watch for security matters: a status page, a security advisory page, direct email for impacted accounts, and an in product notice for self-hosted software. Make sure the same facts appear in each. Differences between channels look like confusion.
Words to prefer and avoid
Prefer: "We have confirmed", "we are investigating", "we do not yet know".
Avoid: "no evidence of exploitation" unless you have actually looked, and then say where. Avoid "sophisticated attacker" and other filler. Avoid blame. Avoid anything that sounds like legal advice, since customers should take their own counsel on their obligations.
Prepare in advance
Keep templates for the four messages. Pre-agree who approves them, usually security, engineering and a communications owner. During a rollout, writing from scratch under pressure produces mistakes.
Include a way to verify
Where possible, tell customers how to check that they are fixed: a version command, a health endpoint value or a file hash. Customers who can verify for themselves stop sending status questions.
After the event
Publish the final version of the advisory, update the changelog and keep a link to the history. A clear record helps customers in later reviews of your security practice.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing monitoring surfaces what changed, the sort of fact a progress update should state.
Safeguard's compliance and evidence automation helps you keep dated records of remediation work that you can share with customers who ask. A free scan is at gold.safeguard.sh/scan.
Quick check
Should we wait for the fix before telling customers?
Not if customers are already exposed and have an action to take. Tell them what you know, and say when you will update.
Do we need to post an update if nothing changed?
Yes, if you promised one. A short no change message keeps trust.
Last reviewed: 19 October 2026.
