An evidence package is the organized set of artifacts that proves each NIST SP 800-171 requirement is implemented. It is different from a readiness checklist. The CMMC compliance checklist asks whether you have done the work; this page lists what you hand an assessor to prove it, at the level the assessor tests.
Use it to build a single indexed repository — a folder structure or a GRC tool — where every objective points to named artifacts with an owner and a date. Packages built this way survive staff turnover, prime contractor questionnaires and DIBCAC reviews alike.
The five anchor artifacts
Every other piece of evidence refers back to these. If any of them is missing or out of date, assessors will discount the rest.
- System Security Plan (3.12.4) describing the boundary, the environment and how each requirement is met. Without it an assessment cannot be completed at all.
- Plan of Action and Milestones (3.12.2) listing open gaps, owners, milestones and target dates, limited to items that are lawfully deferrable.
- Asset inventory (3.4.1) covering hardware, software and firmware, with each asset assigned to a CMMC asset category.
- Network and boundary diagram (3.13.1) showing external and key internal boundaries, enclaves and managed access control points.
- CUI data flow showing where CUI enters, where it is stored, processed and transmitted, and where it leaves.
Evidence by assessment method
Assessors use three methods from NIST SP 800-171A. Organizing evidence the same way tells you quickly where you are thin.
| Method | What it means | Typical evidence |
|---|---|---|
| Examine | Review of documents, settings and records | Policies, procedures, configuration exports, screenshots with dates, logs, tickets, training records, visitor logs |
| Interview | Discussion with the people who own or operate the control | Named control owners, a brief per owner, consistency with the SSP |
| Test | Observing the mechanism working | Live MFA prompt, blocked USB device, account lockout after failed attempts, alert firing on a test event |
Family-by-family checklist
Representative artifacts per family. Each line should be linked in your index to the objective it satisfies.
| Family | Evidence to have ready |
|---|---|
| Access Control (AC) | Account list with roles, access approval records, least-privilege review, session lock and lockout settings, remote access and wireless configuration |
| Awareness & Training (AT) | Training content, completion records by person and date, role-based training for administrators, insider-threat module |
| Audit & Accountability (AU) | Defined list of logged events, log retention settings, SIEM or review records, alert on logging failure, time synchronization source |
| Configuration Management (CM) | Baseline configurations, inventory, change tickets with security impact analysis, application allowlist or denylist, disabled ports and services |
| Identification & Authentication (IA) | MFA configuration for privileged and network access, password policy, identifier reuse and inactivity settings, replay-resistant protocols |
| Incident Response (IR) | IR plan, incident tickets, DoD reporting procedure for 72-hour reporting, records of an exercised test |
| Maintenance (MA) | Maintenance logs, approved tools, sanitization records for off-site repair, MFA on remote maintenance, escort records |
| Media Protection (MP) | Media inventory, CUI marking on media, sanitization certificates, removable-media control settings, backup encryption |
| Personnel Security (PS) | Screening records, termination and transfer checklists with timestamps for access removal |
| Physical Protection (PE) | Badge system access lists, visitor logs, escort procedure, physical access device inventory, alternate work site guidance |
| Risk Assessment (RA) | Dated risk assessment, vulnerability scan reports, remediation tickets tied to scan findings |
| Security Assessment (CA) | SSP, POA&M, records of periodic control assessment and continuous monitoring |
| System & Comms Protection (SC) | Firewall rules showing deny-by-default, FIPS 140 module certificate numbers, encryption at rest and in transit, split-tunnel settings |
| System & Info Integrity (SI) | Patch reports with remediation timelines, anti-malware status, advisory monitoring, network monitoring alerts |
Freshness, ownership and naming
Evidence goes stale. A vulnerability scan from last year does not prove that 3.11.2 is operating, and a screenshot without a date proves very little. Record for every artifact the date it was produced, the next date it must be refreshed, and the person responsible. Name files with the requirement and objective they support, for example "3.5.3[a] MFA privileged accounts 2026-09.pdf", so that an assessor's request can be answered in seconds.
Keep the package inside your CUI boundary if any artifact contains CUI, and keep it under change control. The assessment preparation service uses this package as the input to a mock assessment, and the SSP template shows how the plan should reference it.
Common evidence mistakes
- Policies submitted as evidence that a technical control is operating.
- FIPS-capable products listed without the CMVP certificate number or proof that FIPS mode is enabled.
- MFA evidence for user accounts only, with privileged and service accounts left out.
- Logs collected but no record that anyone reviews them.
- An incident response plan with no record of a test.
- Inventory that lists hardware but not software or firmware.
Frequently asked questions
How is an evidence package different from the SSP?
The SSP describes how each requirement is met. The evidence package proves it. Each SSP statement should point to the artifacts in the package that support it.
Do we need evidence for every one of the 320 objectives?
Yes. A requirement is MET only when all of its objectives are met, so an objective with no evidence will usually make the whole requirement NOT MET.
Can we store evidence in a commercial file-sharing service?
Only if nothing in it is CUI, or if the service meets the DFARS 252.204-7012 cloud requirement of FedRAMP Moderate or equivalent. Configuration exports and diagrams often reveal enough to warrant protection either way.