Keep them for as long as the software could still be running anywhere in your environment, and at least as long as your general records policy requires. Required retention periods are a question for your legal and compliance teams. Technically, an old SBOM answers questions long after the contract ends.
Why the contract end date is the wrong trigger
Contracts end; software lingers. A retired product may still run on a forgotten server, in a backup image or in a test environment. If a serious flaw appears in a component that product contains, the old SBOM is how you find out you are affected.
The NTIA minimum elements report notes that some use cases need complete or mostly complete graphs, such as proving a given component is not on a network. That kind of statement is only possible if the old files still exist.
Three clocks
- The software clock. Until the last instance of the product is truly gone, keep its SBOMs.
- The records clock. Your organization's policy and any legal or regulatory duty set a minimum. Ask counsel what applies to you.
- The investigation clock. After an incident or a customer dispute, you may need to show what components a version contained on a given date.
The longest of these sets your retention.
Step by step
- Tag each stored SBOM with a status. Active, superseded, product retired.
- Track decommissioning. When the product is shut down, record the date and confirm no instances remain.
- Keep superseded files. A new SBOM does not replace the old one for historical questions. The NTIA report says a new SBOM is created for each new build or release, which means the old release still has its own file.
- Set a review date after decommissioning. Ask counsel and your records owner whether to keep, archive or delete.
- Archive, do not scatter. Move retired files to a read-only location with the supplier, product, version and date in the name.
- Handle confidential files properly. If the supplier shared under restricted terms, check those terms for return or deletion requirements before deleting or keeping.
Storage and cost
| Item | Typical size | Note |
|---|---|---|
| One SBOM file | Small text file | Cheap to store |
| Many versions over years | Adds up modestly | Compress and archive |
| Access logs | Small | Keep alongside for evidence |
The cost of keeping is low, which favors keeping. The cost of deleting something you later need is high.
What to delete
Copies you made for convenience, such as extracts or working spreadsheets, can go once the master is archived. Anything covered by a deletion clause in the supplier agreement should be handled as the agreement says. If the agreement is silent, record the decision and who made it.
Evidence value
An archived SBOM with a received date, a checksum and a note of where it came from is better evidence than a file with no history. It shows what the supplier told you at the time. Record the received date when you save it.
Quick check
Can we delete an SBOM when the supplier contract ends?
Check your agreement and records policy first. Technically it is safer to keep it while any instance of the software may still exist.
Is there a legal minimum retention period?
That depends on your jurisdiction, industry and contracts. This post does not give legal advice, so ask your counsel.
If you need a quick look at an archived file, Safeguard's free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
