10 common gaps that can derail a CMMC Level 2 assessment

Most organizations preparing for a CMMC Level 2 assessment have already invested significant time and money in cybersecurity. They have policies. They have security tools. They may have an MSP or internal IT team managing the environment. That does not necessarily mean they are ready for an assessment.

The difference between having a security control and being able to demonstrate that it is implemented correctly is where many organizations run into trouble. Across more than 40 CMMC Level 2 assessments, we have seen many of the same issues repeatedly. Every environment is different, but these are some of the areas worth examining closely before your assessment begins.

1. You cannot clearly show where your CUI goes

Before an assessor can evaluate your controls, the assessment team needs to understand the environment those controls are protecting. That starts with Controlled Unclassified Information (CUI). Your organization should be able to explain where CUI enters the environment, where it is stored, how it moves, who can access it, and where it ultimately leaves or is destroyed. That can include email, endpoints, cloud platforms, collaboration tools, file repositories, backups, removable media, printers, service providers, and external organizations.

It is not enough to know where CUI is supposed to be. You need to understand where it actually goes. An incomplete CUI data flow can lead to an incomplete assessment scope. Once the scope is wrong, many of the security decisions based on that scope can also be wrong.

2. Your System Security Plan does not match your environment

Your System Security Plan (SSP) should describe the system that exists today. One of the most common problems is an SSP that describes what the organization intended to implement rather than what was actually implemented. Sometimes the document was written months before the assessment. Sometimes systems changed. Sometimes a consultant prepared the SSP based on planned configurations that were never fully deployed.

During an assessment, those inconsistencies become visible. If the SSP says a particular technology performs a security function, the assessment team will expect to see evidence that it does. If the SSP identifies one authentication process but employees describe another, that discrepancy will need to be understood. Before your assessment, read the SSP against the actual environment. It should describe what is happening, not what you hope is happening.

3. Multifactor authentication is implemented, but not everywhere it needs to be

Most organizations preparing for CMMC have MFA. The question is whether they have identified all of the authentication paths that need to be protected. Organizations often focus on Microsoft 365, VPN access, or their primary identity provider while overlooking other paths into the environment. Privileged accounts, local administrator accounts, network infrastructure, remote access technologies, cloud applications, legacy systems, and other administrative interfaces all deserve attention.

Do not simply ask, “Do we have MFA?” Ask, “What are all the ways someone can authenticate into our CUI environment, and have we evaluated every one of them?” That is a much more useful readiness question.

4. You use encryption but cannot demonstrate the required FIPS validation

Seeing the word “encrypted” in a product interface does not by itself establish that the applicable CMMC requirement has been satisfied. When CUI confidentiality depends on cryptography, organizations need to understand what cryptographic module is performing that protection, whether the appropriate FIPS validation applies, and whether the technology is configured to use it as intended.

This issue frequently appears with full-disk encryption, VPNs, cloud services, wireless technologies, file-transfer solutions, and other products that protect CUI. The time to establish that evidence is before the assessment. Do not wait until assessment week to begin searching product documentation for a FIPS certificate.

5. Your configuration management program exists mostly on paper

Most environments have configurations. Fewer organizations can clearly demonstrate their approved security configuration baselines, the systems to which those baselines apply, how deviations are controlled, and how changes are reviewed.

Configuration management also goes beyond producing a baseline document. Your organization should be able to explain how changes occur, who approves them, how they are tracked, and how you determine which programs, services, ports, protocols, and functionality are necessary for the environment. The assessor is looking for a repeatable process, not a document created specifically for assessment week.

6. You collect logs but cannot demonstrate what happens next

Deploying a SIEM and enabling audit logging is only part of the story. The assessment question is what your organization can actually do with those logs. Can activity be traced to individual users? Are the security-relevant events you need actually being captured? Who reviews the logs, and how frequently? What happens when suspicious activity is identified? How are audit records protected, and how long are they retained?

A dashboard full of events may show that logging technology exists. It does not necessarily demonstrate that an audit and accountability process is operating. You need both.

7. Your incident response plan has never been tested

A polished incident response plan can look excellent on paper. Then ask the people named in the plan what happens when an incident occurs. If nobody has practiced the process, the answers may be very different from the document.

Incident response requires more than having a plan. Your organization should understand its roles, escalation paths, reporting responsibilities, communications process, and technical response procedures. Testing the plan, such as through a tabletop exercise, helps demonstrate that the organization can actually execute it. It also exposes weaknesses while there is still time to correct them.

8. You scan for vulnerabilities but cannot show a consistent remediation process

Many organizations perform vulnerability scanning. The gap frequently appears after the scan. An assessor may want to understand how findings are reviewed, how risk is evaluated, who is responsible for remediation, how remediation deadlines are established, how exceptions are handled, and how the organization verifies that vulnerabilities were actually corrected.

A monthly vulnerability report containing the same unresolved critical findings month after month tells a very different story from a documented remediation process with accountable owners and evidence of closure. Scanning identifies the problem. Your process for responding to what you find is what demonstrates vulnerability management.

9. You have monitoring tools, but responsibility for monitoring is unclear

Endpoint detection, SIEM platforms, firewalls, cloud security products, and other monitoring technologies generate enormous amounts of information. Someone still needs to be responsible for watching them. During readiness activities, ask a simple question: if something suspicious happened at 2:00 p.m. today, who would see it? Then keep going. How would they see it? What would generate the alert? What would they do next? Where would that response be documented?

Whether monitoring is performed internally or by an MSP, MSSP, or other service provider, your organization should understand exactly who is responsible for each part of the process. Do not assume your provider is doing something simply because the technology is included in your service package. Verify it.

10. You wait until assessment week to organize your evidence

This is one of the most avoidable problems. Assessment week should not be the first time your organization tries to determine how it will demonstrate implementation. Evidence should be organized before the assessment begins.

That does not mean producing hundreds of unnecessary screenshots. It means knowing what evidence supports each requirement and where that evidence can be obtained. Some evidence will be documentation. Some will come from system configurations or logs. Some implementation will be demonstrated through interviews or testing. The goal is not to create an enormous evidence library. The goal is to be able to efficiently demonstrate that your organization does what it says it does.

The common thread: implementation must be demonstrable

The biggest mistake organizations make when preparing for CMMC is focusing exclusively on whether they have something. Do we have MFA? Do we have a SIEM? Do we have an incident response plan? Do we have vulnerability scanning? Those are useful starting questions, but they are not enough.

The better questions are: Is the requirement implemented correctly? Does our documentation match the implementation? Can our personnel explain the process? Can we demonstrate that the process is actually operating?

CMMC assessment is ultimately about evidence of implementation. Technology alone does not establish compliance. Policies alone do not establish compliance. A consultant telling you that you are ready does not establish compliance. Your organization needs to be able to demonstrate it.

The best time to discover these gaps is before your certification assessment begins. Review your CUI boundary. Compare your SSP against the actual environment. Test your procedures. Validate your technical configurations. Make sure responsibilities shared with MSPs and other external providers are clearly understood. And organize the evidence you expect to use. Then bring in your C3PAO.