Automation Over Documentation

The traditional approach

A contractor enables MFA in its identity platform. To prove it, someone takes screenshots, copies account counts into a spreadsheet, describes the setting in the SSP, and files the same material under several assessment objectives. An advisor may reorganize it. An assessor may ask for a fresh export anyway.

• The screenshot has no reliable connection to the current account list.
• The same fact appears in several files and drifts out of sync.
• The reviewer cannot rerun the collection or see what changed.
• Skilled people spend time reconciling files before they can test the safeguard.

Documents are still necessary. Reconstructing the underlying facts for every document and every reviewer is not.

The CMMC 20X approach

Collect the identity export directly. Record when it was collected, which tenant and accounts it covers, which collection method produced it, and who reviewed the result. Link that evidence to the MFA claims it supports. If one break-glass account lacks MFA, keep the conflict with the claim instead of smoothing it out in a narrative.

The SSP, evidence index, internal review, and assessment package can show different views of that record. They do not need separate versions of the fact.

In practice

What software can do

• Collect configuration and inventory data from AWS, Azure, M365, identity providers, endpoint tools, and ticketing systems.
• Check dates, coverage, expected fields, and known contradictions.
• Suggest which CMMC objectives an artifact may support.
• Generate consistent human-readable documents from reviewed records.

What software cannot decide

An export can show that 23 of 24 privileged accounts use MFA. It cannot decide whether the uncovered account is an acceptable emergency exception, a failed requirement, or evidence of a larger scoping problem. A qualified reviewer still has to examine the context and reach the finding.

What an open evidence profile could contain

CMMC 20X proposes common fields that competing tools could produce and validate. Instead of relying only on a screenshot of an Azure AD configuration, for example, a machine-readable record could preserve:

{
  "control": "AC.L2-3.1.1",
  "evidence_type": "configuration",
  "source": "azure_ad",
  "timestamp": "2026-01-24T10:30:00Z",
  "validation": {
    "mfa_enabled": true,
    "conditional_access_policies": 12,
    "privileged_accounts_protected": true
  }
}

Software can compare this record with the prior export and flag a missing account. A reviewer still decides what the result means.

This example is not a Government standard. The Department would still need to define the CMMC-specific fields, acceptable uses, and conformance tests through an open, vendor-neutral process.

Who gets time back

For contractors (OSAs)

• Reuse the same reviewed fact in the SSP, internal review, and assessment package.
• See when evidence was collected and which systems it covers.
• Fix a conflict instead of hunting through several copies of the claim.

For RPOs & advisors

• Spend less time collecting routine exports and naming files.
• Use expert time on scope, remediation, and evidence that needs context.

For C3PAOs

• Receive the source, date, coverage, and conflicts with each claim.
• Rerun repeatable checks and focus interviews on unresolved questions.

Getting started

Start with one claim that creates repeated work:

1. Name the claim. For example, every privileged account uses MFA.
2. Name the source. Identify the system and export that can prove or contradict it.
3. Record coverage and time. State which tenant and accounts the export covers and when it was collected.
4. Keep the reviewer’s finding separate. Preserve what the evidence says and what the reviewer concluded.