CMMC Access Control Evidence: Prove the 22 Requirements

CMMC Access Control evidence is not a folder of screenshots. It is proof that every authorized user, process, device, privilege, session, remote path, external connection, and public release decision is both enforced and current.

A directory export cannot show every application role. A written least privilege rule cannot prove that a local administrator account was removed. One successful remote sign in cannot prove that an old device, stale user, forbidden route, or ordinary account is denied.

The practical job is to connect five things: authority, effective access, operating history, knowledgeable explanation, and a repeatable test. Each applicable assessment objective should point to that connected proof.

Use the CMMC Compliance hub for the full program, the CMMC assessment evidence guide for the objective method, and the NIST 800-171 Access Control guide for the broader control design. The CMMC evidence repository architecture guide shows how to govern source links and retrieval. GS Consulting supports this work through secure AI automation.

CMMC Access Control Evidence: The Short Answer

Start with the current assessed scope. List the people, service accounts, processes, devices, applications, cloud roles, network paths, remote tools, wireless connections, mobile devices, external systems, portable storage, and public release points that can reach or protect CUI.

For each applicable objective, identify the approved rule and owner. Then identify the source system that shows the current configuration or population, the operating record that shows the control over time, the person who performs the work, and the test that demonstrates the expected allowed or denied result.

The official guide presents potential objects and candidates, not a universal file checklist. Select evidence that fits the actual implementation. The best packet is not the largest one. It is the smallest current set that lets an assessor trace the decision, observe the control, question the operator, reproduce the test, and reach the same result.

Check the Current CMMC Status Before You Build the Packet

Program timing and an individual contract are separate questions. On July 13, 2026, the DoD CMMC Resources and Documentation page announced that Phase II requirements were suspended while Phase I self assessment requirements remained in place. That program direction can change.

The current solicitation, contract, subcontract, modification, required CMMC level, affirmation duty, CUI path, and customer direction still control the work for a specific award. Read them with DFARS 252.204-7021, DFARS 204.7504, and 32 CFR Part 170.

Do not delay basic access discipline while waiting for a later assessment date. Account lifecycle, privilege review, remote access, external connections, and public release are live security duties. Current records are easier to preserve during normal operation than to reconstruct later.

Use Examine, Interview, and Test as One Evidence Standard

The CMMC Level 2 Assessment Guide, version 2.13, defines 22 Access Control requirements and their assessment objectives. It uses three methods:

• Examine. Review policies, procedures, plans, configurations, lists, diagrams, records, logs, tickets, reports, and other artifacts.
• Interview. Ask the people who approve, administer, monitor, review, support, and use the control to explain the actual process.
• Test. Exercise the mechanism or process and compare the observed behavior with the expected result.

These methods should tell one story. The procedure says former staff are disabled promptly. The ticket shows when the action was requested and completed. The identity and application records show no effective rights. The administrator explains the exception path. A test confirms that the old identity is denied.

One objective assessed as not met can cause the requirement to be assessed as not met. That is why the working index belongs at the objective level even when owners collect one artifact that supports several objectives.

Original Research: The GS CMMC Access Control Evidence Priority Index

GS Consulting built a planning model for a narrow decision: which Access Control requirements deserve the earliest evidence work?

The model covers all 22 current Revision 2 Access Control requirements. It uses four public features from the official NIST supplemental assessment procedures: objective count, potential examine object mentions, potential interview candidate mentions, and potential test object mentions. GS added two analyst ratings from one to five: operating volatility and scope spread.

The base weights are 25 percent for objective breadth, 20 percent for examine breadth, 10 percent for interview coordination, 10 percent for test breadth, 20 percent for operating volatility, and 15 percent for scope spread. Public counts are normalized to the family maximum. Analyst ratings are normalized to five. The sum is reported on a zero through 100 scale.

Least privilege ranks first at 91.7. Authorized access control follows at 90.1. External connections score 78.2, CUI flow control 73.6, remote access control 71.1, and privileged functions 70.6. These are sequencing signals, not official risk ratings or assessment scores.

The sensitivity test moves five points from objective breadth to operating volatility. The top three requirements remain unchanged, and no score moves by more than 2.4 points. That limited test reduces concern that one small weight choice created the leading order. It does not predict cost, effort, failure probability, or CMMC status for a specific contractor.

Map the 22 Requirements into Six Evidence Lanes

