Keep audit evidence continuous by listing every control that depends on the old tool, running both tools through the cutover so evidence never has a gap, and recording the change date and reason. Auditors accept a documented change. They question an unexplained gap in scans or reviews.
Why migrations create audit trouble
Controls such as "we scan code for vulnerabilities on every change" are demonstrated by logs, reports and tickets. Switch tools carelessly and there may be a week with neither tool's output, or two different report formats an auditor cannot compare.
Steps
- Map controls to the tool. For each control that mentions scanning or monitoring, note which tool produces the evidence.
- Update the control description. If the control names a specific tool, revise it and keep the old wording in version history.
- Overlap. Run both through the cutover so every day has evidence from at least one tool.
- Log the change. A short change record: what, when, who approved, how it was tested. Our post on change management evidence from pull requests shows what to attach.
- Capture the first evidence from the new tool early. A sample report in week one shows the control works.
- Brief the auditor or assessor. A two line heads-up avoids surprises.
What auditors tend to look for
- The control operated on every date in the period.
- The change was approved and tested.
- Evidence exists in a form they can inspect, with dates and scope.
For what to retain from code scanning, see SAST evidence for auditors.
Watch audit timing
If you are inside an observation window for an attestation, a migration adds risk. Our post on migrating tools during an audit period covers when to wait.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the mapping and see how one piece of evidence can support several framework controls, which is why a tool change touches more than one control.
A simple evidence log
Keep a table with one row per control that depends on the tool: control name, old evidence source, new evidence source, first date from the new tool, and who verified it. Fill it during the overlap. When someone asks in six months how the transition was handled, the log and the change record answer in a minute. Store both where your compliance team keeps other audit material, with the same access rules.
Quick check
Do we need to tell our auditor about a scanner change?
It is good practice, especially if the control description names the tool. Check with your auditor on what they want.
Can we backfill evidence after a gap?
You can document the gap and any compensating checks, but you cannot recreate evidence for a day nothing ran. Avoid the gap instead.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
