Walk the auditor through one real package from request to production, showing a record at each step: the request, the review notes, the approval, the mirror entry, the build that used it and the closed change ticket. A live example with evidence beats a diagram of the process.
Prepare before the call
Pick one package that entered recently and went through the normal path, not a hand-picked showpiece. Pick a second that was rejected or took the exception path, because auditors often ask what happens when the answer is no. Gather the records in advance and open them in tabs in order.
Be ready to say who owns each step. Control owners should be able to describe their own part without reading a script. Our checklist on control owner assignment for audits helps.
The script
| Step | What you say | What you show |
|---|---|---|
| 1. Request | A developer files a request with purpose and version | The ticket, with date and requester |
| 2. Automated checks | Scans run on the package and its transitive packages | Scan output attached to the ticket |
| 3. Review | A reviewer other than the requester reads the results | Reviewer notes with name and date |
| 4. Approval | The decision is recorded and the approved list updated | The list entry linking to the ticket |
| 5. Mirror | Only approved versions are served to builds | The mirror configuration and the entry for this version |
| 6. Build | The pull request that added the package passed the gate | The pull request, gate result and merge approval |
| 7. Release | The change was deployed under a change ticket | Change ticket with deployment time |
| 8. Monitoring | The package is rescanned continuously | A later scan result and the next review date |
Answers to prepare
Auditors tend to probe the same few places:
- What stops someone bypassing this? Show the egress rule or mirror enforcement and describe how you test it.
- Who can approve their own request? Show that the system or policy blocks it.
- What about urgent fixes? Show the emergency path and one example with its after-the-fact review.
- How do you know the list is complete? Show a reconciliation of the inventory against the approved list.
- What happens when a new vulnerability appears? Show monitoring and a ticket opened from it.
Answer with what you do, not with what you plan to do. If something is in progress, say so plainly and give a date you control.
Handling gaps
If the walkthrough exposes a gap, note it, agree an owner and move on. Pretending a gap does not exist is how a minor finding becomes a credibility problem. NIST SP 800-218 practice PW.4.1 expects organisations to acquire and maintain well-secured third-party components, and the walkthrough is your chance to show how that is operated, not just written.
After the session
Send the auditor a short follow-up list of the records you showed, with IDs, so they can sample later. Keep your own copy. Update your process notes with any lesson.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a technical record maps to a framework control.
Quick check
Should I show the rejected package too?
Yes. A rejected or excepted example proves the gate can say no, which a clean example cannot.
Can I demo this live?
You can, but prepare screenshots or exports as a fallback and make sure no sensitive data is on screen.
Safeguard compliance and evidence automation can collect several of these records in one place. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
