CMMC Evidence Package: The Documentation Requirements Assessors Actually Evaluate

The C3PAO arrives on day one with the CMMC Assessment Guide Level 2—a list of 320 objectives, each requiring documentation, personnel interviews, and system tests. Your evidence package is what turns each of those determinations from “Not Met” to “Met.” Most assessment failures in the first CMMC cycle are not security failures. They are evidence failures: controls that are actually implemented but can’t survive the examine–interview–test sequence because the documentation is incomplete, outdated, or missing a specific artifact the assessor expected to see.

This guide covers what goes into an evidence package, the quality standard each document needs to meet, and what assessors reject most often.

How Assessors Use Evidence

The CMMC Assessment Guide Level 2 defines three assessment methods drawn from NIST SP 800-171 Rev 2, and a control is only marked Met when all three are consistent:

• Examine: The assessor reviews documentation—SSP sections, policies, network diagrams, configuration screenshots, log samples, training records. This is where most organizations focus their preparation.
• Interview: The assessor talks with IT staff, administrators, and end users. “Walk me through how you provision a new account” is a harder question than it sounds if your staff wasn’t involved in building the controls they’re describing.
• Test: The assessor actively verifies controls—tries to authenticate without MFA, reviews actual audit logs, checks encryption configurations, verifies patch levels on in-scope systems.

Your evidence package primarily supports Examine. But evidence that passes Examine and fails Test produces a Not Met determination anyway. A policy that says “MFA is required for all CUI access” doesn’t help you if an assessor can authenticate to a CUI system using only a password.

The Seven Document Types Assessors Expect

For CMMC Level 2, your evidence package needs to cover these categories. A gap in any one of them creates Not Met determinations across multiple control families simultaneously.

1. System Security Plan

The SSP is the foundational document. It describes how your organization implements each of the 110 NIST 800-171 requirements—what technologies, processes, and personnel support each control, and the defined assessment boundary. Assessors review the SSP first. An SSP that describes a network configuration you no longer have is worse than a gap in the SSP: it tells the assessor exactly where to look for the discrepancy.

2. Network and CUI Data Flow Diagrams

Your network diagram must reflect actual current state: CUI boundary, VPN connections, cloud services, and any segmentation supporting your scope strategy. The CUI data flow diagram shows where CUI enters your environment, how it moves between systems, where it’s stored, and where it exits. Most assessors compare these diagrams against what they observe during testing. A diagram that doesn’t match the tested environment fails automatically, regardless of how accurate the diagram was when it was drawn.

3. Policies and Procedures

At minimum, one policy per control family (14 families, 14 policies). Each must show a review date within the past year and an approving official. Procedures must be specific enough that a new employee could follow them—“contact IT” is not a procedure. Undated policies or policies with approval dates from 2022 signal drift rather than operational maintenance.

4. Technical Configuration Evidence

Screenshots and tool exports showing your security configurations: EDR settings, SIEM rules, firewall policies, MFA enforcement, encryption configurations. For FIPS 140-2 validated encryption (required for CUI at rest and in transit under SC.L2-3.13.8 and SC.L2-3.13.10), the module’s NIST validation certificate number is required—not just a product name or version string. Assessors verify this against the NIST Cryptographic Module Validation Program database.

5. Audit Logs

At least 90 days of audit logs available for review. The logs need to show user account activity, privileged access events, and security events—not just that logging is enabled. Two common failure patterns: the SIEM collects logs from the original in-scope systems but not from CUI systems added after initial configuration; and log retention is set to 30 days for storage reasons. Neither is visible until the assessor asks to pull logs and finds the gap.

6. Training Records

Records showing that all personnel with CUI access completed role-appropriate security awareness training within the past year. Privileged users require separate role-specific training records. A completion email in someone’s inbox is not a training record. A dated export from your LMS or a certificate with name, date, and completion status is.

7. Incident Response Test Documentation

Your IR plan must be tested annually. Tested means exercised—tabletop at minimum. Your evidence is the exercise summary: scenario, participants, decisions, findings, and follow-up actions. An IR plan that has never been run is not evidence of IR capability. For IR.L2-3.6.2, assessors ask who ran the last exercise and what findings were identified. “We haven’t run one yet” is a 3-point Not Met determination.

Evidence Quality Rules

Recency: the 90-day window for technical artifacts

Technical evidence—configuration screenshots, log samples, vulnerability scan results—should be collected within 90 days of the assessment start date. Evidence older than 90 days for dynamic control categories may be rejected as not representative of current state. Plan your evidence collection timeline backward from your scheduled assessment.

Final, not draft

Policies, procedures, and plans must be in final, approved form. Draft documents with tracked changes visible, or policies with “[INSERT DATE HERE]” placeholders, tell an assessor the document was prepared for the assessment rather than maintained operationally. If your IR plan was last approved in 2023, update it, get it approved, and document that review before the assessment. Assessors check signatures and approval dates.

Your environment, not a template

Generic policy language that could apply to any organization doesn’t satisfy the Examine method for controls that require organization-specific implementation. Your access control policy must reference your identity provider. Your media protection procedures must reference your specific sanitization tools. Assessors recognize standard compliance templates; what they’re evaluating is whether you’ve customized the template to reflect your actual environment.

eMASS submission: SHA-256 hashing required

When submitting artifacts to the DoD’s Enterprise Mission Assurance Support Service (eMASS), all artifacts must be hashed using SHA-256. The folder hash value and the log filename must accompany the submission. This is a technical submission step that catches many organizations by surprise—it has nothing to do with document quality, but forgetting it delays artifact acceptance and can push back assessment scheduling.

Organizing the Package by Control Family

Structure your evidence package with one folder per control family (AC, AT, AU, CM, IA, IR, MA, MP, PE, PS, RA, CA, SC, SI). Within each folder, include a cover sheet listing every requirement in that family, the Met or Not Met determination you expect, and the specific artifacts supporting it. This lets an assessor pull evidence on demand without searching through a flat archive.

Organizations that present a disorganized archive signal to assessors that evidence was assembled recently rather than maintained operationally. That perception increases the intensity of the interview and test phases, because assessors who doubt the documentation state are more likely to probe the controls themselves.

What Gets Rejected Most Often

Four patterns account for the majority of evidence rejections in early CMMC assessments:

• Date mismatches across documents: Policy dated 2022, network diagram dated 2023, SSP describing a cloud migration completed in 2024. Inconsistent dates across the package are a red flag that triggers closer scrutiny of every document in scope.
• Scope coverage gaps: Evidence covers your on-premises CUI systems but not the cloud service where CUI also flows. Every system within the assessment boundary needs supporting evidence—not just the systems you thought of first.
• Policy without process: “We have a media sanitization policy.” The assessor asks for a completed media sanitization log showing the last 12 months of activity. There isn’t one. The policy exists; the process it describes doesn’t operate.
• Missing control-to-artifact mapping: A large folder of documents with no indication of which document supports which requirement. If an assessor can’t locate the evidence for a specific control, the control doesn’t pass—even if the relevant document is technically present somewhere in the archive.

For a detailed walkthrough of what the C3PAO assessment sequence looks like once your package is assembled, see our post on what to expect during a CMMC C3PAO assessment—including how the Examine, Interview, and Test methods unfold across a typical 3–5 day engagement.

If you want to identify which control families have the most evidence gaps before your assessment, use our free CMMC readiness assessment to estimate your current SPRS score and see which domains are carrying the most risk.

Assessment results are estimates only and are not a substitute for a formal CMMC readiness assessment by a C3PAO or Registered Practitioner Organization (RPO). Consult an RPO for formal assessment readiness guidance.