A trial evidence log is one shared document where you record, each week, what you tested, what happened, how long it took, which limits you hit and what the vendor told you. It turns opinions into facts, and it lets someone who missed the trial still understand the decision.
Why keep one
Memory is a poor record. By week four, nobody recalls which findings were false positives or which promise was made on the kickoff call. A short log, updated twice a week, fixes that and takes about ten minutes each time.
The six sections
1. Setup record
What you installed, who did it, how long it took and which documentation you followed. Note every step that was not in the documentation.
2. Finding triage
For each finding you review, record the verdict and the reason.
| Finding | Verdict | Reason | Time to judge |
|---|---|---|---|
| Library X, issue Y | True positive, reachable | Code path called in service A | 8 min |
| Library Z, issue W | False positive | Function never imported | 5 min |
| Config warning | Useful, low priority | Real but cosmetic | 2 min |
Use the same verdict categories every time: true positive, false positive, true but not exploitable here, duplicate, unclear.
3. Developer feedback
Short quotes or notes from developers, dated. Record friction ("scan added four minutes to the build") as well as praise. If a developer ignored a finding, record why.
4. Limits and surprises
Anything that behaved differently from what you were told: limits, missing features, delays, error messages. These often matter more than the headline results.
5. Vendor answers
Questions you asked, who answered, when, and whether the answer was backed by documentation. Keep screenshots or copied text for important ones.
6. Hours
Your hours and the vendor's hours, by task. See how to stop a trial becoming free consulting.
Weekly rhythm
| Day | Action |
|---|---|
| Monday | Review last week, set this week's tests |
| Wednesday | Add triage results and developer notes |
| Friday | Summarise: what we learned, what is open, what the vendor owes us |
Make it usable later
- Date every entry and sign it with initials.
- Link, rather than paste, large exports. Store exports in a folder with the same dates.
- Mark entries that came from the vendor, so you can separate claims from measurements.
- Freeze the log on the last day and attach it to the decision record.
What the log gives you at the end
The log feeds the wrap up scorecard directly: accuracy comes from section 2, usability from section 3, fit from section 4, effort from section 6. If a stakeholder asks "why did we choose this", you can point to dated evidence. If you buy, the log also becomes the starting checklist for rollout, because every workaround you recorded is something to fix before production.
Safeguard's free scan results can be saved as the first entry in the log, so you have a starting snapshot dated to day one.
Try it yourself
Click through the demo and imagine you were triaging each finding. Practise using the verdict categories above on what you see.
Click through it at your own pace, or open it full screen.
Quick check
Does the log need special software?
No. A shared document and a spreadsheet are enough. What matters is dating entries and keeping the verdict categories consistent.
Who should own the log?
The trial lead owns it, and the triager and developers add their own entries.
Last reviewed: 19 October 2026.
