A VEX follow-up should replace under investigation statuses with final ones, add an action statement for each affected product, carry updated timestamps and a higher version number, and come with a short note saying what changed. Send it on the date you promised in the first notice.
What the specifications say about updates
The OpenVEX specification states that a document's version must be incremented whenever any content changes, including statements. It also says that when you update a document, the integrity of untouched statements must be preserved, so unchanged statements keep their original timestamps.
The CISA minimum requirements add that the document's last updated time must be equal to or newer than the latest update in any of its statements, and that statuses with under investigation are expected to change once an investigation concludes. For affected products, the statement must include an action statement describing remediation or mitigation.
What to change, status by status
| Before | After | What to add |
|---|---|---|
| under_investigation | not_affected | A justification or impact statement |
| under_investigation | affected | An action statement with the fix or mitigation |
| affected | fixed | The version that contains the fix |
| not_affected | affected | A note explaining what changed, since this is a reversal |
The status names above are the ones both specifications use.
A cadence that works
- Day 0: first notice, with statuses including under investigation.
- Next promised time: update with settled verdicts. If nothing has changed, say so in a short post rather than staying silent.
- When a fix ships: mark affected products as fixed with the fixed version.
- Close: publish a final update and say when you will stop issuing them.
The cover note
Each update should open with two or three plain sentences: what changed, which products moved status, and when the next update is due. Customers should not have to diff two files to find out.
Mistakes to avoid
Do not edit a published statement without incrementing the version. Do not change a not affected verdict to affected without saying so loudly. Do not delete old statements to make the document look clean, because customers may rely on the history.
Related reading: VEX statement lifecycle from under investigation to final and VEX document versioning and timestamps rules.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a finding changes once a fixed version exists.
Quick check
Do we need to reissue untouched statements?
They stay in the document, with their original timestamps preserved, while the document version and last updated time change.
What if nothing changed by the promised time?
Send a brief update saying so and give the next time. Silence erodes trust faster than a short status.
Safeguard's autonomous remediation can open fix pull requests (off by default), which helps move products from affected to fixed.
Sources
Last reviewed: 19 October 2026.