A requirement list is accurate but hard to operate. Six evidence lanes make dependencies visible without changing the official requirement structure.

• Accounts and identities. Authorized users, processes, services, and devices.
• Roles and privilege. Allowed functions, duty separation, least privilege, ordinary account use, and privileged actions.
• CUI flow and release. Approved transfer paths and controls over public content.
• Logon and sessions. Failed attempt limits, notices, locks, and termination.
• Remote, wireless, and mobile. Authorized connections, protected sessions, routing, privilege, devices, and encryption.
• External systems and storage. Approved connections, external use, and portable media paths.

Keep the official objective identifiers in the crosswalk. The lanes are an operating view for assigning owners, collecting source records, designing tests, and spotting evidence that supports more than one requirement.

Prove the Complete Account and Identity Population

Begin with a population, not a policy. Reconcile human accounts, privileged accounts, service accounts, application identities, device identities, shared or emergency accounts, local accounts, provider identities, and noninteractive processes. Name the systems in which each can create effective access.

For each identity, preserve the request, business basis, role, system, approver, provisioned right, start date, review trigger, and removal condition. Then compare the approved record with the rights that actually exist. Include direct assignments, nested groups, inherited permissions, local grants, cloud roles, application roles, network rules, and provider consoles.

A joiner record proves creation. A role change record proves only the requested change. A termination ticket proves intent. None of them proves the current state until the effective rights are reconciled across the systems where access lives.

Service accounts deserve the same discipline. Name the owner, purpose, permitted systems, secret or certificate handling, interactive use restriction, privilege, review frequency, rotation event, and retirement condition. An old integration identity can preserve a path long after its project ends.

Connect Least Privilege, Duty Separation, and CUI Flow

Least privilege is not the absence of administrator labels. It is the match between an approved job or system need and the smallest effective rights that permit the work.

Build a privilege register that identifies the person or process, approved function, system, permission, approver, duration, monitoring condition, and review event. Record emergency elevation separately. Capture the actual privileged action where the requirement and implementation call for it.

Duty separation evidence should identify the incompatible actions, the roles that perform them, the system enforcement point, and the exception authority. Test whether one identity can both initiate and approve a protected action when the design says it cannot.

CUI flow control connects identity with source, destination, transfer method, content condition, and release authority. A user may be authorized to view CUI in one system without being authorized to export it to another. Preserve the rule, enforcement point, transfer history, exception, and blocked path test.

Treat Remote, Wireless, Mobile, and External Paths as Access Decisions

Boundary technology does not automatically prove the boundary. For each remote, wireless, mobile, external, or portable storage path, identify who or what may use it, from which device, through which route, with which protection, for which purpose, into which system, and under whose approval.

Remote access proof may include the approved method, gateway and identity settings, encryption configuration, device condition, session record, route, privileged command control, review, exception, and a test from both an approved and unapproved condition.

For provider supported paths, separate provider capability from customer configuration and shared operation. A service statement can establish available features. It does not prove that the contractor enabled the right setting, limited the right population, reviewed access, handled exceptions, or captured current records.

The CMMC Level 2 Scoping Guide, version 2.13, distinguishes CUI assets, security protection assets, contractor risk managed assets, and specialized assets. Use the actual CUI flow and security dependency map to decide which access paths and systems belong in the evidence population.

Preserve the Decisions That Happen Between Reviews

A clean export on collection day can hide months of weak operation. Preserve the events that show the control running: requests, approvals, grants, changes, reviews, denials, revocations, failed attempts, alerts, exceptions, provider actions, public content reviews, and corrective work.

Every record should have a stable identity, source system, event time, affected identity or path, decision, actor, result, and link to the applicable objective. Preserve enough history to show the required period and the current assessed state. Apply the organization's approved retention and evidence handling rules.

Exception evidence needs a reason, scope, owner, approval, compensating action, start, expiration, monitoring condition, and closure result. An exception without an end condition quietly becomes the design.

Keep authoritative records in the systems that create them when practical. The evidence repository should index those records, control collected copies, and make retrieval repeatable. Duplicating every log into a manual folder creates stale evidence and unnecessary handling risk.

Test the Allowed Path and the Denied Path

A test should state the objective, scenario, population, starting condition, expected result, actual result, evidence source, defect, correction, retest, date, and approver. It should identify the exact system and configuration version observed.

