Evidence Checklists

Why It Matters

Most device controls answer themselves. Your MDM reports disk encryption, your identity provider reports MFA, and the compliance platform pulls both on a schedule. Then the auditor asks about the four contractors, the designer on a personal laptop, and the advisor who has never been in scope for the agent — and the automation has nothing to say.

That gap is usually closed with a spreadsheet and a folder of screenshots in shared storage. It works until someone asks who confirmed a given control, when the screenshot was taken, and whether it still applied during the audit window. By then the answer is buried in a chat thread.

An evidence checklist is a training program whose content is a set of device settings rather than slides. The participant gets step-by-step instructions for their own operating system, changes the setting, uploads proof, and signs the same legally-worded attestation your other training uses. What comes out the other side is a completion record an auditor accepts.

Checklists vs. Courses

Both are training programs and both end in a signed attestation. The difference is what sits in the middle.

	Course	Checklist
Content	Slides, then a knowledge check	Checkpoints, each with per-platform instructions
Proves	They understood the material	Their machine is configured a particular way
Completion	Every slide viewed, quiz passed, attestation signed	Every checkpoint confirmed, attestation signed
Evidence	The completion record	The completion record plus uploaded screenshots

A program is one or the other, decided by the template you seed it from. Everything else — invitations, deadlines, reminders, the completion register, the Vanta export — works identically for both.

The Two Checklist Decks

Endpoint Hardening

The seven device settings an auditor asks a contractor to prove:

Checkpoint	Evidence
Full-disk encryption — FileVault, BitLocker, or LUKS	Screenshot
Screen lock with password on wake	Screenshot
Automatic OS updates enabled	Screenshot
Malware protection running	Screenshot
Password manager in use	Screenshot
Firewall enabled	Screenshot
Device password meets policy	Attestation only

Device password is attest-only on purpose: no settings pane displays your password’s length, so a screenshot would prove nothing.

Malware protection is the one checkpoint that does not claim parity across platforms. On Linux the instruction says plainly that a desktop with no on-access scanner is a normal answer, and asks the participant to capture the compensating controls — automatic patching and a default-deny host firewall — and to state that in their note. Fake parity would make the evidence worse, not better.

Two values are asked as template questions rather than hardcoded, because the three major compliance platforms disagree and your own policy is the one that governs:

• Screen-lock timeout, default 15 minutes. Vanta accepts up to 60, Drata wants a password 60 seconds after a 15-minute lock, Secureframe checks for 900 seconds or less.
• Minimum password length, default 8.

Policy Acknowledgment

All 22 SOC 2 policies as attest-only checkpoints, grouped so they read in coherent runs rather than as one flat list: conduct, information security, data, resilience, and governance. Each links to wherever your policies live, and the signed attestation enumerates every policy by name — a blanket “I have read the policies” signature does not survive a question about which ones.

Building a Checklist

1. Seed it. From the Training dashboard, click Build from template and pick Endpoint Hardening or Policy Acknowledgment. Answer the smart-template questions — your company name, your password manager, your screen-lock timeout.
2. Review the checkpoints. Each has a title, a “why this matters” note the participant reads, capture rules, and instructions per operating system. Edit any of them, add your own, or reorder.
3. Add instructions for platforms you need. The shipped decks cover macOS, Windows 11, and Linux. The Linux steps are written differently on purpose: rather than a click path through a desktop environment we do not know, they name the control and give a distro-agnostic command whose output is the screenshot — lsblk showing a LUKS crypt device, systemctl list-timers showing the update timer, ufw status verbose showing default-deny. A terminal capture is better evidence than a settings pane anyway. A participant on a platform with no instructions of its own still falls back to the first authored one rather than seeing a blank card, and the runner says outright which platform’s steps they are reading.
4. Publish and invite. Identical to a course. A checklist will not publish without at least one checkpoint and an attestation.

What the Participant Sees

One page, one open card at a time. Kit guesses their operating system from the browser and shows the matching instructions; they can switch, and the choice sticks.

Each card carries the numbered steps, the reason the control matters, and the capture rules. They take a screenshot, drop or paste it onto the card, name the device, and date the capture. Confirming collapses the card and opens the next.

