Summary: After conducting multiple CMMC Level 2 assessments, certain problems show up repeatedly. Not for a lack of trying, but because organizations seeking certification (OSC) are preparing for the wrong thing. Most failures are neither documentation nor technology related. Rather, they are consistency failures: when an organization cannot clearly and completely show how Controlled Unclassified Information (CUI) is protected across its people, systems, and processes.
Everyone knows CMMC Level 2 assessments validate compliance with the 110 NIST SP 800-171 security requirements by leveraging the associated NIST SP 800-171A’s three assessment methods: examination, interviews, and testing. What’s missing for OSCs is the fact that CMMC isn’t just a technical solution. Assessors are validating the environment and associated program (administrative and operational) protecting the CUI environment. That means your technical configuration alone cannot tell the full story. Documentation and people need to tell the same story across system posture, evidence, and interviews, or the assessment breaks down.
Below are five areas where that assessment story most often falls apart.
1. CMMC Scope: Don’t guess at CUI assets, follow the data
Scoping is the most important, yet the most underestimated part of the assessment. The most common scoping mistake is starting with your preferred tools or boundary, instead of starting with the data, or the CUI. The right questions to ask are: where does CUI live? Where is it created, received, stored, processed, transmitted, exported, displayed, discussed, shared, printed, backed up, and destroyed?
Every person, system, and service that touches CUI or protects access to it belongs in your scope. Assets must be identified precisely in accordance with the DOD’s CMMC Level 2 Scoping Guide. The boundary includes the obvious: file repositories, emails, and endpoints. But the assessment also includes the less obvious items: ticketing systems, project management and engineering tools, source code repositories, collaboration platforms, remote access paths, print workflows, backups, logs, SIEM integrations, and managed service providers (MSPs). These latter assets, or your Security Protection Assets (SPAs), may not be within your CUI environment directly but they help secure the environment and as such will be assessed.
Problems arise when organizations scope by aspiration rather than the actual data flow. They may describe a secure environment on paper, then interviews reveal that CUI is still being emailed outside of it, saved locally, printed, or shared with subcontractors through channels that are outside the documented process. At that point, you no longer have a diagram problem but a credibility problem, and that is much harder to recover from during an active assessment.
Assessor Takeaway:
Build your scope from CUI data flows, not from your organization chart or preferred technology architecture.
2. Shared Responsibility Matrix (SRM) for CMMC: An important operating layer
While a Shared Responsibility Matrix (SRM) is not a CMMC requirement, it is one of the most useful tools your organization can build, especially when multiple parties contribute to security (e.g., cloud services, managed service providers, corporate IT, program teams).
Now, you might be wondering: Why does that matter? CMMC assessments evaluate whether the organization has implemented each requirement. If responsibility is split across parties, you need to know precisely who does what, who owns the evidence, and who can explain the implementation in an interview.
The best SRMs map to the assessment objective level, and not just the control level, because that is where the actual assessment work happens. This matters because assessment work is performed against the NIST SP 800-171A objectives, not simply a high-level list of 100 requirements. For example, one party may configure multi-factor authentication, a second may manage identity governance, and a third may handle alert monitoring. Finally, a fourth party may approve privileged access requests. Treating the requirement as a single block hides those splits in responsibility.
A strong SRM identifies the requirement, the assessment objective, the responsible party, the supporting party, the implementation location, the evidence source, the interview owner, and any inherited or externally managed components.
Assessor Takeaway:
An SRM does not replace implementation but rather demonstrates that your organization understands and governs implementation across all responsible parties. Let the SRM be the assessor’s roadmap during the assessment.
3. System Security Plan (SSP): Right wording, wrong facts
Documentation is a major failure point. Most organizations have too many documents. The problem is that those documents often describe what the organization intends to do (the theory), not what it currently does (actual operating environment).
As CCAs, we have witnessed three common patterns that appear:
- First, documentation does not match the actual environment or business processes. The System Security Plan (SSP) states encryption is enforced everywhere, but the technical configurations show exceptions. The access control procedure describes an approval workflow that the ticketing system does not reflect. The incident response plan names roles that no longer exist.
- Second, implementation statements restate the requirement instead of explaining how the requirement is implemented. Saying “we will restrict access” or “we will monitor system activity” is not an implementation statement, but an intention. An assessor needs to understand what is configured, where it is configured, who operates it, how often it occurs, what evidence supports it, and how exceptions are handled.
- Third, the SSP contradicts itself internally. One section restricts all CUI to a controlled environment while another permits local downloads. One policy calls for annual access reviews, while the procedure says quarterly. Those conflicts raise questions about whether the documentation represents the environment at all.
Good documentation needs to be accurate, current, and verifiable; specific enough that the technical team recognizes it as true, the control owner can explain it without reading from a script, and evidence can be mapped directly back to the stated implementation.
Assessor Takeaway:
Your SSP should describe how CUI is protected today within the assessed environment, not how you plan to protect it in the future.
4. Operationalizing CMMC Compliance: Policies and procedures must show up
This is often the most common challenge we encounter. Most OSCs can produce policies, procedures, system diagrams, and evidence repositories. Few can genuinely show that those documents reflect how the business runs day to day.
CMMC assessments connect technical configuration, documentation, evidence, and interviews into a single chain. If configurations say one thing, but your SSP says another and the artifacts show a different story, and the interviewee cannot explain the process, the assessment story ultimately breaks and assessors notice.
Interview preparation is about making sure the people responsible for a security process truthfully understand it: what they do, why they do it, how it connects to the requirement being assessed. Operational confidence is often what distinguishes a genuine security process from a documentation exercise.
This is where many organizations discover their CMMC program has been managed as a project focused on producing documents, instead of as an ongoing security program. A project creates documents. A program creates consistent behavior: access reviews happen on schedule, alerts get triaged, vulnerabilities are tracked, changes go through approval, backups are tested, risks are reviewed, and exceptions are documented and governed.
Assessor Takeaway:
The strongest assessments show consistency across documentation, evidence, system configurations, and interviews.
5. Risk assessments and incident response under NIST SP 800-171: Foundational activities are missing
Risk assessments and incident response exercises are two activities that are foundational but routinely underprepared. Both are among the strongest signals that your security program is active rather than theoretical.
A risk assessment should reflect your actual CUI environment that identifies threats, vulnerabilities, likelihood, impact, and response decisions. It should inform your priorities, your Plan of Action and Milestones (POA&M), and management decision-making. A generic or outdated risk assessment disconnected from real operations does not serve your assessment nor your security program.
Incident response exercises are equally important. An unexercised plan is an untested assumption. The requirement is clear: exercise the plan, involve the right roles, identify lessons learned, and update procedures based on what you find. Personnel who have participated in exercises also tend to perform better in interviews. They understand their role, the escalation path, and how decisions get made.
Assessor Takeaway:
Risk assessment and incident response testing are the core evidence that your security program is running, not just documented.
Final Thoughts
The organizations that do well are not always the ones with the most polished documentation or the most expensive technology. They are the ones who can tell a consistent, evidence-based story about how CUI is protected in their environment, from scope to implementation to the people responsible for running it.
CMMC assessment readiness is not a finish line you cross by assembling documents at the last minute. Instead, it reflects that security has become part of how your business works. That shift is what most OSCs are still working toward, and it is what matters most as CMMC assessment continues to mature.
Is Your Organization Getting Ready for Assessment?
Our CMMC team will help you better understand where you currently stand and what to address before your assessment. Book a consultation with our lead CCA today.
