The CMMC Level 2 Compliance Checklist

A useful CMMC Level 2 checklist is a sequence, not a control list: define where CUI lives and shrink that boundary, implement the 110 NIST SP 800-171 requirements across 14 control families with extra attention on the ones assessors fail most, write a System Security Plan that describes reality, keep a POA&M for what remains, post your score to SPRS, and build the evidence habits that let you prove all of it live. This article works through that sequence in order, calling out the specific requirements that most often come back NOT MET, based on what gap assessments keep finding across the defense industrial base.

Two ground rules before the checklist. Nothing below matters until scope is settled, because every requirement applies to every in-scope asset, so a sloppy boundary multiplies all 110 obligations. And done means provable: a control you cannot demonstrate on demand is not done, it is planned.

Step one: scope the CUI boundary

Start with contracts, not systems. Identify which contracts carry the DFARS 252.204-7012 clause and what CUI you actually receive or create under them. Then map where that data flows: file shares, email, the ERP, the shop floor machines, the subcontractor portal, the engineer's laptop. Every place it lands is in scope, along with the systems that protect those places.

Then shrink it. Most contractors do not need to certify the whole company; they need a defensible enclave where CUI lives and works. Consolidating CUI into a contained environment, whether an on-premise segment or a government cloud tenant, routinely cuts in-scope assets by more than half and turns an impossible project into a manageable one. Document the boundary and the asset categories now, because the assessor validates scoping before anything else.

As you document, use the CMMC asset categories, because the assessor will. CUI assets store or process the data itself. Security protection assets, the SIEM, the identity provider, the patching infrastructure, defend it. Contractor risk managed assets could touch CUI but are kept away from it by policy and configuration. Specialized assets cover things like shop floor machines and test equipment that cannot meet every requirement. Each category gets different assessment treatment, and the arguments you will want to make for lighter treatment only hold if the boundary documentation existed before the assessment rather than during it.

The 14 families, and where they fail

The requirement counts below add to 110. The call-outs are the ones that show up NOT MET again and again.

Access Control (3.1, 22 requirements). The largest family and the largest source of findings. The chronic misses: controlling how CUI flows inside the network (3.1.3), least privilege and separation of duties for administrators (3.1.4, 3.1.5), and the pair everyone forgets, connections to external systems (3.1.20) and portable storage limits (3.1.21). Remote access has to run through managed, encrypted paths, not whatever VPN grew there.

Identification and Authentication (3.5, 11 requirements). Multifactor authentication (3.5.3) is the single most consequential requirement in the model: five points in the scoring methodology and not deferrable on a POA&M. The common failure is partial coverage, MFA on the VPN but not on privileged local access, or service accounts quietly exempted. Password reuse rules and replay resistance round out the frequent misses.

Awareness and Training (3.2, 3 requirements). Easy points to lose: role based training for privileged users beyond the annual phishing module, insider threat awareness (3.2.3), and records showing who completed what and when.

Audit and Accountability (3.3, 9 requirements). Failures cluster on review and retention, not collection. Logs exist, but nobody reviews them on a documented cadence, nothing alerts when logging fails (3.3.4), clocks are not synchronized (3.3.7), and administrators can edit the very logs that record their actions (3.3.8).

Configuration Management (3.4, 9 requirements). Baselines that exist on paper but not in the build (3.4.1), change control without security impact analysis, no restriction on what software can run (3.4.7, 3.4.8), and a user-installed software policy nobody enforces (3.4.9).

Incident Response (3.6, 3 requirements). Three requirements, and two of them fail constantly: an operational incident response capability (3.6.1) and testing it (3.6.3). A tabletop exercise with notes counts; a template PDF does not. Know the DFARS 7012 obligation to report qualifying incidents to DoD within 72 hours, because assessors ask how you would meet it.

Maintenance (3.7, 6 requirements) and Media Protection (3.8, 9 requirements). The unglamorous middle. Equipment sent offsite without sanitization first (3.7.3), remote maintenance sessions without MFA (3.7.5), unmarked media, no destruction records when drives leave (3.8.3), and backups that hold CUI without encryption (3.8.9).

