A CMMC evidence package should prove three things: the requirement is implemented, it applies to the systems inside your assessment scope, and the control works in practice. A policy alone rarely proves all three. Strong evidence usually combines documents or configurations that can be examined, people who can explain the process, and system behavior that can be tested.
Start with scope, not screenshots. Identify the CMMC level required by the solicitation or contract, define the FCI or CUI environment, map each applicable assessment objective to evidence, and assign an owner before collecting artifacts. Otherwise, evidence collection turns into a digital attic: hundreds of files, little traceability, and painful gaps discovered at assessment time.
There is also an important 2026 timing issue. The Department suspended CMMC Phase II implementation on July 13, 2026, while keeping Phase I self-assessment requirements in place. Do not assume that handling CUI automatically means a C3PAO certification assessment is required today. Check the actual solicitation or contract and the current CMMC implementation status published by the Department before deciding what assessment path you must prepare for.
Table of Contents
What Counts as CMMC Evidence?
CMMC evidence is information that allows an assessment objective to be evaluated. For Level 2, the Department’s assessment guidance uses the NIST assessment methods of examine, interview, and test. These methods matter because collecting documents is only one part of readiness.
| Assessment Method | What It Demonstrates | Typical Evidence |
|---|---|---|
| Examine | What is documented or configured | SSP, policies, procedures, configuration exports, logs, tickets, inventories |
| Interview | Whether responsible people understand and perform the process | System administrator, security lead, HR, help desk, facilities, control owner |
| Test | Whether a mechanism actually performs as described | Live configuration check, authentication test, access review, logging demonstration |
A screenshot can be useful evidence, but it is not a magical assessment token. A screenshot showing that MFA is enabled, for example, may establish one configuration fact. It may not establish who is covered, what exceptions exist, how enrollment is controlled, or whether the mechanism operates across every in-scope access path.
The practical rule is simple: collect enough evidence to answer the assessment objective, not enough evidence to fill a folder.
Start With Scope Before Collecting Anything
The most expensive evidence mistake is collecting proof for the wrong environment. CMMC is scoped around the systems, assets, people, facilities, and security services relevant to FCI or CUI protection.
For a Level 2 environment, the official CMMC Level 2 Scoping Guide distinguishes several asset categories, including CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets. Those classifications change what must be documented and what may be examined during an assessment.
Collect these scope artifacts first
- Current system boundary description
- Network diagram showing the assessment scope
- Asset inventory with asset category
- Users and privileged-account inventory
- Cloud services used to process, store, transmit, or protect CUI
- Security Protection Assets such as identity, endpoint, firewall, VPN, logging, and security-management systems
- Facilities where in-scope information can be accessed
- External connections and remote-access paths
- Managed service providers and other service providers affecting the environment
- Subcontractor information flows
- CUI repositories and major data flows
- Documented rationale for assets treated as out of scope or risk managed
Your network diagram, inventory, SSP, and evidence matrix should tell the same story. If the SSP says Microsoft 365 is in scope, the inventory says it is out of scope, and your diagram omits it entirely, the problem is larger than missing paperwork. The organization has not established a stable assessment boundary.
CMMC Evidence Collection Checklist
Use the following checklist as an evidence readiness layer over the applicable CMMC assessment guide. It is not a substitute for the individual assessment objectives.
Governance and system documentation
- System Security Plan is current and matches the actual environment.
- System boundary and environment of operation are documented.
- Connections to external systems and services are documented.
- Security responsibilities and control owners are assigned.
- Policies referenced by the SSP exist and are approved where required by organizational process.
- Procedures explain how recurring security activities are actually performed.
- Exceptions are documented rather than silently operating outside policy.
- Plans of action accurately reflect known deficiencies where POA&Ms are permitted.
- Previous assessments and remediation records can be traced to current implementations.
Access control
- Current user and privileged-account inventories
- Account provisioning and deprovisioning records
- Access approval records
- Role or group membership evidence
- Least-privilege configuration
- Remote-access configuration
- Session-lock and session-termination settings where applicable
- Access-control lists or equivalent authorization settings
- Periodic access-review records
- Evidence showing terminated or transferred users are handled as documented
Identification and authentication
- Identity-provider configuration
- MFA configuration and enforcement scope
- Authentication-policy settings
- Privileged-authentication controls
- Password or authenticator configuration where relevant
- Device or service-account authentication configuration
- Processes for authenticator issuance, replacement, and revocation
- Evidence for approved authentication exceptions, if any
Audit and accountability
- Logging configuration for in-scope systems
- Examples of generated security events
- Centralized log collection configuration where used
- Log-retention settings
- Time-synchronization configuration
- Log-review procedures
- Records showing reviews or investigations actually occurred
- Alert or escalation records demonstrating follow-through
- Access controls protecting audit information
Configuration management
- Approved baseline configurations
- Security configuration standards
- Change-management records
- Configuration-review records
- Software inventory
- Evidence restricting unauthorized software
- Administrative configuration for endpoints and servers
- Records showing security-impact analysis for relevant changes
Incident response
- Incident-response plan
- Roles, contacts, and escalation paths
- Incident classification or handling procedure
- Incident tickets or records when available
- Exercise or tabletop records
- Lessons-learned or corrective-action records
- Evidence that personnel know how to report suspected incidents
- Applicable contractual cyber-incident reporting procedures
Maintenance
- Maintenance procedures
- Maintenance activity records
- Controls over remote maintenance
- Authorization for maintenance personnel
- Sanitization or handling procedures for equipment leaving controlled areas
- Vendor or support-session records where external maintenance occurs
Media protection
- Media inventory or handling records where applicable
- Removable-media restrictions
- Encryption configuration
- Media marking and handling procedures
- Storage protections
- Transport controls
- Sanitization and disposal records
- Technical controls preventing prohibited removable-media use
Personnel and physical security
- Personnel screening procedures applicable to the scoped environment
- Termination and transfer workflows
- Physical-access authorization lists
- Badge or access-control configuration
- Visitor procedures and records where relevant
- Physical protection of systems, media, and work areas
- Records showing physical access is reviewed and revoked when necessary
Risk and security assessment
- Risk assessments
- Security-control assessment records
- Vulnerability scan results
- Finding triage and remediation records
- Risk acceptance records where legitimate organizational risk decisions exist
- Evidence that corrective actions are tracked to completion
- Records demonstrating ongoing security-control monitoring
- Updated SSP documentation after material system changes
System and communications protection
- Network-security architecture
- Firewall or security-group configuration
- Network segmentation evidence
- Boundary-protection configuration
- Encryption settings for CUI transmission
- Encryption settings for stored CUI where required by the applicable requirement or architecture
- Remote-access security configuration
- DNS, proxy, gateway, or similar protective configuration where relevant
- Controls separating public-facing and internal components
System and information integrity
- Vulnerability-management process
- Patch-management records
- Endpoint protection configuration
- Malware protection settings
- Security alerting configuration
- Threat or advisory review records where relevant
- Remediation tickets
- Evidence that identified vulnerabilities are prioritized and corrected according to organizational risk processes
Build an Evidence Matrix Assessors Can Follow
Folders organized only by control family are better than a desktop full of screenshots, but they still leave an important question unanswered: which artifact proves which assessment objective?
The stronger model is an evidence matrix. For Level 2 preparation, work from the assessment objectives in the official CMMC Level 2 Assessment Guide, not merely the 110 high-level requirement statements.
| Field | What to Record |
|---|---|
| Requirement | CMMC or NIST requirement identifier |
| Assessment objective | The specific objective the evidence supports |
| Scope asset | System, service, person, facility, or security asset involved |
| Evidence | Exact document, configuration, record, or demonstration |
| Method | Examine, interview, test, or combination |
| Owner | Person responsible for producing or explaining the evidence |
| Evidence date | When the artifact was generated or last reviewed |
| Repository | Controlled location where evidence can be retrieved |
| Status | Ready, needs refresh, gap, or remediation |
This creates an important distinction between a control inventory and an evidence map. The inventory says what you believe is implemented. The evidence map shows how that belief can be independently verified.
Use the Three-Layer Evidence Test
For each assessment objective, ask whether your package can establish three layers.
- Design: Is the intended control documented?
- Implementation: Can you show that the relevant system or process is configured accordingly?
- Operation: Can records, interviews, or testing demonstrate that it actually functions?
Suppose a procedure says administrators review privileged access quarterly. The procedure establishes design. A current list of privileged accounts helps establish implementation. Completed review records, approvals, revocations, and an administrator who can explain the review process provide stronger evidence of operation.
This test also prevents a common form of compliance theater: carefully written documents describing controls that cannot be found in production.
What Makes CMMC Evidence Weak or Unusable?
Weak evidence usually fails because its relationship to the requirement, scope, or current environment cannot be established.
| Weak Evidence | Why It Creates a Problem | Better Approach |
|---|---|---|
| Undated screenshot | Cannot establish when or where the configuration existed | Capture source, system, date, and relevant configuration context |
| Policy only | Shows intent, not implementation | Add configuration, records, interview, or test evidence |
| Huge log export | Relevant event may be impossible to identify | Preserve the authoritative source and identify representative events |
| Generic vendor brochure | Describes product capability, not your configuration | Show tenant-specific configuration or live implementation |
| Old employee list | May not represent current access | Export current identity and authorization information |
| Screenshot with no scope mapping | Assessor cannot tell which asset or objective it supports | Reference the asset and assessment objective in the evidence index |
| Edited evidence with missing context | May make verification difficult | Redact only what is necessary and retain traceability to the source |
Do not invent a universal evidence-expiration rule such as “every screenshot must be less than 90 days old.” Different evidence proves different things. A network architecture decision may remain valid for months, while a current account list can change tomorrow. The question is whether the evidence remains relevant to the implementation being assessed.
Do Not Turn the Evidence Repository Into a New CUI Problem
CMMC evidence can contain sensitive material: usernames, IP addresses, firewall rules, vulnerability findings, architecture details, access records, CUI locations, and sometimes CUI itself. Building a giant uncontrolled evidence share can create exactly the exposure the assessment is intended to reduce.
- Store evidence in an approved location.
- Restrict access to people who need it.
- Avoid copying CUI into evidence when a configuration demonstration can establish the objective without it.
- Redact unrelated personal or sensitive data where doing so does not destroy evidentiary value.
- Maintain source traceability for redacted artifacts.
- Control assessor and consultant access to repositories.
- Define how temporary evidence exports will be removed after their purpose is complete.
- Do not email sensitive evidence casually because it is “only for the audit.”
A live demonstration can sometimes be cleaner than exporting a sensitive dataset. Evidence collection should reduce uncertainty without multiplying sensitive copies across laptops, inboxes, and shared drives.
How Much Evidence Should You Collect?
More evidence is not automatically better. The useful amount is the smallest defensible set that allows each applicable objective to be verified across the actual scope.
One artifact can legitimately support multiple objectives. A current identity-provider configuration, for example, may contribute evidence to several authentication and access-control objectives. Do not make twenty identical screenshots merely because twenty rows in a spreadsheet mention the same system.
The reverse is also true. One polished policy should not be mapped across dozens of objectives when separate technical mechanisms and operational activities must be demonstrated.
Optimize evidence for traceability, not volume: requirement → objective → scope asset → evidence → owner → verification.
Run a Mock Evidence Review Before the Assessment
A useful readiness review does not ask, “Do we have a file for every control?” It attempts to verify the environment using the same basic evidence modes an assessment can use.
Pick a requirement and attempt all three paths
- Examine: Open the documents, configurations, and records without asking the control owner to explain what should be there.
- Interview: Ask the responsible person to explain what happens, who approves it, where records are kept, and what happens when the normal process fails.
- Test: Where appropriate, demonstrate the relevant mechanism in the scoped environment.
If the evidence only makes sense after the security lead spends ten minutes reconstructing its meaning, improve the evidence index. If an administrator’s explanation contradicts the procedure, investigate the process. If the documentation and interview agree but the configuration does not, you have an implementation gap rather than an evidence gap.
Know the Difference Between an Evidence Gap and a Control Gap
This distinction can save substantial remediation time and money.
| Finding | What It Means | Likely Next Action |
|---|---|---|
| Control exists, proof is disorganized | Evidence-management gap | Index, refresh, and map existing artifacts |
| Control exists on some scoped assets only | Implementation gap | Correct inconsistent deployment |
| Policy describes a control that does not exist | Control gap | Implement the control or correct the documented approach |
| Asset was omitted from scope documentation | Scoping gap | Reassess boundary, inventory, SSP, and affected evidence |
| Recurring process has no record of execution | Operational or evidence gap | Determine whether the activity occurred, then correct the process |
Buying a compliance platform cannot repair a control gap. It may make the absence easier to see, which is useful, but the underlying technical or operational deficiency still needs an owner and remediation plan.
When Software or Professional Help Is Worth Paying For
A spreadsheet and controlled document repository may be sufficient when the environment is small, the scope is stable, and control ownership is clear. Evidence software becomes more useful when several systems, control owners, cloud tenants, locations, or recurring assessments must be coordinated.
DIY can be enough when
- The assessment scope is small and well understood.
- The same few administrators own most controls.
- Evidence can be retrieved consistently from existing systems.
- You do not need complex workflow automation.
- Your team understands the applicable assessment objectives.
Evidence software becomes useful when
- Evidence must be refreshed repeatedly across many owners.
- You need objective-level mapping and change tracking.
- Manual collection is consuming significant staff time.
- Multiple compliance programs reuse the same underlying evidence.
- Integrations can collect reliable configuration data directly from systems of record.
Professional help becomes more defensible when
- CUI boundaries remain unclear.
- Your SSP and production architecture materially disagree.
- You cannot confidently classify assets within the assessment scope.
- Major NIST SP 800-171 requirements remain partially implemented.
- A contractual assessment requirement is approaching and internal expertise is limited.
- A government-led or independent assessment creates material contract risk.
Before buying either software or consulting, ask for a concrete answer to one question: Which unresolved evidence, scope, or implementation problem will this purchase remove? If the answer is merely “it gives us a compliance dashboard,” keep the checkbook closed a little longer.
For budgeting beyond evidence collection, separate assessment preparation, technical remediation, recurring operations, software, and outside assessment expenses rather than treating them as one number. This distinction matters because a low assessment fee does not make an unprepared environment inexpensive to certify.
Verify the Requirement Before Building the Package
CMMC implementation is contractual. The current DFARS clause requires contractors to maintain the CMMC status specified for applicable information systems when the clause and requirement are incorporated into the procurement. The exact level and assessment type therefore matter more than a generic statement that an organization “needs CMMC.”
Review the solicitation, contract, flowdown obligations, applicable information type, and current program implementation before deciding what evidence program to build. The current DFARS 252.204-7021 clause and the Department’s CMMC resources and documentation are better verification points than a checklist copied from an old consulting slide deck.
As of August 2026, Phase II implementation remains suspended and Phase I self-assessment requirements remain in place. That pause does not erase underlying contractual safeguarding obligations, nor does it make evidence discipline wasted effort. A well-built evidence system is useful for self-assessment, customer scrutiny, government review, remediation, and whatever assessment path an applicable procurement ultimately requires.
Frequently Asked Questions
Do I need one evidence file for every CMMC requirement?
No. One artifact can support several assessment objectives, and one requirement may need several different evidence objects. Map evidence to what must be verified rather than forcing a one-file-per-control structure.
Are screenshots enough for a CMMC assessment?
Not by themselves. Screenshots can be useful examination evidence, but some objectives require additional documentation, interviews, records, or testing to establish how the control is implemented and whether it operates as intended.
Should CMMC evidence be collected only right before an assessment?
No. Evidence for recurring activities is much easier to preserve when it is generated as part of normal operations. Waiting until assessment month can expose a painful problem: the control may have operated, but the records needed to demonstrate it were never retained.
Does the 2026 Phase II suspension mean Level 2 evidence no longer matters?
No. Current Phase I Level 2 self-assessment obligations remain relevant where applicable, and the underlying protection requirements for CUI have not disappeared. The suspension means organizations should verify the current assessment requirement rather than assuming the previously scheduled Phase II rollout is proceeding unchanged.
Your Next 15 Minutes
Do not begin by collecting another screenshot. Open a blank evidence register and create these columns: requirement, assessment objective, scope asset, evidence, method, owner, date, repository, and status.
Then select five assessment objectives from the level that actually applies to your organization. For each one, identify what an assessor could examine, who could be interviewed, and what could be tested. Mark anything you cannot substantiate as either an evidence gap, implementation gap, or scoping gap.
That small exercise tells you far more than a folder containing 500 unlabeled screenshots. It converts CMMC evidence collection from document hunting into verification, which is exactly what the assessment process is designed to accomplish.
Last reviewed: 2026-10
CMMC compliance costs and assessment budgeting MFA rollout and implementation guidance AWS CloudTrail logging checklist vulnerability remediation SLA customer security questionnaire preparation