A customer notice about a vulnerable component should say which products and versions are affected, which are not, what customers should do, what you have done, and when the next update comes. Keep it factual and short. Leave out speculation, blame and anything you have not verified.
The fields that matter
| Field | What to write | Why |
|---|---|---|
| Title and date | Plain description and the true publication time | Lets readers track updates |
| Component and identifier | Name, advisory or CVE reference | Lets customers match their own scans |
| Product status | One line per product and version range | Answers "are we affected?" fast |
| Customer action | Upgrade to a named version, or apply a stated mitigation | Turns the notice into a to-do |
| What you are checking | Products still under investigation | Honest about unknowns |
| Next update | A date or time | Sets expectations |
| Contact | A named channel | Reduces ad hoc email |
The structure mirrors the status vocabulary in the CISA minimum requirements for VEX: not affected, affected, fixed and under investigation. Using the same four words in your prose and in your machine-readable statements keeps both consistent.
Write the status lines like this
- Affected: "Product A versions 3.0 to 3.4 include the component. Upgrade to 3.5."
- Fixed: "Product B 2.2 contains the fix."
- Not affected: "Product C does not include the component."
- Under investigation: "We are still confirming Product D and will update by the stated time."
Each line should be checkable. If you state "not affected" because the code is never called, say so, since customers may ask. The CISA text says a not affected statement must carry a justification or an impact statement explaining why.
Things to leave out
- Guesses about who is behind an attack or how it began.
- Promises of a fix date you cannot control.
- Marketing language about your security program.
- Legal conclusions. Have your own counsel review anything that touches contracts or regulatory duties.
Pair it with a VEX document
A notice is for people, and a VEX document is for tools. Publish both when you can. The CISA document notes that VEX can be authored by the software supplier or a third party, and that an advisory can itself be a valid VEX document or include one. If you cannot publish VEX yet, the notice is still worth sending.
After sending
Log the time, the recipients and the wording. If a fact changes, issue a dated update rather than editing the original quietly. Customers who copied the first version should see the change.
Quick check
How long should the notice be?
Short enough to read in two minutes. Put status lines first and background after.
Should we name the root cause?
Only when it is confirmed and your approver agrees. Early guesses often turn out wrong.
Can we say a product is not affected without proof?
No. State the evidence or mark the product as under investigation.
Safeguard's compliance and evidence automation helps keep the records behind notices like this one in order.
Sources
Last reviewed: 19 October 2026.