Personnel Security (3.9, 2 requirements) and Physical Protection (3.10, 6 requirements). Screen people before they touch CUI, and prove access ends the day employment does. On the physical side, visitor escort and logs (3.10.3, 3.10.4), and an answer ready for the home offices of anyone who handles CUI remotely.

Risk Assessment (3.11, 3 requirements) and Security Assessment (3.12, 4 requirements). A periodic risk assessment that produces an artifact, vulnerability scanning on a schedule with remediation you can trace (3.11.2, 3.11.3), periodic control self-assessment, and the SSP requirement itself (3.12.4). Without an SSP the assessment cannot proceed at all.

System and Communications Protection (3.13, 16 requirements) and System and Information Integrity (3.14, 7 requirements). Home of the expensive findings. FIPS validated cryptography wherever encryption protects CUI (3.13.11) fails more often than any other single requirement, usually because the modules were never validated, only marketed. Encryption in transit (3.13.8) and at rest (3.13.16), deny-by-default boundary rules (3.13.6), and split tunneling left enabled all recur. On the integrity side: flaw remediation inside defined timelines (3.14.1) and monitoring alerts that a human actually triages.

The SSP and the POA&M

The System Security Plan is the document the assessment runs on. For each requirement it should say how the control is implemented, on which systems, and who owns it, in the present tense. If the SSP says one thing and the interview says another, the mismatch itself becomes the finding. Our SSP guide covers structure and pitfalls in detail.

The POA&M holds what remains, each item with an owner, a milestone, and a date. Keep it honest and keep it short. Under CMMC, only select one point requirements can ride on a POA&M through an assessment, you still need a score of at least 88, and the closeout window is 180 days. Anything heavier has to be fixed before the assessor arrives, not after.

SPRS submission

Compute your score under the DoD Assessment Methodology, starting from 110 and deducting 5, 3, or 1 points per unmet requirement, then post it in SPRS through the PIEE portal against your CAGE code, along with the assessment date, the SSP it describes, and the date you plan to reach full implementation. Primes check this number before they put you on a team, and it must reflect what you can evidence, because a score you cannot support is a False Claims Act problem, not a rounding error. Update it as items close rather than letting it age toward the three year limit.

Traps that reset the clock

Four patterns burn quarters. Buying tools before scoping, because the platform purchased for the whole company gets repriced and reconfigured once the boundary shrinks to an enclave. Treating the enclave as a network project, when most of the work is process: how people mark, move, and share CUI has to change, or the boundary leaks within a month. Handing the program to an MSP without contract language, since the provider's obligations follow them into your assessment and the assessor will ask for the responsibility matrix that says who runs which control. And waiting on the rulemaking calendar, because primes are already writing CMMC requirements into subcontracts ahead of any clause in your own prime contract. Each of these is cheaper to avoid than to unwind.

Evidence habits that survive an assessment

Assessments are lost on evidence more than on controls. Five habits prevent that:

• Keep an evidence calendar. Quarterly exports of access reviews, scan results, training records, and log review notes, filed the day they are generated.
• Name a control owner for every family. The person who will sit in the interview should be the person who runs the control.
• Capture context in screenshots. Hostname, system clock, and logged-in user visible, so the artifact proves what it claims.
• File by requirement number. If producing evidence for 3.5.3 takes more than five minutes, you do not have it.
• Run show-me drills. Once a quarter, pick five requirements at random and demonstrate them live, exactly as an assessor would ask.

Working the checklist

Run the sequence in order: boundary, gaps, remediation, documentation, score, evidence. Cold starts typically need 6 to 12 months to reach assessment readiness; organizations with a real security program in place can compress that to a quarter or two. The fastest way to find out which one you are is a CMMC gap assessment, which scores all 110 requirements against their assessment objectives and hands you the prioritized fix list. If you want the whole path handled, from scoping and enclave design through remediation and mock assessment, that is what our CMMC consulting practice does. BD Emerson is not a C3PAO and does not certify; we get you to the point where the certifying assessment is boring.