Useful pairs include:

• An approved user reaches the required CUI function; a stale or unapproved user is denied.
• A privileged account performs the approved function; an ordinary account cannot perform it.
• An approved CUI transfer reaches the named destination; an unapproved destination is blocked.
• The failed attempt threshold triggers the expected response; a valid user can recover through the approved process.
• An approved device uses the protected remote route; an unmanaged device or alternate route is denied.
• Approved public content passes review; a CUI sample is blocked or removed through the documented process.

Run tests safely and coordinate any activity that can lock accounts, change access, affect production, or expose sensitive data. Use synthetic or approved test information when the objective does not require real CUI.

Six Evidence Failures That Weaken Confidence

1. Group export only. Direct, nested, inherited, local, cloud, application, and provider rights remain invisible.
2. Successful logon only. One allowed path proves nothing about forbidden or stale access.
3. Stale population. Former staff, old devices, unused services, and abandoned paths remain in the evidence.
4. Provider promise. A capability statement replaces current customer settings and operating records.
5. Policy without operation. The approved rule has no matching grant, review, alert, revocation, or removal history.
6. No exception path. Emergency access, failed review, and control outage have no owner, limit, monitoring, or closure proof.

A 45 Day Access Evidence Plan

Days 1 through 7: freeze scope and ownership

Confirm the current contract baseline and program direction. Reconcile the CUI flow, asset categories, security providers, identity sources, access paths, and public release points. Assign one accountable owner and one operator for every evidence lane.

Days 8 through 15: build the objective crosswalk

Map all 70 Access Control objectives to the implementation statement, evidence source, examine item, interview role, test scenario, owner, period, and status. Record any justified not applicable determination with supporting scope facts.

Days 16 through 25: reconcile authority and effective access

Collect account and path populations from the source systems. Compare every material right with its authorization. Remove stale rights through normal change control. Document exceptions and retest the corrected state.

Days 26 through 35: collect operating history and test both outcomes

Collect representative approvals, grants, changes, reviews, revocations, alerts, exceptions, provider actions, and release records. Run the approved and denied scenarios. Capture exact configurations, dates, results, defects, and corrections.

Days 36 through 45: rehearse retrieval and close gaps

Have each operator explain the work from the authoritative source. Ask a reviewer who did not build the packet to request evidence by objective. Repair missing context, broken links, stale exports, unexplained differences, and failed tests. Approve the final current package.

The Minimum CMMC Access Control Evidence Packet

1. CUI access map. People, services, devices, systems, stores, transfers, providers, and release points.
2. Objective crosswalk. All 70 objectives linked to the current examine, interview, and test path.
3. Authorization register. Request, basis, role, system, approver, effective right, date, and review trigger.
4. Population inventory. Users, privileged and service accounts, devices, remote paths, and external systems.
5. Effective access review. Decisions compared with direct, nested, local, cloud, application, and provider rights.
6. Configuration baseline. Access, flow, session, remote, wireless, mobile, external, and public controls.
7. Operating history. Grants, changes, reviews, revocations, alerts, exceptions, and provider actions.
8. Access test record. Scenario, expected result, actual result, evidence, defect, correction, retest, and approval.

Research Sources, Method, and Caveat

The research package uses the DoD CMMC Resources and Documentation page, the CMMC Level 2 Assessment Guide, version 2.13, the CMMC Level 2 Scoping Guide, version 2.13, and the NIST SP 800-171A Revision 2 publication page. NIST withdrew that publication in 2024 and superseded it with Revision 3. The current CMMC Level 2 guide still incorporates the Revision 2 objective structure.

Counts come from the official NIST supplemental assessment procedures CSV. NIST states that the PDF is normative if a supplemental data format differs. GS handled a source formatting anomaly in requirement 3.1.19 by selecting the first populated candidate set within the requirement group.

Model caveat: this is a GS Consulting derived planning model based on cited public sources and documented assumptions. It is not an official legal, audit, compliance, NIST, CMMC, DoD, assessment, certification, or regulatory determination. It does not estimate market averages, cost, labor, failure probability, or a contractor's status. Replace the ratings and sequence with the actual system, contract, assessment, and operating facts.

Frequently Asked Questions About CMMC Access Control Evidence

The standard is direct: every access decision has an owner, every effective right matches it, every change leaves a record, every exception closes, and every allowed and denied path can be reproduced.