The risky words are the ones that sound like conclusions without evidence: false positive, not applicable, mitigated, accepted, not exploitable and fixed. Each hides a question the auditor will ask. Replace them with scoped statements that name the evidence, the build and the date.
Why one word can cost an hour
An auditor samples closed items and reads the closing note. A note that says "false positive" invites "how do you know", and if the answer is not in the ticket, the sample becomes a finding. It is rarely that the decision was wrong. It is that the reason was not recorded.
The words and their replacements
| Loose word | Question it triggers | Better wording |
|---|---|---|
| False positive | Who confirmed, and how? | Scanner matched version X, installed version is Y, confirmed on date by name |
| Not applicable | Applicable to what? | Component not present in build Z, per manifest |
| Mitigated | By what, tested when? | Named control, test date, owner |
| Accepted | By whom, until when? | Accepted by role on date, expires on date |
| Not exploitable | Under what conditions? | No call path found in version V on date D |
| Fixed | Verified how? | Upgrade merged in pull request N, rescan clean on date |
| Low risk | Compared to what? | Named severity and exploitation signals used |
Borrow from VEX
The standard vocabulary for product status is already precise. The OpenVEX specification defines statuses and a catalog of justification labels, and CISA's minimum elements describe the status of a product or component with respect to a vulnerability. Using those words in your notes makes them consistent and easy to export.
For a not affected claim, OpenVEX requires a justification label or an impact statement. Labels include component not present, vulnerable code not present and vulnerable code not in execute path. Pick the one that matches what you actually established.
Three habits that prevent most findings
- Name the build. A closure without a version is a claim about nothing in particular.
- Add a date. Evidence ages. The CISA document requires timestamps in international standard formats for VEX elements, which reflects how central dates are.
- Put a person on it. A role or name, not a team alias.
Add a template to the ticket
Give the closing field a short template so people fill it correctly. A short prompt such as "What was checked, in which build, on what date, by whom" gets better notes than a free text box. See writing a dismissal comment an auditor will accept for a longer version.
A short audit of your own tickets
Search your tracker for each loose word in the last quarter. Open ten closures. If more than a few lack a version, date or owner, fix the template before the next audit.
Quick check
Is false positive ever acceptable wording?
Yes, when you add what was compared and who confirmed it. The label alone is not enough.
Do we need to rewrite old tickets?
No. Do not alter history. Improve the template and, if asked, add a dated note to old records.
Safeguard's compliance and evidence automation keeps decision records with owners and dates alongside findings. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
