Decide three things in advance: who determines whether a customer is affected, what threshold triggers a notice, and which channel carries it. A short notice that states the component, the exposure, the action taken and the next update time is more useful than a long one.
The trigger question
Not every advisory deserves a customer message. Writing the threshold down avoids both silence and noise. A reasonable rule is to notify when a vulnerability in a component you ship is reachable in the customer's deployment, or when customers must take an action such as upgrading a client or rotating a credential.
NIST SP 800-218 asks producers to gather information from acquirers, users and public sources about vulnerabilities in third-party components and to investigate credible reports (RV.1.1), then plan responses based on risk (RV.2.2). Notification is part of the response plan.
Who does what
| Role | Responsibility |
|---|---|
| Security lead | Decides exposure and severity |
| Engineering owner | States the fix or mitigation and timing |
| Customer success or support | Sends the notice and handles replies |
| Legal or compliance | Checks contractual duties and wording |
Name the people. During an incident, "someone" does nothing.
What a notice contains
- The component and version range, in plain terms.
- Whether this product is affected, and which versions.
- What you did, or are doing, and by when.
- What the customer should do, if anything.
- When the next update will come.
Leave out speculation about attackers and anything you cannot confirm.
Template
A vulnerability was disclosed in an open source library used by our product. Based on our review, versions A to B are affected when feature X is enabled. We released version C on date, which includes the fix. Customers running affected versions should upgrade. We will update this notice by time if anything changes.
For incidents where customers ask whether they were exposed, see how to answer "were we affected".
How to describe this in a questionnaire
Say that a defined process exists, name the channel types (email, status page, advisory page) and state that notices follow a documented threshold. If contracts set time limits, say you follow them. Do not invent a time you have not committed to.
Rehearse it
Run a short tabletop exercise once a year. Pick a past advisory, decide whether the product was affected, draft the notice and send it to an internal address. You will find the missing contact list, the approval that takes two days and the template nobody can locate. Fixing those before a real event is the whole point of the exercise.
Try it yourself
Click through it at your own pace, or open it full screen.
Run the check and see how a finding is classified as affecting or not affecting the product. That determination is what your notice is based on.
Safeguard reachability analysis helps establish whether vulnerable code is actually reachable in your application.
Quick check
Should we notify customers about vulnerabilities that do not affect them?
Usually a short statement of "not affected" is enough where customers ask. Broad notices for non issues create noise.
Who approves the wording?
A named reviewer from security and from legal or compliance, with a template to speed the process.
Sources
Last reviewed: 19 October 2026.
