CMMC Level 2 Readiness Checklist: NIST 800-171 Audit Prep Guide

If I’m a small to mid-size DoD supplier handling CUI in January 2026, CMMC Level 2 readiness is no longer a “someday” project. CMMC 2.0 is active and rolling out in phases, and Level 2 is the baseline most CUI contractors will live and die by.

Level 2 aligns to NIST SP 800-171 Rev. 2, which is 110 requirements across 14 families. The part that surprises teams is this: assessors don’t certify my intent. They certify objective evidence. That means screenshots, exports, logs, tickets, diagrams, training records, and proof that controls work in real life, not just in policy.

This checklist is organized like I run audit-prep: front-matter setup first (scope, SSP, roles), then the 14 NIST families, then a pre-assessment and day-of evidence package.

Before the checklist, set my CMMC Level 2 readiness foundation

Most CMMC pain is self-inflicted. Bad scoping creates extra controls, extra endpoints, and extra interviews. Missing documentation leads to rework when I’m already on the clock.

I start by grounding my approach in authoritative references. The best “what will they ask for?” view is the DoD CMMC Level 2 Assessment Guide. For the baseline requirements, I keep NIST SP 800-171 Rev. 2 handy. When I want to see how controls get tested, I cross-check with NIST 800-171A assessment procedures. I also watch the official CMMC resources hub from DoD CIO for updates.

This is where Small Business IT realities matter. I’ve seen one-person IT teams and MSP-led environments succeed when they treat readiness like an IT operations tune-up, not a paperwork sprint. My work often blends Cybersecurity Services and Technology Consulting with practical “keep the business running” support, especially for Managed IT for Small Business clients that need a Business Technology Partner, not a binder-builder.

To keep it “downloadable,” this is my master readiness checklist:

Readiness area	What I confirm	Example artifacts
Contract trigger	Which programs require Level 2, self vs C3PAO	Contract clauses, SPRS notes
CUI scope	Where CUI is created, stored, processed, transmitted	Boundary statement, CUI data map
SSP quality	Clear system description + control implementations	SSP, control-to-evidence index
Inventory	Everything in scope is counted and owned	Asset list, SaaS list, service accounts
Identity	MFA, least privilege, admin separation	Conditional access export, admin roster
Logging	Central logs, time sync, reviews	SIEM report, log retention settings
Vulnerability mgmt	Scan cadence + remediation proof	Scan report, patch tickets
Incident readiness	Plan, reporting, tabletop evidence	IR plan, tabletop notes, tickets
Backups	Encrypted backups + tested restores	Backup settings, test record
POA&Ms	Minimal, owned, dated, closing fast	POA&M register, closure plan

Define my CUI boundary and enclave scope (what’s in, what’s out)

I locate every place CUI can live: endpoints, file shares, SharePoint sites, Teams chats, email, line-of-business apps, and backups. If it can touch CUI, it’s in scope.

Then I shrink scope on purpose. Separation is my best friend: a dedicated tenant, network segmentation, VDI for CUI work, and clearly labeled SharePoint libraries. Thoughtful Cloud Infrastructure choices and Secure Cloud Architecture patterns reduce audit friction because the boundary becomes explainable.

Evidence I collect early:

• Boundary statement in the SSP
• Network and tenant diagrams
• In-scope apps, endpoints, and CUI storage locations (including Microsoft 365)

Get my SSP, asset inventory, and data-flow diagrams ready

My SSP is the story assessors will test. At minimum, I document system purpose, boundary, roles, how each requirement is met, and links to the procedures and tool settings that prove it.

I also build an inventory that doesn’t lie: hardware, software, VMs, SaaS, service accounts, and privileged identities. For data-flow diagrams, I map the CUI path through email, Teams, SharePoint, file transfer, backups, and any integrations.

Office 365 Migration projects are a common breaking point. Moving mail, files, or identity changes data flows, so diagrams and scope must be updated the same week, not months later.

Evidence examples:

• SSP mapping table (requirement to implementation)
• CMDB or exported inventory
• Microsoft 365 admin center exports
• Data-flow diagram and interconnection list

Assign roles, set vendor/MSP rules, and handle POA&Ms the right way

I assign owners the way auditors expect: system owner, ISSM/ISSO function, IT admin, HR, facilities, and a vendor manager who controls third-party access.

For MSPs and cloud providers, I document shared responsibility and flow-down requirements in contracts and SOW language. If a vendor can touch CUI systems, I treat them as part of the risk story.

POA&Ms are not a comfort blanket. I use them sparingly, track owners and dates, and plan to close most gaps before any C3PAO assessment. If I’m asking DoD for “conditional” time, I need proof the plan is real and moving. This ties directly into Business Continuity & Security planning, because loose ends tend to show up during incidents.

Evidence examples:

• RACI chart
• Vendor list with CUI access
• Contract language and access approvals
• POA&M register and risk acceptance notes

CMMC Level 2 readiness checklist by NIST 800-171 family (what it means, tasks, evidence, common gaps)

Before I lock anything in, I cross-check each control against NIST 800-171A procedures and the DoD Level 2 guide, because those drive what assessors examine, interview, and test. For assessment mechanics, I also reference the Cyber AB CMMC Assessment Process (CAP) so I’m not surprised by sampling and evidence handling.

AC, AT, AU, and CM (access, training, logs, and change control)

• AC (Access Control): I restrict CUI access to need-to-know. Tasks: least privilege, MFA, remote access controls. Evidence: group reports, conditional access export. Gaps: shared admin accounts, broad file permissions.
• AT (Awareness and Training): I train by role, not just annually. Tasks: onboarding training, phishing drills. Evidence: roster, completion logs. Gaps: no contractor training, no proof of phishing follow-up.
• AU (Audit and Accountability): I can reconstruct events. Tasks: central logging, time sync, review cadence. Evidence: SIEM dashboard, retention settings. Gaps: no documented reviews, missing admin activity logs.
• CM (Configuration Management): I control change. Tasks: baselines, patch approvals, Device Hardening standards. Evidence: baseline doc, change tickets. Gaps: “we just update it” changes, unmanaged endpoints.

IA, IR, MA, and MP (identity proof, response, maintenance, and media)

• IA (Identification and Authentication): Every user is unique and verified. Tasks: MFA for admins and remote, strong auth. Evidence: MFA enforcement screenshots. Gaps: legacy protocols, weak vendor auth.
• IR (Incident Response): I can detect, report, and recover. Tasks: IR plan, reporting path, tabletop exercise. Evidence: incident tickets, tabletop notes. Gaps: no exercise record, unclear escalation.
• MA (Maintenance): Support is controlled and logged. Tasks: approve remote tools, track maintenance events. Evidence: tool configs, maintenance logs. Gaps: vendor “anytime” access, no session records.
• MP (Media Protection): CUI stays protected off-device too. Tasks: marking, encryption, disposal. Evidence: disk encryption report, shred certificates. Gaps: unmanaged USB use, unlabeled exports.

PS, PE, RA, and CA (people, facilities, risk, and assessment)

• PS (Personnel Security): Trust is verified and removed on exit. Tasks: screening, fast offboarding. Evidence: HR checklists, termination tickets. Gaps: slow deprovisioning, orphan accounts.
• PE (Physical Protection): The space matches the policy. Tasks: badges, visitor logs, locked areas. Evidence: access logs, visitor sign-in. Gaps: shared keys, weak server closet controls.
• RA (Risk Assessment): I know my exposures and I act. Tasks: vulnerability scans, risk register. Evidence: scan report, risk log. Gaps: no scan cadence, fixes not tracked to closure.
• CA (Security Assessment): I re-check myself and update reality. Tasks: internal audits, SSP updates, self-scoring. Evidence: assessment checklist, SSP change log. Gaps: SSP not updated after changes.

SC and SI (secure systems, secure comms, and ongoing protection)

• SC (System and Communications Protection): I defend the boundary and encrypt traffic. Tasks: segmentation, secure protocols, encryption at rest/in transit. Evidence: firewall rules, VPN and TLS settings. Gaps: flat networks, old admin protocols.
• SI (System and Information Integrity): I prevent, detect, and fix. Tasks: EDR, patching, flaw remediation, monitoring. Evidence: EDR reports, patch compliance, alert runbooks. Gaps: no proof alerts were handled. Endpoint Security and Device Hardening are easy wins when documented.

Conclusion: pre-assessment validation and the day-of evidence package

When I’m close, I validate like an assessor would. I sample real users and endpoints, run a mock interview, confirm MFA on privileged accounts, and check that logging and time sync are consistent across systems. I also test restores, not just backup jobs, and I confirm my boundary statement matches reality on the network and in Microsoft 365.

For evidence retention, I keep dated exports, tickets, and reports in a controlled folder tied to my SSP, and I retain them for at least the current three-year certification cycle (plus whatever my contracts require). If I can’t show “what happened when,” I’m betting my award eligibility on memory.

My day-of evidence package is simple: SSP, network and data-flow diagrams, asset inventory, policies and procedures, recent vulnerability scan report, training records, incident exercise record, backup test record, logging and SIEM proof, access control and MFA exports, change tickets, and a POA&M (if any) with a clear closure plan.

If you want help getting this over the finish line, I can act as your Business Technology Partner, aligning Cloud Management, Infrastructure Optimization, and Tailored Technology Services to CMMC realities. That includes environments people forget about, like Restaurant POS Support and Kitchen Technology Solutions, when a restaurant group also supports DoD work and needs compliant, dependable IT that doesn’t slow the business down.