Attach one artifact per claim: the policy text, a sample inventory, a license report, a remediation record and an end of life decision log. Redact internal names, date every item and keep copies so the same evidence answers the next questionnaire.
Claims and evidence
A questionnaire answer that says "we maintain an inventory" invites a follow up. An answer that says "we maintain an inventory, sample attached" often closes the thread. NIST SP 800-218 is written around practices a producer can demonstrate, and the open source ones sit under PW.4 and RV.1 and RV.2.
| Claim | Evidence | Redact |
|---|---|---|
| Written policy | Policy summary with review date | Internal system names |
| Component inventory | Sample SBOM for one release | Private package names |
| License review | License field export and policy table | Customer specific notes |
| Vulnerability handling | Two or three ticket histories | Internal usernames |
| Update process | Merge history of dependency updates | Repository paths |
| End of life handling | Decision log for retired components | Vendor negotiations |
Make evidence repeatable
Keep a folder, owned by one role, with the current version of each item and its date. Refresh on a schedule so it never goes stale. When a questionnaire arrives, you assemble rather than invent.
If you maintain a trust page, link public items there, such as your policy summary. See anatomy of a trust center.
Evidence quality rules
- Dated. Undated evidence reads as old.
- Specific. One real example beats a generic screenshot.
- Consistent. Numbers must match across documents and answers.
- Proportionate. Do not send more than asked.
Be careful with attestation language. If a report or audit is in progress, say it is in progress. Do not describe it as complete or imply a certification that you do not hold.
When evidence does not exist
Say so, give the plan and date, and describe the practice you follow today. A credible gap statement is better than a stretched claim. The related post on replying when a customer asks for SOC 2 before you are ready shows similar wording.
Handling confidentiality
Not every customer should see every artifact. Keep two tiers: a public tier such as a policy summary and the general description of your process, and a restricted tier such as sample SBOMs and ticket histories shared under agreed terms. Decide in advance who may release the restricted tier, so replies do not stall while people debate it.
Log what was sent, to whom and when. If the same evidence is requested again six months later, you will know whether it needs refreshing.
Try it yourself
Click through it at your own pace, or open it full screen.
See how one piece of evidence can map to several framework controls. Reuse is the point.
Safeguard offers compliance and evidence automation to collect and map such artifacts.
Quick check
Should evidence be sent as a file or shown live?
Either works. A screen share protects detail, while a redacted file lets the customer review later.
How current must the evidence be?
Recent enough that the customer believes it reflects today. Quarterly refresh is a common rhythm.
Sources
Last reviewed: 19 October 2026.
