Use a justification whenever one of the five standard values fits, because tools can read it. Add an impact statement when a person needs the reasoning. Write only an impact statement when none of the five values describes your case. Both specs accept either one, but not neither.
What the rules say
CISA's minimum requirements say a not_affected statement should provide a justification. If it does not, an impact statement must be provided. If a justification is present, an impact statement is optional.
OpenVEX is slightly stricter in wording: a not_affected statement must include a justification, an impact statement, or both.
Why the justification wins for automation
The OpenVEX spec describes the impact statement as free-form text that is not intended to be machine-readable, and it discourages its use in automated systems. Its recommended pattern is a machine-readable justification, optionally enriched with an impact statement.
In practice, a pipeline can auto-close findings that carry a vetted justification. It cannot safely auto-close on a paragraph of prose.
When an impact statement is the only option
Some reasons do not fit the five values. A vulnerability might apply only to a platform the product never runs on, or to a deployment mode the supplier does not support. In that case, the impact statement carries the explanation, and consumers must read it.
Keep it short and checkable:
- Name the condition the vulnerability needs.
- Say why the product never meets it.
- Say how the author verified that.
A weak versus a strong impact statement
Weak: "Not exploitable in our environment."
Better: "The vulnerable parser is only reachable through the optional import module. This product ships with that module removed at build time, confirmed by the build configuration for release 3.1."
The second can be checked. The first cannot.
For consumers
Prioritise statements that have both fields. A justification gives you something to filter on, and the impact statement gives you something to challenge. If a supplier sends many not_affected statements with only terse prose, sample a few and ask for evidence.
A quick decision guide
- Does one of the five justification values describe your reason? Use it.
- Would a human reviewer need more context to accept it? Add an impact statement.
- Does none of the five values fit? Write an impact statement alone, and make it specific.
- Is the reason weak or untested? Do not publish not_affected. Use under_investigation until you can explain it.
Review impact statements at release time. If the product changes, the sentence "the module is removed at build time" may stop being true, and nobody will notice unless someone owns the check.
Quick check
Can I send not_affected with no explanation?
No. Both CISA and OpenVEX require at least a justification or an impact statement for not_affected.
Should tools parse the impact statement?
OpenVEX discourages it. Use the justification field for automation and treat the impact statement as text for humans.
Sources
Last reviewed: 19 October 2026.
