How do you keep audit evidence when retiring an old dependency policy?

When you retire an old dependency policy, archive it instead of deleting it. Keep the version that applied, its effective dates, and the scan results, approvals, and exceptions produced under it. Then map each old control to its new equivalent so an auditor can follow the change. Confirm retention periods with your compliance or legal advisers.

Why the old policy still matters

An auditor or customer reviewing a past period asks what rules applied then and whether you followed them. If you replaced the old policy and threw it away, you cannot answer. The evidence you collected under it still belongs to that period.

What to archive

For each retired policy, keep a single bundle:

1. The final policy text, with version number and the date it stopped applying
2. The date it took effect and any earlier versions
3. The list of controls or rules it contained
4. Scan and gate results from the period
5. Approval records and exceptions granted under it
6. The announcement or notice sent to teams
7. The decision record that explains the merge

Store the bundle where it cannot be edited casually, and where the people who answer audits can find it.

Draw the line with dates

A clean cutover date helps. Evidence before the date points to the old policy, evidence after points to the new one. If you phased the change, record the date each rule moved and keep a short table.

Map old controls to new ones

If a framework or customer questionnaire references your controls, update the mapping. Show which new rule covers each old one, and call out any rule that was dropped, with the reason. Honest mapping is better than a document that implies nothing changed.

The NIST Secure Software Development Framework is described as a core set of high level practices that can be integrated into each software development life cycle, so mapping to practices rather than to document titles survives policy rewrites more easily.

Be careful with claims

Do not describe the merged policy as certified, attested, or audited unless that is true and you can point to the report. A policy is an internal document. An audit result is a separate thing, issued by someone else for a defined period.

Keep the evidence flowing

After the cutover, check that automated evidence collection still runs for both the retired and the new rules during any overlap. A common gap: a scan job tied to the old policy is switched off a week before the new one produces its first report.

For related reading, see what to archive for each software release and policy review dates and the out of date policy finding.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how one control can be mapped to several framework requirements.

Safeguard's compliance and evidence automation can collect and organize records from scans and gates, so the trail across a policy change stays in one place.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1

Last reviewed: 19 October 2026.