Capture attribution is typed, not photographed. Rather than requiring the machine name in the screenshot, Kit asks for the device label and capture date as fields. Those are encrypted, they are searchable, and they survive after the image itself is deleted.

The microcopy tells them to silence notifications before capturing and to screenshot the settings pane rather than photograph the screen with a phone. Both are the top reasons an auditor rejects evidence.

Reviewing Evidence

Submitting completes the checkpoint. Review is triage afterwards, not a gate — a contractor is not left waiting on someone’s inbox.

The queue lists confirmed but unreviewed submissions with the attribution that makes a screenshot auditable: platform, device label, capture date, and how many days before confirmation it was taken. Backdated evidence is stated outright, since that is the thing a reviewer is looking for.

Accepting clears the item. Rejecting requires a note, reopens the checkpoint, and emails the participant with your reason. It does not revoke their completion record — they did complete the training, and rewriting that would be falsifying history rather than asking for a better screenshot.

Reopening is real access, not just a status: the runner stays reachable for someone who has already finished, showing your note on the one card they need to recapture. Their new screenshot returns the checkpoint to the review queue as a fresh claim. The evidence they submitted before your review stays attached and cannot be deleted — that is the record an auditor asks about — so it is shown alongside the replacement, marked superseded.

Rejected evidence does change the register: that person stops counting as green and moves to the Evidence rejected stage, ranked above everything else. The count of completed people is what you hand an auditor, so it excludes anyone with outstanding evidence.

Access and Retention

Only training admins of the account can see evidence, and every download is logged with who opened which file and when. Files are served through short-lived links minted per click rather than URLs embedded in the page, so access ends when the person’s access ends.

Evidence is deleted on a schedule. Each program has a retention window, 395 days by default — a year plus the margin a Type II audit window needs. A nightly sweep deletes the files once a submission passes it. Set a different window per program with evidence_retention_days on training_create_program.

The completion record survives the deletion, and so do each file’s name and content hash. After the screenshots are gone you can still prove what was submitted, when, by whom, and that it was not swapped for something else.

Exporting

The Vanta CSV export gains evidence columns for checklist programs: review state, checkpoints confirmed, total checkpoints, file count, device label, and the capture window. Course exports are unchanged, down to the byte — Vanta matches on exact column order and wording.

The PDF register adds a separate checkpoint-evidence table below the main one.

One Person, One File

The register exports cover everyone at once. When an auditor asks about a single person, use Evidence bundle on that person’s row instead. It builds a ZIP in the background and the download starts as soon as it is ready.

Inside is everything on record for them, renamed so the folder is readable without you standing next to it:

training-evidence-jane-doe-endpoint-hardening-20260114.zip
└── jane-doe-endpoint-hardening-20260114/
    ├── jane-doe-00-manifest.csv
    ├── jane-doe-01-certificate.pdf
    ├── jane-doe-checkpoint-01-full-disk-encryption-01.png
    ├── jane-doe-checkpoint-02-screen-lock-01.png
    └── jane-doe-checkpoint-02-screen-lock-02-superseded.png

The manifest is the part an auditor actually reads: one row per file with the platform, device label, capture date, confirmation date, reviewer verdict and review note, plus each file’s original name and content hash. A folder of screenshots without it is unreadable to anyone who was not there.

Two states are labelled rather than hidden. Evidence submitted before a reviewer’s verdict is included with -superseded in the name, because leaving it out hides the trail and including it unmarked implies it was accepted. Files already deleted by retention appear as a small .purged.txt note in the exact place the screenshot would have been, carrying the retained filename and hash — a bundle that quietly omitted them would misrepresent the record.

Course participants have no screenshots, so their bundle is the certificate and manifest alone; the button says Certificate bundle rather than promising evidence that never existed.

Bundles expire after seven days, and every download is recorded — who took the archive and when, plus a per-file entry in the same evidence trail a single-file download writes, so “who has ever seen this person’s screenshots?” has one complete answer.

Reminders

Checklists use the same drip as courses: a nudge after the invitation, a last call as the deadline approaches, a sign-off nudge for anyone who finished the content but never signed, and a past-due reminder capped at three sends a week apart.