Briefings · Readiness
Where CMMC readiness actually fails
Assessments rarely fail on exotic requirements. The same handful of gaps does nearly all the damage: a boundary that turns out to be wrong, cryptography that isn't validated, MFA that covers half its ground, a thin SSP, controls with no history behind them, and a service provider nobody wrote down. Every one of them is findable months in advance.
Readiness · at a glance
The short version
None of the common failures are tool gaps. They are program gaps: things nobody owned, wrote down, or operated long enough to prove. That is bad news for shortcut shopping and good news for small shops, because the fixes are discipline, not budget.
The list
Six gaps that sink assessments
Each with the failure as an assessor meets it, and what right looks like instead.
Scope that's wrong on assessment day Unmapped data flows
CUI turns out to live in corporate email, the proposal team's cloud drive, or a file share nobody mapped, and systems believed out of scope walk into the assessment unprepared. What right looks like: scope traced from actual data flows before the boundary is drawn, then policed. The scoping briefing covers the method.
Encryption that isn't FIPS-validated Most-failed requirement
SC.L2-3.13.11 is consistently among the most-failed requirements in government assessment experience, because "we use AES-256" is not the claim being assessed. What right looks like: validated cryptographic modules with CMVP certificate numbers, running in FIPS mode, protecting CUI everywhere it rests and travels, named module by module in the SSP.
MFA that stops at the VPN Missed access paths
IA.L2-3.5.3 requires multifactor for local and network access to privileged accounts and network access for everyone else, and assessments keep finding the local-admin login, the server console, or the legacy app that never got it. What right looks like: MFA coverage enumerated account by account, access path by access path, exceptions written down and defended.
An SSP that can't carry the weight Boilerplate plan
A boilerplate SSP that restates requirements instead of describing your environment gives the assessor nothing to verify, and no SSP at all means no assessment. What right looks like: a current plan that names the boundary, the assets, and how each requirement is actually implemented here, kept in revision like the controlled document it is.
Controls turned on last month No operating record
Logging enabled, an incident response plan written, reviews scheduled, all in the quarter before the assessment, with no operating record behind any of it. Evidence with no history reads as staging. What right looks like: controls run as habits, with reviews held, exercises conducted, and logs read, and the records accumulating as a byproduct. History is the one thing that cannot be backfilled.
An MSP arrangement nobody documented No responsibility matrix
"Our IT provider handles that" answers none of the 320 objectives. Inherited controls fail when nobody can show who does what, or when CUI sits in a cloud service that was never FedRAMP Moderate to begin with. What right looks like: a shared responsibility matrix with an owner for every requirement, and provider claims verified rather than assumed.
The safety net that isn't
What a POA&M actually forgives
The plan of action and milestones is widely imagined as the escape hatch: pass now, fix later. The final rule made it narrow. Conditional status requires a minimum score of 88 out of 110. Only one-point requirements may sit on the POA&M at all, which excludes every three- and five-point requirement on the board, with a single exception: CUI encryption may be deferred if encryption is genuinely in place but not yet FIPS-validated. And the whole plan must be remediated and reassessed within 180 days, or conditional status lapses.
Read that against the list above: wrong scope, missing MFA, and an inadequate SSP are not POA&M-able problems. The POA&M forgives loose ends. It does not forgive foundations.
Straight answers
Asked and answered
What's the single most-failed requirement?
FIPS-validated cryptography, by reputation and by government assessment experience. Not because encryption is hard, but because contractors prove the wrong claim. Validated modules, CMVP certificates, FIPS mode, named in the SSP.
How long does readiness take?
For a small contractor starting honestly: months, not weeks, commonly six to eighteen depending on scope and starting point. The floor is set by operating history, which accumulates in real time no matter how fast the technical work goes.
Can't we just buy a tool for this?
No tool owns your scope, writes your SSP truthfully, holds your reviews, or runs your incident exercise. Tools help; the gaps that fail assessments are program gaps. That is a discipline problem, which is why our answer to it is a program, not a dashboard.
Where do we even start?
Scope first, meaning where CUI actually lives, then the SSP, then the gaps in priority order, operating as you go so history accumulates. If you want the sequence already engineered, that is literally what the 93-step program is.
Sources
- 32 CFR Part 170, the CMMC Program final rule (scoring, POA&M limits, conditional status, 180-day closeout)
- NIST SP 800-171A (assessment objectives behind each requirement)
- DoD CIO CMMC documentation: Level 2 Assessment and Scoping Guides
- NIST Cryptographic Module Validation Program (CMVP) (what "FIPS-validated" actually means)
Next up
A scoping call reads your environment against this list and tells you where you actually stand, including when the honest answer is that you're closer than you think.
Schedule a Demo