NIST does not set one refresh interval for SSDF evidence. Its examples suggest reviewing requirements and roles at least annually, and sooner after new requirements, a major vulnerability or an incident. A practical cadence: policies yearly, settings exports quarterly, and release artifacts on every release.
What NIST says about timing
Three notional examples mention an annual review. PO.1.1 and PO.1.2 suggest reviewing security requirements at least annually, or sooner if new requirements appear, a major vulnerability is found in released software or an incident targets development infrastructure or software. PO.2.1 suggests an annual review of roles and responsibilities. Other tasks, such as PO.3.3, ask you to determine how often collected information should be audited.
These are examples, not mandates, so choose a cadence you will actually keep.
A cadence by evidence type
| Evidence | Suggested refresh | Trigger for an early refresh |
|---|---|---|
| Security requirements policies | Annually | New requirement, incident, major vulnerability |
| Role map | Annually | Team changes |
| Settings exports | Quarterly | Tool or platform change |
| Release SBOMs and signatures | Each release | Component update |
| Scan results | Continuous or each build | None needed |
| Exception register | Per entry review date | New exploit information |
| Training records | Per training cycle | Role change |
Make staleness visible
Add a last reviewed date to every document and index row. Then sort the index by that column once a month. Anything older than its cadence gets a ticket.
Steps
- Assign each evidence type a cadence from the table.
- Put the dates in a shared calendar owned by a role, not a person.
- Automate what you can, so pipeline-generated evidence refreshes itself.
- At each review, record what changed, even if the answer is nothing.
- Close the loop in your annual review with a short summary.
Evidence that should never be refreshed
Some records are meant to be a snapshot of the past: the SBOM of release 4.2, the signed approval of an exception, the minutes of an incident review. Do not overwrite them. Add new versions beside them with new dates.
Buyer-facing dates
If you share evidence with a customer, include the capture date. A buyer can accept a three-month-old settings export if you say so, and may reject one with no date at all.
Start modest
Teams often set an ambitious cadence and then abandon it. Begin with three rhythms you can sustain: an annual policy review, a quarterly settings check and automatic refresh for pipeline output. After two cycles, see what is slipping and adjust. A cadence you keep beats a better one you skip, and the dated record of your reviews is itself evidence that the process works.
Quick check
Is annual review enough?
For policies and roles, NIST's examples treat annual as a baseline. Fast-changing evidence such as scan results needs far more frequent refresh.
Should we delete old evidence?
Follow your retention policy. Release-related records may need to be kept as long as the release is supported.
Safeguard's continuous monitoring and compliance evidence automation can keep scan and policy records fresh. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
