Run a mock buyer review by asking a colleague outside the engineering team to request evidence for each SSDF practice group, and time how long each answer takes. Anything you cannot produce in about five minutes, or that contradicts what you claimed, goes on a gap list with an owner.
Why do a dry run
Evidence that exists is not the same as evidence you can find. A real buyer review often arrives with a deadline and a long list. Practicing once shows where the index is wrong, who is the one person who knows where a file lives, and which claims the artifacts do not support.
Set it up
- Pick a reviewer who did not build the evidence. Someone from sales engineering, finance or another team works well.
- Give them the four practice groups from NIST SP 800-218: prepare, protect, produce and respond.
- Ask them to choose three tasks from each group at random.
- Book three hours and a quiet room.
Script for each task
| Step | Ask | Record |
|---|---|---|
| 1 | What do you do for this task? | Time to a clear answer |
| 2 | Show me the policy | Found, missing or out of date |
| 3 | Show me it working on real work | Link or file, with date |
| 4 | Who owns it? | Name, and whether they agree |
| 5 | When was it last reviewed? | Date |
Keep the pace brisk. The five minute limit is a guide, not a rule.
What to watch for
- Answers that differ from the written policy
- Evidence older than your review cycle
- Owners who are surprised to be named
- Artifacts that contain customer data and need redaction
- Claims in marketing copy that go beyond what the artifacts show
On that last point, compare your public wording with your evidence. NIST describes recommended practices, so avoid wording that sounds like a certificate when none exists.
After the session
- List every gap with an owner and a date.
- Fix the index first, since that is the cheapest improvement.
- Update policies that no longer match reality.
- Repeat the exercise in six months with a different reviewer and different tasks.
Keep the notes
The notes from a dry run are evidence in their own right for the continuous improvement theme in the SSDF. In RV.3.4, NIST asks you to review the SDLC process and update it if appropriate, and a record of exercises and fixes fits that task.
Make it a habit
One dry run helps. A recurring one changes behavior. Put it on the calendar twice a year and rotate the reviewer. Track the number of gaps found and the time to produce evidence, and expect both to improve. If they do not, the index is probably not being kept current. Share the results with leadership as a short note, which also supports the commitment theme in PO.2.3.
Quick check
Who should be the mock reviewer?
A person who is not on the engineering team and has not seen the evidence before, so they ask naive questions.
What if we find big gaps?
Write them down plainly and fix in order of buyer impact. Do not paper over them with new documents that do not reflect real work.
Safeguard's compliance and evidence automation can keep records current between reviews. 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.
