After working through CMMC assessments from both the preparation side and the evidence review side, the failures almost always come from the same places. Here's what's actually happening during a Level 2 assessment, domain by domain, and how to not become a cautionary tale.
There's a persistent misconception that a CMMC assessment is primarily a document review, that if you have enough policies and procedures, you'll pass. That's not how it works. A Level 2 assessment has three distinct phases, and documents are only one part of the picture.
Before the assessors arrive (or join the call), they review your System Security Plan (SSP), supporting policies, network diagrams, and any pre-submitted evidence. This phase typically takes 1–2 days and sets the tone for everything that follows. Assessors are looking for: internal consistency (does the SSP match your network diagram?), completeness (are all 110 practices addressed?), and credibility (does the control implementation description match what a company your size would realistically have deployed?). A thin SSP signals that the environment is thin. A detailed SSP that contradicts the network diagram signals that the SSP was written by someone who didn't look at the actual environment. Neither is a great look.
Assessors conduct structured interviews with personnel at multiple levels: executive/management (governance, policy awareness, responsibility), IT administrators (technical implementation, system configuration, account management), and end users (security awareness, procedure compliance, incident reporting). Interviews validate that the controls described in your SSP are actually understood and practiced by the people responsible for them. An IT admin who can't describe your password policy, or who describes it differently than the SSP does, is an assessment problem.
Assessors examine technical evidence directly: screenshot walkthroughs of configurations, live demonstrations of controls, log samples, and system queries. They'll look at Active Directory (Microsoft's directory service that controls user accounts, group policies, and access permissions across Windows environments) settings, Azure AD Conditional Access policies (rules that automatically enforce requirements like MFA based on conditions such as user role, device compliance, or sign-in location), audit log configurations, endpoint security baselines, and patch management records. The key word is examine, not penetration test, not red team. They're verifying that the configuration you described in the SSP is actually in place. But they're methodical, and they know what to look for.
Access control is the largest domain and the most common source of NOT MET findings. The two most frequently failed areas are least privilege and remote access controls. Least privilege failures typically look like: administrator accounts used for day-to-day work, service accounts with excessive permissions that haven't been reviewed since they were created, and shared accounts that can't be attributed to individual users. Remote access failures center on VPN configurations that don't enforce MFA, or remote desktop access that's exposed without adequate controls.
The most common CM failure: no documented baseline configuration. Assessors will ask for your baseline configuration documentation for endpoints, servers, and network devices. "We follow CIS Benchmarks" (security configuration guides from the Center for Internet Security, Level 1 covers basic hardening, Level 2 adds higher-security controls) is a start, but you need to show that you've documented which CIS Benchmark level you target, verified your endpoints against it, and have a process to detect and remediate drift. Software restriction policies (CM.L2-3.4.7/3.4.8), controlling which software is permitted to execute, is frequently not implemented at all, particularly in smaller organizations that haven't deployed application whitelisting or an endpoint security platform with that capability.
MFA is the centerpiece of IA failures. The common gap isn't a total absence of MFA, most organizations have MFA turned on for something. The failure is incomplete coverage: MFA for Microsoft 365 but not for VPN, or MFA for external-facing systems but not for privileged accounts accessing internal infrastructure. MFA everywhere except the one door that actually matters, a classic. IA.L2-3.5.3 requires MFA for local and network access to privileged accounts, and for network access to non-privileged accounts, which is broader than many organizations have implemented. Password management failures are the second most common IA finding: minimum length not enforced, complexity not configured, no lockout policy, or stale accounts from departed employees still active.
SI failures cluster around three areas: malware protection coverage gaps (endpoints not covered by EDR or AV, or signature updates not current), patching cadence (no documented patch management process or evidence of patches being applied within a defined window), and security alert monitoring (no process to review security alerts from endpoint protection tools or SIEM). The question assessors ask is: "Who reviews security alerts, at what frequency, and what's the escalation path?" If the answer is "our EDR sends emails to an inbox that nobody checks systematically," that's a finding.
Audit and accountability failures are almost always about retention and review, not enablement. Most organizations have audit logging turned on, Windows event logs exist, Microsoft 365 unified audit log is enabled, VPN logs are generated. The failure is that: (1) logs aren't being retained for the required period (AU.L2-3.3.1 requires logs be retained as long as necessary to support after-the-fact investigation), (2) nobody is reviewing the logs, and (3) there's no alerting on anomalous events. Assessors will ask for a log sample, ask how long logs are retained, and ask who reviews them and how often. If your answer to "how long are your Azure AD sign-in logs retained?" is "I'm not sure," you have a problem, Microsoft 365 E3 retains those logs for only 30 days by default, which is often insufficient.
The System Security Plan is not a bureaucratic checkbox. It is the document that frames the entire assessment. Assessors read your SSP during Phase 1, and they build their interview questions and technical test cases from it. A weak SSP is self-defeating in two ways.
First, a thin SSP, one that describes controls at a high level without specifics, gives assessors nothing to validate. They will probe deeper in interviews and technical testing to fill in what the SSP left vague. An SSP that says "MFA is implemented" without specifying which accounts, which systems, and which enforcement mechanism is an invitation to dig into every MFA gap your environment has.
Second, an SSP that contradicts your actual environment is worse than a thin SSP. If your SSP says "all privileged accounts are separated from standard user accounts" and your Active Directory shows your IT admin using a single account for everything, that contradiction is not just a finding, it raises questions about the credibility of every other control described in the SSP.
The SSP must describe the environment as it actually is, not as you wish it were. If a control isn't fully implemented, the SSP should reflect that honestly, that's what POA&M items are for. An SSP that overclaims implementation status will be contradicted by evidence, and that's a harder position to recover from than an honest gap with a documented remediation plan.
Under 32 CFR Part 170, a CMMC Level 2 certificate can be issued conditionally when open Plan of Action and Milestones (POA&M) items exist, but the rules on what can be deferred are specific, and this is an area where organizations frequently misunderstand their options.
What can generally be deferred: Controls that are partially implemented and progressing toward full implementation, controls that require significant infrastructure investment and have a documented remediation timeline, and non-critical gaps with compensating controls in place. POA&M items must have a specific remediation date, a responsible party, and milestone checkpoints, not just "we'll fix this eventually."
What cannot be deferred: Fundamental CUI protection controls, particularly full MFA deployment, basic audit logging, and any practice that represents an active and unmitigated risk to CUI. Assessors (and the DoD contractor officer reviewing your certification) have discretion here, but controls assessed as NOT MET where there's no compensating control and no evidence of partial implementation are typically not deferrable. The guideline to remember: a POA&M is for a gap in an otherwise functional security program, not for a missing security program.
Timing matters: Arriving at an assessment with a complete POA&M (items documented, dates assigned, milestones clear) signals a mature security posture, you know your gaps and you're managing them. Arriving with no POA&M and discovering gaps during the assessment is a significantly worse position. Start your POA&M during your readiness assessment, not after your C3PAO assessment.
End users are often the weakest link in assessment prep, not because they're careless, but because nobody briefed them on what an assessor would ask about their daily work.
These three assessment outcomes have specific meanings under NIST SP 800-171A, and understanding them matters for how you prepare and how you respond to findings.
MET requires more than saying a control exists. Evidence must demonstrate implementation. "We have a policy" is not sufficient to support a MET finding for a technical control, the policy and the technical implementation must both be present.
NOT MET is the finding you want to avoid, but it's also the honest finding if a control isn't implemented. NOT MET findings must either be remediated before the assessment concludes (if the remediation is quick) or captured in a POA&M. An organization that receives multiple NOT MET findings across critical domains without compensating controls will not receive a CMMC certificate at that assessment, conditional or otherwise.
NOT APPLICABLE is frequently misused. Organizations apply it to practices they simply haven't implemented, rather than practices that genuinely don't apply to their environment. Assessors know the common NOT APPLICABLE scenarios (no portable storage in the environment, no public-facing systems, no external connections to CUI systems) and will push back on NOT APPLICABLE claims that aren't supported by the environment description. Every NOT APPLICABLE finding must be documented with justification in your SSP.
Gap analysis against all 110 NIST SP 800-171 practices. Produce your initial POA&M. Identify documentation gaps and technical remediation items. This is where you discover what you actually have vs. what you think you have.
Address the highest-priority findings from your readiness assessment. Prioritize: full MFA deployment, audit logging and retention, access control gaps, documented configuration baselines. Complete or update your SSP to accurately reflect current state.
Compile screenshots, policy documents, system configuration exports, training records, and log samples for each practice. Organize by domain. Brief your IT admins on the interview process and the controls they're responsible for describing.
Assessors review SSP and submitted evidence off-site. You may receive clarifying questions. Respond promptly and completely.
Interviews with management, IT, and users. Technical walkthrough of key controls. Live configuration reviews. Assessors will document findings in real time.
C3PAO delivers assessment report. Review all NOT MET findings. Finalize POA&M with remediation dates. Conditional certificate issued if POA&M items are acceptable. CMMC certificate submitted to CMMC database (eMASS).
The three documents C3PAO assessors review first, professionally written, NIST SP 800-171 aligned, and ready to customize for your environment.
Editable .docx / .xlsx · Instant download · 30-day guarantee
For a small organization (under 50 employees) with a limited CUI environment, a Level 2 assessment typically takes 3–5 business days of active assessment activity, document review, interviews, and technical testing. Larger environments with complex boundary definitions, multiple facilities, or significant inherited infrastructure can take 2–3 weeks. Add 4–6 weeks before the assessment for document preparation and evidence package assembly.
MET means the practice is implemented and evidence demonstrates it. NOT MET means the practice is not implemented or evidence is insufficient, this requires either remediation before the assessment concludes or a POA&M entry. NOT APPLICABLE means the practice doesn't apply to your environment (e.g., no portable storage in your CUI boundary). NOT APPLICABLE requires documented justification, assessors don't accept it without evidence that the practice genuinely doesn't apply to your specific environment.
Yes, but only for certain practices and within limits. 32 CFR Part 170 allows a conditional CMMC certificate to be issued when open POA&M items exist, provided those items don't represent practices essential to CUI protection and they have documented remediation timelines. However, practices assessed as NOT MET for fundamental controls, MFA, access control, audit logging, are unlikely to be accepted as deferrable. C3PAOs have discretion here, and the DoD contracting officer has final say on acceptability.
The SSP must describe your system boundary (what's in scope), all 110 NIST SP 800-171 practices and how each is implemented, your network architecture, data flow for CUI, responsible parties for each control, and inherited vs. implemented controls. Assessors read the SSP before the assessment begins, a thin or incomplete SSP signals that the implementation is likely thin too. The SSP sets expectations that interviews and technical testing then validate or contradict.
The most common failure modes are: (1) MFA not fully deployed, especially for privileged accounts or VPN access; (2) audit logging not enabled or logs not retained long enough; (3) SSP that doesn't match what's actually deployed; (4) no documented configuration baselines; and (5) access control gaps, particularly excessive privileges and unreviewed accounts. These five issues account for the majority of NOT MET findings across assessments.
As of the current rule (32 CFR Part 170), most CMMC Level 2 contractors must use a C3PAO for a third-party assessment. A subset of Level 2 requirements may permit annual self-assessment with affirmation by a senior official, the specific contracts subject to self-assessment vs. third-party assessment are designated at the contract level. When in doubt, assume you need a C3PAO. Your contracting officer can confirm which requirement applies to your specific contract.
No spam. Just practical guidance on CMMC compliance and new resources when we publish them.