Pick five samples from your own records, trace each through detection, decision, change and verification, and score what is missing. In about 45 minutes you will find the weak link in your dependency controls. Fix that before the auditor samples it, and repeat monthly.
Why a mini dry run
Full mock audits take days. A narrow rehearsal on one control family is cheap and catches the common failure: the process exists, but the records do not connect. You do it as an internal check, so go in expecting to find gaps.
Before you start
Gather access to your scanner or alert list, your ticket tracker, the repository settings and the policy. Put someone in the room who did not run the process, to play skeptic.
The 45 minutes
Minutes 0 to 10: population. Export all dependency findings for the last 90 days. Count them. Confirm the export includes closed items. If you cannot produce a complete list in ten minutes, that is finding one.
Minutes 10 to 20: sample and trace. Pick five items at random, mixing severities. For each, find the alert, the ticket, the pull request, the deploy and the rescan. Time yourself. Anything over five minutes per item signals weak linking.
Minutes 20 to 30: policy check. For each sample, compare the dates with your policy timeline. Mark met or missed. For misses, look for an exception record made at the time.
Minutes 30 to 40: configuration. Open repository settings. Confirm the default branch requires review and status checks, which GitHub documents as available protected branch settings. Confirm alerts are on for every in-scope repository, and check that the coverage list matches.
Minutes 40 to 45: score and assign. Fill the table.
| Check | Pass | Partial | Fail |
|---|---|---|---|
| Complete population export | |||
| Alert to ticket link | |||
| Ticket to PR link | |||
| Fix within policy or excepted | |||
| Rescan or closure evidence | |||
| Branch protection as written | |||
| Coverage matches repo list |
Common results
Teams usually find that closed alerts have no ticket, that pull requests do not reference tickets, and that two or three repositories were never scanned. All are cheap to fix: add a ticket field to the PR template, turn on alerts for the missed repos, and require a closing note.
What to do with the output
Write each gap as a ticket with an owner and a date. Retest the same check next month with five new samples. A trend of fewer gaps is itself evidence that you monitor your controls.
Do not game it
Choose samples randomly. If you cherry pick clean items, you learn nothing and the auditor will find the rest. Also avoid fixing a record after the fact and presenting it as original. Add a dated note instead.
Where Safeguard fits
Safeguard's dependency scanning and compliance and evidence automation keep alerts, decisions and closures linked, which shortens the trace step. Free scan: https://gold.safeguard.sh/scan.
Quick check
Should I tell my auditor about gaps I found?
You do not need to report every internal finding, but never hide or backdate records. Fix the process and keep dated notes of what changed.
How many samples is enough for a dry run?
Five is enough to find process gaps. The auditor's sample size is theirs to decide.
Sources
Last reviewed: 19 October 2026.
