Vulnerability scan results and SBOMs go stale fastest, often within days, because advisories and releases change constantly. Access lists and exception approvals age in weeks. Policies, architecture descriptions and training records age in months. Label each item with a date and a refresh interval so readers know how far to trust it.
Why shelf life matters
A buyer reading a scan report from three weeks ago cannot tell whether it still reflects reality. Neither can you, unless you rerun it. The risk is not that the document is wrong when written but that it is quoted later as current.
Shelf life by evidence type
| Evidence | Typical shelf life | Why it ages |
|---|---|---|
| Vulnerability scan report | Days | New advisories every day |
| SBOM | Until next release | Components change with code |
| Known issues register | Weeks | Fixes land, new items appear |
| Access and admin lists | Weeks | People join, leave, change roles |
| Exceptions and risk acceptances | Until expiry date | They should carry one |
| CI and branch settings | Weeks to months | Changed by admins |
| Policies | Months | Reviewed on a cycle |
| Training records | Annual | Cycle based |
| Pen test report | Months to a year | Code moves on after the test |
| Architecture and data flow diagrams | Months | Drift as systems change |
Set a header on every file
Put three lines at the top of each evidence document or in the index: generated on, covers, refresh by. Then no one has to guess. If you use the index to list files, add a column for each.
A refresh rhythm that fits a small team
- Weekly during an active process: rescan stored SBOMs and update the register counts.
- At each release: new SBOM, stored and indexed.
- Monthly: access list export, branch rule check, exceptions review.
- Quarterly: policy read through, diagram check.
- Annually: training cycle and pen test scheduling.
Automate what you can. Generating an SBOM in the build and rescanning it on a schedule costs nothing per refresh once set up.
When evidence is older than you would like
State the date plainly and say what you have done since. A pen test report from nine months ago is not a problem if you add: "fixes for all high findings were verified on 3 September, and one release since has touched these areas." That gives the reader the context to judge.
Retention versus freshness
Do not delete older versions. Keep them in an archive folder with dates. They prove history, such as how fast a past vulnerability was fixed. Keep just the current version in the main folder.
Mistakes
Dropping a PDF into the data room and forgetting it. Rescanning but not updating the summary. Editing a file in place with no version history. Letting one person hold all the refresh duties and then having them go on leave mid process.
Quick check
Do policies need refreshing during a deal?
If something changed. Confirm the review date is within your stated cycle.
Is a months old scan acceptable?
As history yes, as current status no. Label it with its date and provide a recent one.
Safeguard keeps SBOMs and findings in one place with dated compliance evidence automation, which suits this kind of refresh rhythm. A free scan shows the current state of a repository.
Last reviewed: 19 October 2026.
