5 Reasons CMMC Controls Fail Assessment Even When Implemented
The most frustrating outcome in a CMMC Level 2 assessment is receiving a finding on a control you believed was implemented. It happens regularly. Contractors invest months in remediation, stand up the technical infrastructure, draft the policies, and walk into the assessment confident — and then generate findings on controls that were, in fact, functioning correctly in their environment.
The cause is almost never the control itself. It is almost always the gap between implementation and provability. A C3PAO assessor is not evaluating whether your controls are working. They are evaluating whether you can demonstrate that they are working, to a trained examiner, using methods the assessment defines. Those are related but distinct standards.
Understanding the specific failure patterns that turn implemented controls into findings — and addressing them before the assessment — is the highest-leverage preparation work you can do in the weeks before your C3PAO arrives.
Failure Pattern 1: The SSP Describes a Future State, Not the Current State
The System Security Plan is the foundational document of your CMMC assessment. Every practice the assessor evaluates during the Examine method will be measured against what the SSP says is in place. If the SSP describes a planned or aspirational state rather than the environment as it currently exists, you will generate findings on controls that are correctly implemented.
This failure pattern is extremely common. Contractors build an SSP early in their CMMC preparation to plan their implementation roadmap. The SSP gets written to describe what the environment will look like when remediation is complete. Remediation then proceeds — but the SSP does not get updated to reflect what was actually deployed. When the assessor examines the SSP and then tests the live environment, the two descriptions do not match. That inconsistency is a finding even when the technical implementation is correct.
Your SSP must describe what is in place right now, not what you intend to build. This means the SSP is a living document that requires updates whenever a relevant change is made to your environment. The review should be dated, and the update history should be visible. When an assessor asks when the SSP was last reviewed and the answer is "before we stood up MFA on the endpoint management platform," that is a problem — regardless of how well MFA is currently functioning.
Failure Pattern 2: Evidence Assembled for the Assessment Does Not Reflect Normal Operations
Assessment evidence has to demonstrate that your controls are operational in the normal course of business — not that they were operational during the assessment window. Assessors are experienced enough to distinguish between evidence that represents an ongoing operational posture and evidence that was generated specifically for the assessment.
Audit logs that were activated the week before the assessment will not show a history of normal operations. Configuration baselines that were documented in the month before the assessment but show no enforcement history raise questions about whether those baselines were being maintained before preparation began. Training records that show all staff completed awareness training in the thirty days before the assessment, with no prior-year records visible, suggest that training was not an ongoing program.
When assessors identify this pattern during the Test method, they will follow up during Interview. They will ask specific questions: When was this policy last reviewed? Who approved this configuration change? Can you show me log samples from three months ago? If your evidence only exists for the assessment, it will not hold up under that scrutiny. The evidence needs to reflect your actual operational posture, which means your operational posture needs to be assessment-ready at all times — not staged for a specific window.
Failure Pattern 3: Interview Inconsistency Between Documentation and Staff Descriptions
Your documentation can be accurate and current. Your technical implementation can be correct. And you can still generate a finding because the staff member interviewed about a specific control describes a process that differs from what the SSP says.
This failure pattern appears most often when policies and procedures are written by an external consultant or compliance advisor and the internal technical team was not involved in drafting them and has not read them carefully. The technical team knows what they actually do. They will describe it accurately. But if what they actually do differs in any procedural detail from what the SSP says they do, the assessor will treat that inconsistency as a reliability signal.
One inconsistency does not just create a finding for the control being discussed. It raises questions about all of your evidence. Assessors interpret interview inconsistency as an indicator that documentation may not reflect operational reality — which means they will probe more deeply in subsequent Examine and Test activities.
The resolution is not to coach staff on scripted answers. It is to ensure that the people responsible for maintaining controls have read the relevant SSP sections and can accurately describe what is implemented and why. Interviewed staff should be accurate and consistent. That requires that the SSP accurately describes what staff are doing, and that staff are familiar enough with the SSP to confirm it.
Failure Pattern 4: Scope Confusion About Which Systems Require Demonstrated Controls
Contractors sometimes believe that systems outside the defined CMMC assessment boundary do not need to have their controls demonstrated. That belief can be accurate — but only if the boundary itself is clearly defined, accurately documented, and defensible under assessor scrutiny.
If a system outside the claimed assessment boundary has network connectivity to CUI-bearing systems and that connectivity is not properly isolated, segmented, and documented, the assessor may expand the scope of the assessment. What began as a bounded assessment of a defined CUI enclave can expand to include systems you did not prepare for — because the boundary documentation did not adequately support the exclusion.
Your network architecture documentation and asset inventory need to clearly define what is in scope, what is out of scope, and how CUI flows through your environment. The boundary documentation needs to answer the assessor's questions before they ask them: What systems are in the enclave? What systems have connectivity to enclave assets? What controls prevent CUI from transiting out-of-scope systems? Where does CUI originate, where does it go, and what enforces that path?
Boundary ambiguity is always resolved in the direction of expanded scope. A defensible boundary is one that holds up under examination of actual network flows and actual CUI handling practices — not just one that is drawn clearly on a diagram.
Failure Pattern 5: Treating POA&Ms as a Mechanism to Defer Any Finding
A Plan of Action and Milestones documents a planned remediation for an assessment finding. It is an important part of the CMMC framework, and it is not a mechanism to defer all findings indefinitely.
Contractors who overrely on POA&Ms as a way to defer remediation work sometimes discover late in the assessment process that certain findings are not deferrable under current CMMC rulemaking guidance — or that the aggregate of deferred findings, even individually deferrable ones, creates a threshold problem that prevents certification from being granted.
Before your assessment, you need to know which of the 110 practices carry zero tolerance for open findings. That list is not long, but the practices on it tend to be foundational. Knowing in advance which controls must be fully remediated before the assessment begins — and which can be addressed through an accepted POA&M — allows you to allocate your remediation effort correctly. Discovering those constraints during the assessment is far more disruptive than addressing them in your preparation timeline.
What to Do Before the Assessor Arrives
Six preparation steps address the failure patterns described above. These are not checkbox exercises. They are the structural work that separates contractors who pass from contractors who generate findings on controls they believed were ready.
Audit your SSP for current-state accuracy. Go section by section and verify that every described control reflects what is actually implemented and operational today. Date-stamp the review. This is not a one-time exercise. It should be updated anytime a relevant change is made to your environment.
Map your evidence artifacts to each of the 110 practices. For every practice, identify what documentary evidence exists, which personnel can speak to it in an interview, and how it can be demonstrated technically. If you cannot answer all three for a given practice, that is a gap that needs to be addressed before the assessment.
Conduct internal evidence walkthroughs using the Examine, Interview, Test framework. Do not review documents internally and stop there. Sit your system administrator down and walk through what an assessor would ask. Does their verbal description match the SSP? Can they pull the relevant logs on demand? Does the live system configuration match what the documentation describes?
Validate your assessment boundary documentation. Your network diagram and asset inventory need to clearly define what is in scope, what is out of scope, and how CUI flows through your environment. Boundary ambiguity invites scope expansion. Review it the way an assessor would — looking for connectivity paths that could pull out-of-scope systems into the assessment.
Review your open POA&M items and classify them by criticality. Identify which findings are deferrable under current guidance and which are not. Close or remediate any practice that cannot be deferred before the formal assessment begins. Do not walk into an assessment with open findings in zero-tolerance control areas.
Brief all personnel who may be interviewed. This means ensuring that the people responsible for your controls have read the relevant SSP sections and understand what is implemented and why. The goal is accuracy and consistency — not rehearsed answers, but genuine familiarity with what is in place.
Preparation Is Not Gaming the System
Knowing what the assessor is looking for before they walk in the door is not an attempt to game the assessment process. It is the correct approach to the work. The assessment is a structured verification process, and preparing to that structure — understanding the methods, closing the documentation gaps, ensuring staff can accurately describe what is in place — is what it means to be genuinely ready.
If your controls are implemented but your evidence does not support them, you are not ready. If your SSP is current but your staff describe a different process, you are not ready. Readiness means all three methods of assessment — Examine, Interview, and Test — will produce consistent, sufficient evidence across every practice being evaluated.
Download the Free Resource
The CMMC Level 2 Assessment Evidence Guide is a control family-by-control family reference that maps each of the 110 practices to the artifacts assessors commonly request across the Examine, Interview, and Test methods. If you are closing documentation gaps and need to know exactly what evidence is expected for each practice, this guide provides that reference before your assessor asks for it. Download it now.
