The System Security Plan Mistakes That Slow Down a CMMC Assessment

"We have an SSP. Why did the assessment stall out?"

We hear a version of this question from companies that did the work: they wrote a System Security Plan (SSP), filled in all 110 practices required under the Cybersecurity Maturity Model Certification (CMMC) program, and walked into a readiness review or an actual assessment feeling reasonably confident. Then the assessor starts asking for evidence behind specific line items, or walks the floor and finds a system the SSP never mentioned, and the confidence evaporates. The document existed. It just wasn't ready to be tested against the real environment.

That gap, between having an SSP and having an assessment-ready SSP, is where a lot of otherwise well-prepared organizations lose time. Here's what usually causes it, and how to catch it before an assessor does.

What an SSP actually has to do

An SSP is the core document describing how your organization implements each applicable NIST SP 800-171 practice: what's in scope, how each requirement is actually implemented, who's responsible for it, which systems are involved, and what evidence backs up the claimed status. Under the CMMC program rule, an organization has to have a current SSP in place at the time of a Level 2 certification assessment describing every information system inside the assessment scope; the regulation is explicit that an assessment can't be completed without one (32 CFR 170.24).

That same rule sets a real bar for evidence: it has to be in final form, not a draft, and things like working papers or unapproved policies don't count. A Plan of Action and Milestones (POA&M) covering a NOT MET practice doesn't substitute for the practice actually being implemented, either (32 CFR 170.24). Assessors working from NIST SP 800-171A break each of the 110 requirements down into specific assessment objectives (roughly 320 of them across the full set) and evaluate each one by examining documents, interviewing staff, and testing the actual mechanism. Writing an SSP entry that satisfies the requirement in general terms but doesn't hold up against that level of granularity is one of the most frequently cited implementation mistakes in current CMMC coverage (Secureframe, "7 Biggest CMMC Implementation Mistakes," June 2026).

For Level 2, that assessment is typically conducted by a Certified Third-Party Assessment Organization (C3PAO). Level 3 assessments, which build on Level 2 with additional NIST SP 800-172 practices, are conducted by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC), a government body. Both are looking for the same underlying thing: a plan, backed by proof, that matches the environment in front of them.

The problems we see most often

None of the following is an official published "top findings" list from a regulator; it's what shows up repeatedly in current CMMC readiness work, including a recent industry summary of common SSP-related gaps found during 2026 readiness reviews (Datasure24, "Top Findings from CMMC Readiness Assessments in 2026," August 2026), plus what we've observed doing this work ourselves. Consider it a pattern to watch for, not a checklist an assessor will read off verbatim.

• Policy without proof. The SSP describes a control that exists on paper, but nobody can produce the configuration export, screenshot, log sample, or ticket record an assessor would actually need to confirm it's real and current.

• A boundary that doesn't match reality. The described system boundary leaves out shadow IT, a legacy server nobody decommissioned, or personal devices that still touch Controlled Unclassified Information (CUI) in practice.

• A document that's fallen behind the environment. New tools, a new office, new staff, or an infrastructure change happened after the SSP was last updated, and the document still describes the old setup.

• POA&M items that aren't really a plan. Milestones are vague, dates have quietly passed, or nobody owns the item anymore, which reads to an assessor as remediation that's stalled rather than in progress.

• "Met" without a trail. A practice is marked Met in the SSP, but there's no clear evidentiary path from the requirement to something an assessor can independently verify.

The recurring theme across all five is the same: a written policy is necessary, but it isn't sufficient. Assessors are looking for policy, implementation, and evidence that the implementation is real and current, together. A policy statement with nothing behind it reads as aspirational, not implemented.

A short example

Picture a 50-person manufacturing subcontractor preparing for a Level 2 assessment. Its SSP states, correctly as originally written, that all endpoints are centrally managed through the company's endpoint protection platform, satisfying several NIST SP 800-171 practices around configuration management and malicious code protection.

A readiness review a few weeks before the assessment turns up three laptops that were issued to new hires last quarter and never enrolled in that management platform, because the onboarding process changed and nobody updated the deployment checklist. Caught during the readiness review, it's a quick fix: enroll the devices, update the onboarding process, and note the correction. Caught by the assessor instead, it's a finding against a practice the SSP claimed was fully implemented, and now the whole surrounding narrative (including anything else the SSP claims without a visible evidence trail) gets a harder look.

What to do before the assessor finds it first

The SSP mistakes above share a fix: review the document against your actual environment, on purpose, before someone else does it for you during the assessment. In practice, that means walking each practice claimed as Met and asking whether you could hand an assessor real, current evidence for it today, not whether the policy sounds right on paper. It means physically or logically verifying the system boundary against what's actually running, not just what was documented at rollout. And it means treating POA&M items as live work with real owners and dates, not a list that gets updated once a year before an assessment.

This is our professional recommendation based on how these reviews tend to go, not a formal requirement spelled out anywhere as "you must conduct a pre-assessment SSP review." But given that the SSP is the document the entire assessment gets built around, a deliberate gap check against it is cheap compared to the alternative of an assessor finding the gap for you.

Official resources

• 32 CFR 170.24, CMMC Level 2 certification assessment requirements (Legal Information Institute, Cornell Law School)

• NIST SP 800-171 (CUI protection requirements)

• Datasure24: Top Findings from CMMC Readiness Assessments in 2026 (industry coverage)

• Secureframe: 7 Biggest CMMC Implementation Mistakes C3PAOs Are Seeing (industry coverage)

A closing note, and where ICTS USA fits

This is general informational guidance, not legal advice, and it isn't a substitute for consulting a Registered Practitioner Organization (RPO) or a Certified Third-Party Assessment Organization (C3PAO) for a specific compliance determination or assessment.

Before investing in tools, documentation, or an assessment, make sure your SSP actually reflects the environment an assessor is going to walk into. ICTS USA can help you review your SSP against your real environment, organize the evidence behind it, and identify gaps while there's still time to fix them.

Copyright © 2026 ICTS USA LLC - All Rights Reserved.