A good proof request quotes the claim, says what evidence would satisfy you, names the format and sets a reply date. It is short, specific and polite. Vague requests such as "please send your security documentation" invite generic answers, while precise ones get precise evidence or an honest admission that none exists.
The parts of a proof request
- The claim, quoted. Cite the page, deck slide or call date. Quoting avoids drift.
- Why it matters. One sentence tying the claim to your requirement.
- The evidence you accept. Name the forms: a document, a live test, a log extract, a reference conversation.
- The format. Say how you will use the answer, for example "exportable file" or "live on our repository".
- The date. A reasonable deadline, so silence is also an answer.
- The fallback. Say what happens if proof is not available: you will treat the claim as unverified.
A template
Subject: Evidence request, claim from [date]
Hello [name],
On [date], [person] stated that "[exact claim]". This matters to us because [requirement].
To count this in our evaluation we would like one of the following: [option one, option two, option three]. A file we can keep, or a live demonstration on one of our repositories, works well.
Could you reply by [date]? If this is not currently possible, please say so, and we will record it as not yet verified. That is fine, and it helps us compare fairly.
Thank you, [name]
Keep the tone neutral. You are not accusing anyone.
Examples of claims and acceptable evidence
| Claim | Evidence worth asking for |
|---|---|
| "We analyse reachability" | A live run on your repository, showing the call path for three findings |
| "We never store your source code" | The data flow description, retention settings and the contract clause |
| "We report new issues quickly" | Timestamps for recent advisories, from publication to detection |
| "Our fixes are safe to merge" | Fix examples with test results, and how failures are handled |
| "We support our own SBOM generation" | A sample file in a standard format, validated with a tool you choose |
What to do with the answer
Log it in your ledger. If the vendor supplies evidence, check it for what it actually shows. A certificate for one product does not cover another. A test on a toy project does not show scale. If they decline, record that plainly and let the weight of the claim fall accordingly.
Timing and tone
Send the request early, ideally within a few days of the claim, while the context is fresh. Address it to the person who made the claim and copy your own evaluation lead. Keep one thread per request so the record stays clean. If a reply is vague, answer politely with one narrower question rather than a longer list.
Where Safeguard fits
Send the same request to Safeguard that you send to anyone. You can also collect your own evidence first with the free scan at gold.safeguard.sh/scan, so your questions are based on what you saw.
Quick check
Is a proof request rude?
No. Vendors in security expect it. A precise, polite request usually earns respect.
How many claims should one request cover?
Three to five that would change your decision. More than that and replies get shallow.
Last reviewed: 19 October 2026.
