Article 14 has separate triggers for an actively exploited vulnerability contained in a product and a severe incident affecting product security. A decision not to report should show how the available evidence was tested against both routes.
Avoid a one-line conclusion such as “not severe” or “not exploited.” It cannot show which product versions were examined, which evidence was accepted, or what would cause the decision to change.
Record each trigger test
For the vulnerability route, document whether the vulnerability is contained in the product and whether there is reliable evidence of exploitation by a malicious actor without the system owner’s permission. For the incident route, document the relevant product-security effects against the severe-incident criteria.
For each route, record the conclusion, reviewer, decision time, evidence links, assumptions, and unresolved conflicts. If the test cannot yet be completed, use an open assessment state rather than treating missing evidence as proof that the trigger is absent.
Preserve contrary evidence
Include the strongest evidence for reportability, not only the material that supports closure. For the vulnerability route, preserve exploitation reports, product-containment questions, and source-reliability limits. For the incident route, preserve observed and credible potential effects for each severe-incident test.
Explain why the retained contrary evidence did not change the outcome at that time. If it was rejected because it concerned another product, an unreachable component, authorised testing, or an unsupported attribution, link the evidence for that distinction.
Keep “trigger not met” separate from “unable to conclude”. The first is a decision based on the evidence reviewed. The second requires an owner, next evidence source, and review time.
Define a reopen condition
List the new facts that would require reassessment: confirmation of affected versions, reliable exploitation evidence, a change in impact, or a corrected incident timeline. Assign an owner to monitor those facts while the case remains active.
Give each reopening condition a source channel and time horizon. A supplier update, newly confirmed product mapping, customer incident report, or revised technical finding should reach the same case owner. When one arrives, create a new assessment event rather than editing the original negative decision.
Before closure, have a reviewer who did not write the analysis test both trigger worksheets, the contrary-evidence section, and the reopening rules. They should be able to state which facts were decisive and which facts would change the result.
A reviewable non-report decision is not about creating paperwork for its own sake. It lets a later reviewer understand the boundary of the original analysis and respond quickly when the evidence changes.
Continue this workflow with the conflicting-exploitation review and the voluntary-reporting decision.