CMMC evidence: what supports a self-assessment?

Connect evidence to assessment objectives, show what each record covers, and keep missing populations, contradictions and remediation rechecks visible.

Evidence has a specific job. Policy: intended process. Export: observed state. Review: human decisions. Working guide.
In this guide

Useful CMMC evidence connects a requirement to the actual people, systems, settings, and activities in your assessment scope. Record where each artifact came from, when it was collected, what it covers, and what it cannot establish. More screenshots do not compensate for missing coverage or an unresolved contradiction.

This guide explains evidence quality. For submission steps, use the Level 2 self-assessment and SPRS guide. For a practice evaluation, read what a CMMC mock assessment should examine.

Start from a requirement and its objectives

For the Revision 2 assessment basis, NIST SP 800-171A (June 2018) provides assessment objectives and potential assessment methods and objects. It identifies examine, interview, and test methods. It does not prescribe a universal three-file evidence package for every requirement.

Identify the applicable objectives, the population being assessed, and the evidence needed to support the determination. A policy describes intended behavior. Configuration and operating records show other parts of implementation. An interview may clarify practice, but a completed questionnaire is not a substitute for missing technical or operating evidence.

Worked example: authorized access to an engineering site

Illustrative example: a company says only approved engineering personnel may use a project site. A site-membership export is relevant, but it is not the complete evidence for requirement 3.1.1. Review the authorized identities, access paths, applicable processes acting on behalf of users, and devices. Consider inherited groups, guests, privileged access, application permissions, and sharing links where they apply.

ArtifactWhat it can supportWhat remains to check
Approved access rules and authorizationsWho should receive access and who approves itWhether those rules are implemented and the authorizations remain current
Dated effective-access exportsThe access paths visible to that collection method at that timeNested groups, omitted identities, permissions outside the export, and collection failures
Completed access review and resulting changesThe comparison actually performed and actions recordedWhether the review covered the full relevant population and removals became effective
Appropriate access testsThe behavior of the tested accounts and pathsUntested paths and whether the test was representative of the assessed scope

This set is an example, not a guarantee of acceptance. The evidence must answer the applicable objectives for your environment. If two records disagree, keep the disagreement visible and investigate it rather than selecting the more favorable record.

Give each artifact a useful index entry

A record should include an identifier, source system, scope, collection time, collector, method, relevant population, limitations, supported requirements or objectives, and a protected location for the artifact. Add version or integrity information when it helps distinguish the actual record reviewed.

Illustrative record — not customer evidence
ID: E-012
Artifact: Engineering site access export
Source: Example tenant and project-site identifier
Collected: Actual collection timestamp, with timezone
Collector and method: Named operator or connector; export operation
Coverage: Direct memberships and expanded groups; guests included
Limitations: Application permissions and sharing links reviewed separately
Supports: Candidate evidence for 3.1.1; objective mapping requires review
Related records: Approved access list; review record; separate access-path exports
Location: Protected evidence repository reference
Open issue: One unresolved group expansion

Do not put controlled information, passwords, tokens, or unnecessary personal data into a broadly accessible index. An index describes and locates evidence; it is not the evidence itself.

Check empty results, stale records, and missing coverage

“No external users” may mean no users were found, or that the query, permission, filter, or collection failed to cover them. Record the method's success and limitations before interpreting an empty result. The same caution applies to device inventories, audit logs, and vulnerability reports.

Compare the expected population with the population observed. If a device console shows ten laptops and the assessed inventory has twelve, identify the two unmatched devices. Do not describe ten healthy records as proof that all twelve devices are protected. Resolve renamed, stale, duplicated, or excluded records explicitly.

Freshness depends on the fact being supported. A current membership export and an access review from the relevant review period answer different questions. Do not replace a missing historical activity record with a newly completed template.

Preserve the change and the recheck

For remediation, keep the finding, original evidence, authorized change, subsequent evidence, and explanation of what changed. A closed ticket records an action; it does not necessarily demonstrate effective implementation. A new membership export without a former employee is useful, but also check other access paths relevant to the finding.

Human observations should identify who observed what and when. They should not be framed as an administrative override declaring a requirement satisfied. If a scheduled review did not happen, record that gap honestly, perform the current review, and use its actual date.

A practical evidence review

  1. Select a requirement and identify its applicable objectives.
  2. State the assessed scope and expected population.
  3. Match each objective with evidence that can support it.
  4. Record collection limitations, missing records, and contradictions.
  5. Resolve the gaps and repeat the relevant checks.
  6. Retain the evidence and rationale behind the resulting determination.

The security requirements are in NIST SP 800-171 Rev. 2; confirm the applicable program and assessment route using the official CMMC update and your contract.

Garde1 supports evidence collection and mock-assessment findings. Review which connectors and capabilities are available and an illustrative mock report. Some requirements need manual operating evidence. Neither a connector's successful collection nor a mock score is certification.