Reply to a customer's "are you affected" question with one of four clear statuses: not affected, affected and fixed, affected and being fixed, or still investigating. Give a one line reason, the date you last checked, and when they will hear from you next. Never answer faster than you can verify.
Pick a status you can defend
Customers read your reply as a commitment. Choose the status the evidence supports.
| Status | Use when | What to add |
|---|---|---|
| Not affected | The component is absent, or the vulnerable function is not used | How you checked and the date |
| Affected, fixed | The patch is deployed | Fix date and version |
| Affected, in progress | You know it applies and are working on it | Target date and any interim mitigation |
| Investigating | You have not finished checking | When the next update will come |
"Investigating" is a legitimate answer. A confident wrong answer is far worse, because you may have to retract it.
The reply template
Subject: Update on CVE-XXXX-XXXXX and our service
"Thanks for asking. As of [date and time], our status is [status]. Reason: [one sentence]. What we did: [checked inventory, reviewed code path, applied update]. What you need to do: [nothing / action]. We will send our next update by [date], or sooner if this changes."
Keep it to a short paragraph. Attach evidence if the customer asks, and have a version of it ready.
Check before you answer
To say "not affected", you need an inventory that includes indirect dependencies, container base images and any managed services you run. A search of your top level manifests is not enough, because the component may arrive through another package. If your inventory is incomplete, say "investigating" and finish the work.
For "not affected because the code is not reachable", record how you determined it. A statement in a machine readable exploitability format, such as VEX, can carry that reasoning, but the plain email still needs to be understandable on its own.
Handle the awkward cases
You do not use the product named. Say so, and offer to confirm for named components if they list them.
The customer shares a scan of your public site. Scanners often match on version banners. Ask for the finding, check it, and reply with the result rather than arguing about the tool.
The advisory is still developing. Say what you know and that the facts may change. Offer a time for the next update.
Many customers ask at once. Write one approved statement and put it on a status or trust page, then link to it in replies. It stops contradictory answers from different people.
Keep a record
Log the question, your answer, the evidence and the date. If your status changes, update everyone you told. A short log also helps with questionnaires and audits later.
Safeguard's asset discovery and SBOM and dependency scanning give a searchable inventory to answer "do we use this component", and the free scan at gold.safeguard.sh/scan shows how that looks on a project.
Quick check
How fast should I answer a customer's CVE question?
Acknowledge quickly, and give a verified status as soon as you can. A fast "investigating, next update at 3 pm" beats a fast wrong answer.
Can I say not affected if I checked just direct dependencies?
No. Check indirect dependencies and images, or say investigating.
Last reviewed: 19 October 2026.
