Evidence Library Guide

What Counts as Evidence

An evidence artifact is anything that allows an assessor to confirm that a control is implemented as the SSP describes. Evidence answers questions an assessor cannot answer from the SSP alone: Is this actually happening? At the cadence the SSP claims? Across the systems the SSP scopes? With the rigor the requirement demands?

NIST SP 800-171A — the assessment companion to 800-171 Rev 2 — defines three assessment objectives for every requirement: examine (review documents and configurations), interview (talk to people who perform the work), and test (observe the control in action). Evidence supports the examine and test objectives. The interview objective is supported by personnel who can describe what they do — but their description must be backed by examinable artifacts.

Evidence is not a paperwork exercise. It is the record of operational practice. A configuration screenshot evidences a configuration; a quarterly access review record evidences an access review; an audit log sample evidences logging coverage. The artifact must reflect what is actually true in the environment at the time the assessor reviews it.

Evidence Categories

Most evidence falls into one of seven categories. Building the library means having artifacts in each category, mapped to specific requirements.

• Policy and procedure documents. The written rules. Cross-reference each policy to the requirements it supports. See the policy library guide.
• Configuration screenshots and exports. Evidence that a system is configured as the SSP describes. Examples: Group Policy Object exports showing password policy enforcement, firewall rule listings, conditional access policy screenshots, audit log retention configuration.
• System-generated reports. Reports the in-scope systems produce automatically — vulnerability scan reports, patch compliance reports, MFA enrollment reports, antivirus update reports, audit log summary reports.
• Records of periodic activities. Artifacts showing that a recurring activity actually recurred. Examples: quarterly access review records (with dates and reviewer signatures), annual SSP review records, monthly vulnerability scan summaries, weekly audit log review sign-offs.
• Training and awareness records. Completion records for required training, with dates, topic, and personnel. Often pulled from a learning management system.
• Change records. Tickets or change requests showing security review of significant changes — new system additions, configuration changes, software approvals, user access provisioning, equipment disposal.
• Incident records. Documented security incidents (real or tabletop), the response taken, and the lessons-learned outcome. Even an organization with no real incidents should have tabletop exercise records demonstrating the IR plan is exercised.

The Freshness Question

Every evidence artifact has an implicit shelf life. Assessors look at the date on the evidence and ask: does this prove the control is currently effective? A vulnerability scan report from two years ago demonstrates that a scan once happened — it does not demonstrate that scanning is currently part of operational practice.

The freshness question is the simplest evidence flaw to fix and the most common to fail. Before any assessment, walk through every evidence artifact and confirm it is current. Stale evidence in an evidence package signals to assessors that the control is not actively maintained — even if it is.

Evidence by Control Family

The breakdown below describes the evidence patterns assessors typically expect for each of the 14 control families. This is a starting point — the specific evidence will vary based on your environment, but the categories should map closely.

Organizing the Package

An evidence package is a navigable, indexed collection — not a folder of dumped files. A well-organized package speeds the assessment, reduces back-and-forth, and signals discipline to the assessor team.

• Folder per family. Top-level folders organized by the 14 NIST families (3.1 AC, 3.2 AT, etc.). Within each, subfolders by requirement (3.1.1, 3.1.2, etc.) or by evidence type.
• Index document. A spreadsheet or document mapping each of the 110 requirements to the specific evidence artifact(s) supporting it. This is the cross-reference assessors actually use during fieldwork.
• Naming conventions. Date-stamped filenames (YYYY-MM-DD prefix) for time-sensitive evidence. Descriptive names (not "Document1.pdf") for ad-hoc artifacts.
• Evidence collection date. Each artifact should clearly indicate when it was generated or captured. For configuration screenshots, this means the date in the filename plus a date visible in the screenshot.
• Excluded evidence. Items collected but determined not to be useful as evidence — keep in a separate "rejected" folder rather than mixed with the active package.
• Access control on the package. The evidence package itself contains sensitive information about your security posture — restrict access appropriately, encrypt at rest, and version-control changes.

A common organizational pattern is to use the SSP's outline as the spine: each control implementation statement in the SSP includes a footnote or reference pointing to the specific evidence file(s) that support it. The evidence index then provides the mapping.

Common Mistakes

• Document-only evidence. An evidence package consisting entirely of policies and procedures — no configurations, no activity records — proves intent but not implementation. Add the configuration and activity evidence.
• Stale artifacts. Already covered above; the most common single failure mode. Audit freshness before assessment.
• Evidence that doesn't match the SSP. The SSP says quarterly access reviews; the evidence package contains an access review record from 14 months ago. Either the SSP or the operational practice needs to change.
• Missing the high-weight controls. The 5-point and 3-point requirements in the DoD Assessment Methodology receive disproportionate scrutiny. Confirm that high-weight controls have especially complete evidence.
• Unredacted PII. Evidence containing PII (training records with employee names, screenshots showing user accounts) should be appropriately handled. Some C3PAOs prefer redacted samples; check before sending.
• Configuration screenshots without context. A screenshot of a Group Policy setting with no annotation showing what GPO it's from, what OU it applies to, when the screenshot was captured, is hard to interpret. Annotate or include source metadata.
• Evidence stored only on individual workstations. Evidence on the ISSO's laptop that no one else can produce when the ISSO is unavailable creates fragility. Centralize in a controlled repository.
• Mock or fabricated evidence. Forging evidence — backdating documents, fabricating training completion records, doctoring screenshots — is the most serious failure possible. It is also a False Claims Act exposure for the senior official affirming the SPRS posting. Walk away from any consultant or staff member who suggests it.

Authoritative References