There is no universal number. Keep reachability and exploitability records at least as long as the longest of your audit period, your customer contracts and your own policy requires, then add margin for disputes. Ask counsel and your auditor for the figure that applies to you, and write it into your retention schedule. This is not legal advice.
Why a fixed answer would be wrong
Retention depends on who is asking and why. A SaaS vendor with annual customer audits has different needs from a company supplying a regulated sector. A record that was routine last year can become evidence in a dispute this year.
Be wary of any article, including this one, that gives a single figure. The honest version is a method for finding yours.
Find your own period in four steps
- List the obligations. Contracts with customers, any framework you report against and your own policies. Note each retention or evidence period they mention.
- Take the longest. The strictest source sets your floor.
- Add margin. Disputes and late questions arrive after the audit window closes.
- Check with counsel. Some records have legal hold implications that only a lawyer can assess.
What to keep
| Record | Why keep it |
|---|---|
| The reachability result with commit, tool version and date | Reproduces the decision |
| The decision note with owner and reason | Shows judgment and accountability |
| Exception approvals and expiries | Shows governance |
| Any VEX statements sent to customers | Shows what you told them and when |
| The policy version in force at the time | Shows which rule applied |
| Rescan evidence after a fix | Shows the outcome |
The CISA minimum elements for VEX include fields for when a statement was first issued and last updated. Keeping that history, not just the latest state, is what makes the record useful later.
What not to keep forever
Raw scan output can contain information about your systems that you would not want widely accessible. Keep the exports tied to sampled findings and set access limits. If a record is no longer needed, delete it on schedule and log the deletion according to your own retention policy.
Make retention testable
A policy that says "retained for the required period" will draw a follow up question. A policy that says where records live, who can read them and when they are reviewed for deletion gives the auditor something to test.
- Store records in a system with an audit log.
- Restrict write access so that history cannot be altered quietly.
- Test retrieval once a year by pulling a record from two years back.
NIST's Secure Software Development Framework describes updating records of risk responses and approved exceptions, which supports keeping a dated history rather than overwriting.
Avoid the two common mistakes
Keeping nothing beyond the current state is the first. You cannot show what you knew on a past date. Keeping everything indefinitely with open access is the second. You create exposure and cost with no benefit.
Quick check
Is the latest state of a finding enough?
No. Auditors often ask about a past period, so keep the history.
Who decides the retention period?
Your policy owner, informed by contracts, frameworks and counsel.
Safeguard's compliance and evidence automation keeps dated records linked to findings. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
