When a security story does not apply to you, record that as a decision: what you checked, what you found, who decided and when you will look again. A short written note takes five minutes and saves hours when a customer, auditor or colleague asks later whether you saw the news and what you did about it.
Why write it down
Memory fades, people leave, and "we looked at that" is not evidence. A dated note shows that the check happened and what it covered. It also protects you from repeating work: next month someone asks the same question and the note answers it.
What the note contains
Keep it to six fields:
- The story: name, identifier if any, link to the primary source.
- Date and author of the check.
- What was checked: repositories searched, images inspected, vendors asked, hosts listed.
- Result: not affected, with the specific reason.
- Confidence: high if you verified versions, medium if you relied on a vendor statement.
- Revisit date or trigger, such as "if the vendor updates the advisory".
Good reasons and weak reasons
Good reasons are specific: "we do not use the product", "our version is outside the affected range", "the vulnerable feature is disabled by configuration and the setting is enforced in code". Weak reasons are vague: "probably fine", "the scanner did not flag it", "nobody is exploiting it yet".
If your reason depends on a configuration, note where the configuration lives so a later change does not silently reopen the exposure.
Link it to your formal status vocabulary
If you track vulnerability status in a standard format, use its terms consistently. Many teams use labels such as affected, not affected, fixed and under investigation, with a short justification for not affected. Whatever labels you pick, define them once and keep them stable.
Who signs off
For low impact items, the person who ran the check can close the note. For anything touching customer data or an important system, a second person reads the reasoning. Review does not need to be heavy, it just needs a different pair of eyes.
Revisit on triggers
Facts change. The vendor updates the advisory, exploitation appears, a new version of your own software pulls in the component. Choose triggers that match the story, and put the date on your calendar.
Where to keep it
One shared folder or tracker, searchable by product name. Consistency matters more than the tool.
Quick check
Do I need a note for every story I read?
Only for stories where you ran an exposure check. For stories that clearly do not touch you, the digest line is enough.
What if my reason was a vendor statement?
Record it as medium confidence, quote the statement with its date, and plan to re-check.
Last reviewed: 19 October 2026.
