A supply chain evidence pack is a small, dated folder that proves the statements in your questionnaire answers. Include a dependency inventory, a recent scan report, your patching rule, branch and review settings, a vendor list and an index that points each claim to a file.
The folder layout
Keep it boring and predictable. One folder, one index, numbered files.
| File | What it shows | Refresh rhythm |
|---|---|---|
| 00-index | Each claim mapped to a file | Whenever a file changes |
| 01-inventory | Dependencies per production repo | Every release or monthly |
| 02-scan-report | Vulnerability scan results and open items | Monthly |
| 03-patching-rule | One page rule and a few closed tickets | Yearly or on change |
| 04-change-controls | Branch protection and review settings | Quarterly |
| 05-ci-settings | Pipeline permissions and who can edit workflows | Quarterly |
| 06-vendors | Vendor and subprocessor table | Quarterly |
Why the index matters most
Reviewers do not read every file. They look for the line that matches the question they are on. An index with sentences such as "We scan dependencies on each pull request: see 02" saves a round of emails and makes the pack feel owned rather than assembled in a panic.
Write each index line as a claim you can defend. If you cannot point to a file, either collect the evidence or drop the claim.
Dates, versions and scope
Every file needs a date and a scope: which repositories, which environments. A scan report with no date is nearly useless. Note what is out of scope, for example internal tools or an acquired product, so no one assumes coverage you do not have.
Keep older versions in an archive subfolder. If a customer asks what you said last year, you can answer from the record instead of memory.
What to leave out
- Raw exports that contain customer data, secrets in configuration, or internal hostnames. Redact before sharing.
- Marketing language. Evidence should be plain.
- Anything that implies an audit result you do not hold. Never label the pack with a certification or attestation name unless an independent party has issued that report.
- Findings with no owner. Add an owner and a date before the file goes out.
Sharing it safely
Send it through a controlled channel such as a shared link with expiry, and log who received it. If a customer asks for more than you can share under your own confidentiality rules, say that and offer a call with someone who can describe the control. That is a normal answer.
For a systems view of the NIST development practices many reviewers use as a reference point, see the Secure Software Development Framework publication, which describes a core set of high level practices that producers can add to their own development process.
Try it yourself
Open the continuous monitoring demo and look at how results are refreshed over time. A pack that refreshes itself is easier to keep honest than one rebuilt by hand before each deal.
Click through it at your own pace, or open it full screen.
Safeguard's compliance and evidence automation can collect scan results and change records into dated exports, and the free scan at https://gold.safeguard.sh/scan gives you a first baseline file.
Quick check
How big should the pack be?
Small enough that one person can refresh it in an afternoon. Six or seven files is typical.
Should we send the whole pack unprompted?
Send what answers the questions asked. Offer the rest on request.
Can screenshots count as evidence?
Yes if dated and scoped, but exports from the system of record are stronger because they are harder to dispute.
Sources
Last reviewed: 19 October 2026.
