Keep a small, consistent record for every intake decision: the request, the checks run with their results, the decision and decider, the date, and the hash of what was approved. Add periodic summaries of exceptions and queue performance. Produce these as a by-product of the pipeline, not by hand.
Why evidence matters
An auditor, a customer or your own incident team will eventually ask the same questions. How do you decide which open source goes into your product? Show me an example. What happens when a package turns out to be bad? A process that cannot show its own records will be judged on its description alone.
This post describes record keeping, not a certification. What a specific audit or framework needs depends on its scope and the auditor, so confirm with them.
The per-decision record
| Field | Why it is needed |
|---|---|
| Request ID and requester | Shows accountability |
| Package, version and source | Identifies what was reviewed |
| File hash | Ties the decision to the exact artifact |
| Checks run and versions of the tools | Shows what was examined |
| Check results | Shows why the decision followed |
| Decision and decider or rule version | Shows who or what approved |
| Timestamp | Orders events |
| Exception link, if any | Connects to accepted risk |
If the pipeline writes this automatically, the record is cheap and consistent.
The periodic summaries
- Exceptions register. Each exception with owner, reason, expiry and status.
- Queue performance. Time to decision and oldest open request, as described in the intake metrics post.
- Policy changes. A log of changes to rules, with approvals, ideally from version control history.
- Incident handling. For each malicious or revoked package, the timeline of detection, blocking and cleanup.
- Sample reviews. Results of the monthly spot checks of auto-approved changes.
Where to store it
- Records that belong to a change (a pull request) can live in that pull request and its checks.
- Policy lives in version control, with reviews required.
- Registers and summaries go in a place with access control and retention rules you can state.
Consistency matters more than the tool. Choose a retention period that matches your obligations and write it down.
What to avoid
- Screenshots of dashboards as the only record. They cannot be queried or verified.
- Evidence created after the fact to match an audit request.
- Claims in a questionnaire that outrun the records. If you cannot show it, describe it as planned.
Trace to a framework only when needed
If a customer asks how intake maps to a control in a framework such as NIST SSDF, answer from your records: here is the policy, here is a sample decision, here is the exception register. NIST describes the SSDF as a core set of high-level secure software development practices that can be integrated into any development lifecycle, and that it provides a common vocabulary for purchasers and suppliers, so use it as a vocabulary for the conversation.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single piece of evidence is linked to more than one framework requirement, which is how a lean record set can serve several audiences.
Where Safeguard fits
Safeguard's compliance and evidence automation collects records from scans, policies and gates so they are available when asked. Start with the free scan.
Quick check
How long should intake records be kept?
Match your contractual and regulatory obligations, and the lifetime of the software you ship. Write the period down.
Is an intake record a compliance certificate?
No. It is evidence that a control operated. Attestations and certifications come from independent assessors.
Sources
Last reviewed: 19 October 2026.
