There is no universal retention period for scan results. Keep them as long as you need for remediation tracking, trend reporting and audit evidence, and no longer. Set a period per data class, write it into the contract, and ask the vendor how deletion works when the period ends.
Three needs pull in different directions
Operations. Engineers need current findings and recent history to fix things. A few months is usually enough.
Evidence. Auditors may ask you to show that you scanned regularly and acted on results. That can mean a year or more of summary records. The retention depends on your frameworks and your own policy, so confirm with your auditor and counsel rather than copying a number.
Privacy and risk. Older detailed results keep growing in value to an attacker while shrinking in value to you. A list of vulnerabilities fixed two years ago is of little use, but a record of what an application exposed back then can still reveal architecture.
The GDPR's storage limitation principle makes the same point for personal data: keep it in identifiable form no longer than necessary for the purpose. Findings are not mostly personal data, though assignees and commit authors in them are.
A schedule you can adapt
| Data | Suggested approach | Why |
|---|---|---|
| Open findings | Keep while open | Needed to fix |
| Closed findings, full detail | Months, set by policy | Useful for regressions and reviews |
| Summary metrics and counts | Longer, for trends and audits | No code excerpts, little risk |
| Code excerpts and file paths | Shortest period you can live with | Most revealing |
| Evidence exports you made | Held by you, under your own policy | Not the vendor's job |
| Access and API logs | A defined period, often tied to security needs | Needed for investigations |
The point is the structure, not the numbers. Fill the numbers with your compliance and legal people.
Export what you need before it expires
If a vendor deletes detailed history after a set time, check that you can export what auditors need first. Ask for a scheduled export of summaries to your own storage. Then your evidence retention does not depend on the vendor's retention. For general evidence guidance see audit evidence retention: how long to keep it.
What to ask the vendor
- What is the default retention per data class, and can we change it per tenant?
- Does a shorter setting actually delete, or only hide?
- How long do backups and logs keep deleted records?
- Can we trigger deletion on demand, such as when a project is retired?
- Do you notify us before a retention period removes data we may need?
Try it yourself
Click through it at your own pace, or open it full screen. Notice that continuous monitoring produces a steady stream of new results, which is why a retention rule matters.
How Safeguard fits
Safeguard's compliance and evidence automation is meant to produce the summary records auditors ask for, so you can keep evidence under your own policy. Try the free scan to see what a result contains.
Quick check
Is shorter retention always better?
No. If you cannot show past scans to an auditor or trace when a fix landed, you lose evidence. Balance exposure against audit needs, class by class.
Who decides the period, you or the vendor?
You should. Treat the vendor default as a starting point and negotiate a per class setting.
Sources
Last reviewed: 19 October 2026.
