There is no universal period. Keep scan exports, fix tickets and approvals for the longest of your policy, your contracts and the rules that apply to you. One New York rule asks for audit trail records for not fewer than five years, which shows how long some periods run.
Which records are we talking about
For vulnerability management, the records that tend to matter are:
- Scan results and the configuration that produced them.
- The findings register and its history.
- Fix tickets, with created, fixed and verified dates.
- Change records for production fixes, with approvals.
- Exception approvals and their reviews.
- Reports to senior leaders.
- Penetration test reports and retests.
What the sources say
NIST SP 800-53 configuration change control asks that records of configuration-controlled changes be retained for a period the organization defines. Its audit record retention control likewise asks organizations to retain audit records for an organization-defined time, to support after-the-fact investigations and to meet regulatory and organizational retention requirements. Neither fixes a number, so you set one.
New York's financial services rule on audit trails asks covered entities to maintain records required by that section for not fewer than five years. That section concerns systems that reconstruct material financial transactions and audit trails designed to detect cybersecurity events, so it does not automatically cover every vulnerability record. Ask counsel how it applies to you.
A decision method
- List each record type.
- For each, find the longest applicable period from law, contract and internal policy.
- Use that period, and write it into a retention schedule.
- Note who owns deletion.
- Review the schedule annually.
| Record | Typical drivers | Your decision |
|---|---|---|
| Scan exports | Audit lookback, investigations | Set period, store with dates |
| Fix tickets | Audit sampling, trend analysis | Set period |
| Change records | Change control rules, investigations | Set period |
| Exception approvals | Audit sampling | Keep at least until expiry plus the audit lookback |
| Pen test reports | Contract and audit requests | Set period, restrict access |
Our general guide on audit evidence retention covers the wider decision.
Pitfalls
- Tool defaults. Many scanners keep history for a limited time unless you export. Check before an audit asks for last year.
- Ticket cleanups. Archiving old projects can delete history.
- Vulnerability reports are sensitive. Long retention means long exposure, so limit access.
- Personal data in tickets. Names and emails in comments may trigger privacy retention limits. Balance both with counsel.
Make exports routine
Schedule a periodic export of findings and their history into storage you control, with a hash recorded for integrity. Then retention does not depend on a vendor tool's own limits.
Where tooling helps
Safeguard keeps findings tied to components and policy decisions and supports evidence automation, which helps produce dated exports. You still choose and enforce the retention schedule.
Quick check
Should we keep every scan result forever?
No. Longer retention has costs and risks. Keep what your schedule says, then delete on a documented routine unless a legal hold applies.
Is five years the standard?
No. Five years is what one New York rule says for the records that section covers. Other rules and contracts differ.
Sources
Last reviewed: 19 October 2026.
