Send a short, factual message once you know whether your product is affected: what the advisory is, whether you ship the affected version, what you have done, what customers should do, and when you will update them. Do not wait for a perfect picture, and do not guess. This is not legal advice.
Decide whether to notify at all
Not every advisory deserves a customer message. Notify when you ship the affected component in a version customers run, when the flaw is reachable, or when customers must take an action such as upgrading an on-premises install. If you are not affected, a brief "not affected" note is useful only to customers who have asked or who are likely to hear about a high profile issue.
Separately, check your contracts. The Security Rule requires business associates to report security incidents they become aware of to the covered entity (45 CFR 164.314(a)(2)(i)), and breach notification has its own outer limit of 60 calendar days after discovery (164.410). Contract terms can be tighter, so know your notice clause before you write anything.
The four message types
| Type | When | Content |
|---|---|---|
| Heads up | Advisory published, assessment under way | What we know, what we are checking, next update time |
| Not affected | Assessment done, not exposed | Why, with the version or code path reason |
| Affected, fix available | Exposed, patched release ready | Impact, fixed version, how to upgrade, interim controls |
| Incident | Evidence of attempt or compromise | Handled by your incident process and counsel, not this template |
A template for the affected case
Subject: Security advisory affecting release X, action needed.
Body, in this order: one sentence on what happened; whether any evidence of misuse has been found, stated precisely; which versions are affected; what we changed; the exact steps for the customer; interim mitigation if they cannot upgrade now; a named contact; the time of the next update.
Keep it under 250 words. Put the technical detail in a linked page so the email stays readable by a busy security officer.
Timing guidance
- Within hours of publication, start the exposure check.
- Within one business day, send a heads up if the issue is widely reported or likely affects you.
- As soon as you know, send an affected or not affected message.
- Follow up when the fix ships and again when the incident record closes.
What not to write
- Absolute claims such as "no customer data was affected" unless logs and scope support it.
- Blame on the library maintainers.
- Speculation about attackers.
- Anything that contradicts what you told a hospital earlier. Keep a record of messages.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new disclosure is matched against components in use, which is the first question in your heads up message.
Safeguard's zero-day discovery and reachability analysis support that exposure check. Message content and any legal duty to notify are for your team and counsel.
Quick check
Should the first message wait until the fix is ready?
Not if customers must act or are likely to hear about it. A short heads up with a next update time is better than silence.
Who should approve the message?
Security lead and a customer facing owner, with counsel for anything involving an incident.
Sources
- 45 CFR 164.314 Organizational requirements, eCFR
- 45 CFR 164.410 Notification by a business associate, eCFR
Last reviewed: 19 October 2026.
