Access Control is 22 of the 110 practices in CMMC Level 2, the largest single domain. It's also where most small defense contractors get stuck. Not because the technology doesn't exist, but because the documentation doesn't.
Here's the scenario that plays out repeatedly in CMMC readiness assessments: a small defense contractor has decent technical controls. They have Active Directory. They have a VPN. Most people use MFA. The IT administrator is competent and genuinely cares about security. But when the assessor asks to see the Access Control Policy, there isn't one. When the assessor asks how accounts are provisioned and revoked, the answer is "we handle it as needed." When the assessor asks about least privilege, the administrator explains what they do, but there's nothing written down, no evidence of formal access reviews, no procedure for handling terminated employees.
Good security practice without documentation fails a CMMC assessment. The assessment isn't just testing whether your controls work. It's testing whether your controls are defined, implemented, and verifiable. That's what the Access Control Policy provides.
The core problem: CMMC Level 2 assessors don't take your word for it. For each of the 22 Access Control practices, they need to see evidence, a policy document, a system configuration, a log, an interview that aligns with the written procedure. If there's no written procedure, every control becomes harder to prove.
The Access Control domain in NIST SP 800-171 Rev 2 (practices 3.1.1 through 3.1.22) is the most comprehensive in the framework. These 22 practices fall into six practical categories:
Only authorized users get access. Users can only perform the transactions their job requires. These are the foundation, everything else in the domain builds on them. The gap here is usually the absence of a formal provisioning process and RBAC documentation.
CUI must flow only where it's authorized to go. Duties must be separated to prevent fraud. Admins must use separate privileged accounts and standard accounts for everyday tasks. Privileged function execution must be logged. This is where most mature IT environments pass the technical test but fail the documentation test, no written Least Privilege Policy, no Separation of Duties matrix, no Privileged User Register.
Account lockout after failed login attempts. System use notification banners at login. Screen lock after inactivity. Session termination after defined periods. All of these are technical Group Policy settings that most IT admins can configure in an afternoon, but they must be documented in policy and verified by assessors.
One of the most scrutinized areas in CMMC assessments. Remote access must be authorized, encrypted (AES-256 / TLS 1.2+), routed through managed gateways, and monitored with logs. Split tunneling that lets VPN users simultaneously reach the internet directly is a finding. Direct RDP exposure to the internet is a critical finding. These requirements are technical, but the policy that defines them must exist in writing.
Wireless access must be authorized and protected with enterprise-grade authentication (WPA2/WPA3-Enterprise with 802.1X, not PSK). Guest wireless must be isolated from the network carrying CUI. Small shops running a flat network with a shared Wi-Fi password and CUI on the same segment fail this category completely.
Mobile devices must be managed (MDM enrolled) and encrypted before accessing CUI. Portable storage (USB drives) must be controlled. Connections to external systems must be authorized. CUI must never appear on publicly accessible systems. These controls require both technology and documented policy, and the enforcement evidence to back it up.
Based on patterns seen in CMMC readiness work across small defense contractors, these are the gaps that appear most consistently:
The most common failure by far. Technical controls exist but there's no document that defines the rules. Assessors look for the policy first. Without it, every control becomes anecdotal rather than systemic.
Practice 3.1.13 requires cryptographic mechanisms for remote sessions. Practice 3.5.3 (Identification and Authentication) requires MFA for all network access by non-privileged users. Many contractors have MFA "available" but not enforced, some users skip it, legacy apps bypass it. Conditional Access Policies in Azure AD are the standard solution here. Partial enforcement is still a finding.
The framework requires that access be reviewed periodically. Most small contractors have accounts that belong to former employees, contractors who finished their project two years ago, or service accounts with no documented owner. A quarterly access review, even a simple spreadsheet walk-through with a sign-off, closes this gap. The absence of any review evidence is an automatic finding.
Practice 3.1.6 requires that non-privileged accounts be used for non-security functions. If your sysadmin logs into their @domain admin account to check email and browse the web, that's a finding. The fix is straightforward, create separate accounts, but the policy requiring it has to exist and be enforced.
Guest wireless and corporate wireless on the same network segment, or WPA2-Personal (PSK) used on a network that carries CUI, fails practices 3.1.16 and 3.1.17. Enterprise wireless authentication and VLAN isolation are required. For small shops with limited IT resources, this is often the most operationally disruptive finding to remediate.
Practice 3.1.21 limits portable storage use. Practice 3.8.7 (Media Protection) adds additional controls. Most small contractors have no policy on USB drive use and no technical controls blocking unknown USB devices. Endpoint management tools (or even built-in Windows GPO controls) can address this, but again, the policy defining the rule has to come first.
A C3PAO assessor conducting an AC domain review will typically do the following:
The thing most contractors don't expect: Assessors will interview non-IT staff. They'll ask a random employee to describe how they access company systems, whether they've seen a login banner, what they do when they're done working for the day. If the employee's answer doesn't match the policy, that's a finding against the policy, even if the GPO is configured correctly.
A formal Access Control Policy doesn't implement your technical controls, your IT systems do that. What it does is three things an assessor needs to see:
First, it defines the rules. "Account lockout occurs after 5 failed attempts" is a rule. Putting it in writing, in a document signed by the System Owner, makes it official organizational policy, not just a Group Policy setting someone configured once.
Second, it creates the audit trail. When you conduct an access review, you can point to the policy that requires it. When you provision or deprovision an account, the policy defines the process that was followed. This is what shifts individual actions into verifiable organizational practices.
Third, it maps directly to CMMC practices. A well-structured Access Control Policy maps each section to the specific practice requirement it satisfies. When an assessor asks "how do you address practice 3.1.12, monitoring remote access?", you point to Section 9.6 of your policy, then show the logs. Done.
Writing an Access Control Policy from scratch, researching the 22 practices, drafting clear procedures, getting internal review, and formatting for production, takes 6–12 hours for a small organization. That's time most IT administrators don't have when they're also managing the systems the policy is supposed to govern.
A policy template pre-mapped to all 22 CMMC AC practices reduces that to a customization exercise. You fill in the tool names, the specific timeouts, the names of the people responsible. The structure, the practice mapping, and the formal policy language are already there.
Our CMMC Level 2 Access Control Policy template covers all 22 AC domain practices, includes a full practice mapping appendix so assessors can find what they need, and is written in formal policy language that works as evidence. Pair it with our SSP template for complete CMMC documentation coverage.
Get the Access Control Policy Template →The Access Control domain is large because access is the first line of defense for any system. It determines who gets in, what they can do, how they get there, and how you know when something goes wrong. Getting all 22 practices implemented and documented is a real project, but it's also the most impactful security work a small defense contractor can do.
The contractors who fail their CMMC assessment on Access Control don't fail because they don't care about security. They fail because the gap between what they do and what they can prove they do is too wide. A formal policy closes that gap.
Start with the policy. Build the evidence around it. When an assessor arrives, you'll be ready.
No spam. Just practical guidance on CMMC compliance and new resources when we publish them.