Tool-generated records beat hand-made ones. Pipeline logs and exported settings with timestamps are harder to dispute than screenshots, and a screenshot beats a bare statement. Choose the form that shows the control working on real work, is dated, and can be reproduced on request.
Why form matters
NIST's PO.3.3 asks you to configure tools to generate artifacts supporting your secure development practices, and defines an artifact as a piece of evidence. Its examples include using existing tooling to build an audit trail, deciding how often to audit the collected information, and setting security and retention policies for artifact data. The message is to let systems produce evidence as a by-product of work.
Comparing the forms
| Form | Strength | Weakness |
|---|---|---|
| Tool log or run record | Generated automatically, timestamped | Can be noisy, needs context |
| Settings export | Shows exact configuration | Shows state at one moment |
| Ticket or review history | Shows the process on real work | Needs redaction |
| Screenshot | Quick and readable | Easy to question, goes stale |
| Written statement | Explains intent | Proves nothing alone |
Use more than one form for important practices. A branch protection export plus a merged pull request showing the required approval tells a stronger story than either alone.
Rules of thumb
- Date everything. Include the capture date in the filename or the export itself.
- Show a sample, not a pile. Three representative items beat three hundred.
- Redact customer data. Remove names and secrets before sharing.
- Say how it was produced. A line such as "exported from the repository settings page on this date" lets a reader trust it.
- Keep a way to regenerate. If a reviewer asks for a fresh copy, you can produce it in minutes.
When a screenshot is fine
A screenshot suits a setting that the tool cannot export, or a quick illustration inside a document. Add the date and the page address visible in the capture. If the setting matters a lot, find an export or API call that returns the same data.
What not to do
Do not edit evidence to make it look cleaner, and do not backdate files. A reviewer who spots a reworked log loses trust in everything else you supplied.
Retention
Decide how long each kind of record is kept and apply it consistently. NIST's PO.1.2 examples tie release archive retention to the SDLC model, software end of life and other factors.
An example
Say a buyer asks how you ensure code is reviewed. A strong answer pairs three things: the repository setting that requires approval, exported on a stated date; two recent merged changes showing the approval; and the policy sentence that explains the rule. Each item alone is open to challenge. Together they show a rule, its enforcement and its use. Aim for that triangle on your most important practices.
Quick check
Is a screenshot ever acceptable evidence?
Yes, as supporting material. It is stronger when dated and paired with a log, export or ticket showing the same control in use.
How many samples should we show?
Enough to show a pattern across time, often a handful per practice. State how you picked them.
Safeguard's compliance and evidence automation is built around producing records as checks run. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
