The 5 Most Common CMMC Assessment Failures

Why Assessment Failures Are Predictable

CMMC Level 2 assessments evaluate 110 security requirements across 14 control families. Assessors from Certified Third-Party Assessment Organizations (C3PAOs) follow a structured methodology that includes reviewing documentation, interviewing personnel, and testing technical configurations. After hundreds of assessments, patterns have emerged: most failures cluster around a handful of recurring deficiencies that contractors routinely underestimate or misunderstand.

Passing an assessment on the first attempt matters — a failed assessment must be remediated and re-assessed, adding cost and delay. Understanding where contractors most commonly fall short lets you address those areas proactively.

1. Access Control Gaps (AC Domain)

The Access Control family (17 requirements) is the largest in NIST 800-171 and one of the most frequently deficient. Common failures include:

• No formal documented process for provisioning and deprovisioning user accounts. Assessors look for evidence that access is granted based on least privilege and revoked when employees leave or change roles.
• Privileged accounts used for routine work. Administrators who use their admin credentials for daily tasks — browsing the web, reading email — create unnecessary exposure. NIST 800-171 requires separation of privileged and non-privileged functions.
• No review of access rights on a defined schedule. Requirements 3.1.1 and 3.1.2 require limiting system access to authorized users and transactions. Assessors expect to see periodic recertification of access rights, not just initial provisioning.

The fix: implement a formal Access Control Policy, document your provisioning process in a procedure, and conduct at least an annual review of all user accounts with evidence (screenshots, reports) that the review occurred.

2. Missing or Incomplete Multi-Factor Authentication (IA Domain)

Requirement 3.5.3 — the mandate for multi-factor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts — is one of the highest-weighted controls in the DoD Assessment Methodology. It is also one of the most commonly failed.

The typical failure mode is not a complete absence of MFA, but incomplete coverage. Contractors often implement MFA for their primary business applications but overlook remote desktop access, VPN connections, cloud management consoles, or legacy systems. Assessors will probe every access path into the environment. If any path to CUI-bearing systems permits authentication with just a password, the control is Not Met.

Also commonly missed: MFA for accounts that access CUI even indirectly. A user who can access a shared drive containing CUI must use MFA, not just users with elevated privileges.

3. No Documented Incident Response Plan (IR Domain)

NIST 800-171's Incident Response family (3 requirements) appears deceptively simple, but the documentation standard it demands is specific. Requirement 3.6.1 requires establishing an operational incident-handling capability that includes preparation, detection, analysis, containment, recovery, and user activities. Requirement 3.6.2 requires tracking, documenting, and reporting incidents to designated officials.

Many contractors claim to have an incident response capability but cannot produce a documented plan. Assessors want to see: a written IR plan that covers each phase, defined roles and responsibilities, contact information for reporting to the DoD (US-CERT reporting requirements under DFARS 252.204-7012 for cyber incidents), and evidence that the plan has been tested or exercised. A plan that exists only in someone's head is not a plan — it is an unmet requirement.

4. Undocumented or Incorrectly Scoped System Boundaries (CA Domain)

The Security Assessment family includes requirements around documenting system boundaries (3.12.4 — System Security Plan). The most common failure here is not the absence of an SSP but an SSP whose system boundary does not match reality.

Assessors compare the SSP system boundary description and network diagram against what they actually observe in the environment. Common mismatches: cloud storage (SharePoint, OneDrive, Google Drive) used for CUI but not included in the boundary; contractor-owned laptops used to access CUI from home networks that are not addressed; managed service provider connections that touch the environment but are not documented as external connections.

An incomplete boundary is a material finding because every control assessment is scoped to the boundary. If a system is in scope but not in the documented boundary, the controls applied to it cannot be credited.

5. Policies That Exist but Are Not Enforced

This is perhaps the most frustrating failure category because the documentation exists — the problem is the gap between the written policy and actual practice. Assessors are specifically trained to identify this pattern through a combination of document review, personnel interviews, and technical testing.

A classic example: a password policy that mandates 12-character minimum passwords and 90-day expiration, but Active Directory Group Policy is configured for 8-character minimums and no expiration. The document says one thing; the system does another. The control is Not Met.

Another common version: an acceptable use policy that prohibits installing unauthorized software, but endpoint devices have no application control or deny-listing in place, and staff interviews reveal that no one enforces the policy. Having the right policies on paper is necessary but not sufficient — the policies must be implemented through technical controls and demonstrated through evidence of enforcement.

The remedy is to audit your technical configurations against your documented policies before the assessment and resolve every discrepancy. Where technical enforcement is not feasible, compensating controls and procedural controls must be documented and demonstrably practiced.