CMMC Level 2 Readiness Checklist: Preparing for Your C3PAO Assessment

Most organisations that fail a CMMC Level 2 assessment do not fail on technology: they fail because the System Security Plan does not match the environment, the scope is unclear, or the evidence for a requirement they believe is met cannot be produced on the day. This checklist is a working template for [Organisation] to test readiness against the 110 security requirements of NIST SP 800-171 Rev 2, family by family, together with the scoping, SSP, scoring and evidence rules of 32 CFR Part 170. It works for a Level 2 self-assessment and for preparing a certification assessment by a CMMC Third-Party Assessment Organisation (C3PAO). It is written for compliance leads, IT managers and security engineers at defence contractors and subcontractors that handle Controlled Unclassified Information (CUI).

How to use this template

• Replace bracketed text such as [Organisation], [CUI enclave], [Affirming Official], [Control owner] and [Date] with your own values.
• Check programme status first. As of 8 November 2026, the DoD CIO CMMC page states that Phase I began on 10 November 2025, that Phase II (originally scheduled for 10 November 2026) was suspended on 13 July 2026, and that a reform task force was established. It also states that Phase I self-assessment requirements remain in place, that DoD enforces NIST SP 800-171 Rev 2 through self-assessments and select government-led assessments, and that DFARS 252.204-7012 still applies. Recheck the page before you plan a C3PAO date.
• Mark each check Met, Not met or Not applicable, link the evidence and record the SSP section that describes it. Under 32 CFR 170.24, a requirement scored Not applicable counts as Met, but the assessor must agree it is genuinely not applicable.
• Requirement numbers below follow SP 800-171 Rev 2 (3.1.1 and so on), which is the version CMMC Level 2 assesses. Assessors test each requirement against its assessment objectives in SP 800-171A.
• This template is not legal advice. Confirm contract clauses and current DoD policy with your contracting officer and counsel. For the assessment process itself, see the CMMC 2.0 Level 2 Assessment Guide.

1. Contract, scope and boundary

• Contracts and solicitations containing DFARS 252.204-7012, 252.204-7019, 252.204-7020 or 252.204-7021 are listed, with the CMMC level each requires. See the DFARS 252.204-7012 Guide.
• CUI received and generated is identified by category, with where it is stored, processed and transmitted. See the CUI Guide.
• Every asset is categorised under 32 CFR 170.19 as a CUI asset, Security Protection Asset, Contractor Risk Managed Asset, Specialized Asset or out of scope, with the reason recorded. See the CMMC Scoping Guide.
• A network diagram and data flow diagram show the [CUI enclave] boundary, external connections and every External Service Provider.
• Cloud services that store, process or transmit CUI are FedRAMP Moderate authorised or equivalent, and the customer responsibility matrix for each is referenced in the SSP.
• Security Protection Assets (identity provider, SIEM, EDR console, vulnerability scanner, managed service provider tools) are inside the assessment scope.

2. System Security Plan, POA&M and score

• An SSP exists, is current, names the system, boundary, environment and roles, and describes how each of the 110 requirements is implemented. Requirement 3.12.4 (SSP) must be in place or the assessment cannot be completed. See the System Security Plan Template and Guide.
• The SSP describes what is actually deployed: tool names, policy names and configuration match what an assessor will see.
• A self-assessment score using the 32 CFR 170.24 method (each requirement weighted 5, 3 or 1 points from a maximum of 110) has been calculated and, where required, entered in SPRS.
• Any open items are in a Plan of Action and Milestones (POA&M). Under 32 CFR 170.21 a Conditional status needs a score of at least 80% of the maximum, POA&M items must be closed within 180 days, and certain requirements may never be on a POA&M, including 3.1.20, 3.1.22, 3.12.4, 3.10.3, 3.10.4 and 3.10.5.
• A senior [Affirming Official] is named and understands the affirmation duties under 32 CFR 170.22: at Conditional and Final status, annually, and after POA&M closeout.

3. Access control (AC, 22 requirements) and identification and authentication (IA, 11)

• Authorised users, processes acting for users and devices are defined and limited (3.1.1), and every account, including service accounts, has an owner and a documented purpose.
• Least privilege is applied (3.1.5), privileged accounts are used only for privileged functions (3.1.6), and non-privileged users cannot run privileged functions (3.1.7).
• Unsuccessful logon attempts are limited (3.1.8), sessions lock after inactivity (3.1.10) and remote access is monitored, controlled and routed through managed access points (3.1.12 to 3.1.15).
• Wireless, mobile devices and connections to external systems are controlled (3.1.16 to 3.1.21), and CUI on publicly accessible systems is prevented (3.1.22).
• Multi-factor authentication is enforced for local and network access to privileged accounts and network access to non-privileged accounts (3.5.3). This requirement carries partial credit only in narrow cases, so treat it as mandatory.
• Replay-resistant authentication (3.5.4), identifier management (3.5.5, 3.5.6) and password rules (3.5.7 to 3.5.10, including storing and transmitting only cryptographically protected passwords) are configured and evidenced.
• Service accounts, API keys and machine credentials are inventoried and rotated because 3.1.1 and 3.5.1 cover processes acting on behalf of users and devices, not only people. See the NIST SP 800-171 and CMMC 2.0 Guide.

4. Audit and accountability (AU, 9), configuration management (CM, 9) and system and information integrity (SI, 7)

• Audit events are defined, logs are created and retained (3.3.1), user actions are traceable to individuals (3.3.2) and logging failures raise alerts (3.3.4).
• Logs are reviewed and correlated (3.3.5), time is synchronised to an authoritative source (3.3.7), and audit logs and tools are protected from unauthorised change (3.3.8, 3.3.9).
• Baseline configurations and an inventory exist (3.4.1), security settings are enforced (3.4.2), changes are tracked and analysed for security impact (3.4.3, 3.4.4).
• Least functionality is applied: unnecessary programs, ports and services are disabled, and software is restricted by allow-list or deny-list (3.4.6 to 3.4.9).
• Flaws are identified and remediated on time (3.14.1), malicious code protection is current and scans run (3.14.2, 3.14.4, 3.14.5), security alerts are acted on (3.14.3) and systems are monitored for attacks and unauthorised use (3.14.6, 3.14.7).

5. Risk assessment (RA, 3), security assessment (CA, 4), incident response (IR, 3) and awareness and training (AT, 3)

• Risk is assessed periodically (3.11.1), vulnerability scans run on a schedule and when new vulnerabilities are announced (3.11.2), and findings are remediated by risk (3.11.3).
• Security controls are assessed periodically (3.12.1), deficiencies are tracked in plans of action (3.12.2) and controls are monitored on an ongoing basis (3.12.3).
• An incident handling capability covers preparation, detection, analysis, containment, recovery and user response (3.6.1), incidents are tracked and reported (3.6.2) and the capability is tested (3.6.3). Under DFARS 252.204-7012, cyber incidents are reported to DoD within 72 hours of discovery.
• Users are made aware of risks (3.2.1), role-based training is delivered (3.2.2) and insider threat awareness is included (3.2.3), with completion records.

6. Media protection (MP, 9), physical protection (PE, 6), personnel security (PS, 2) and maintenance (MA, 6)

• CUI media is protected, access limited, sanitised before disposal or reuse, marked and controlled in transport, with encryption for CUI on portable storage (3.8.1 to 3.8.9).
• Physical access is limited and monitored, visitors are escorted and logged, and physical access devices are controlled (3.10.1 to 3.10.6). Alternate work sites have safeguards (3.10.6).
• Individuals are screened before access to CUI (3.9.1), and CUI and systems are protected during and after terminations and transfers (3.9.2).
• Maintenance is performed and controlled, maintenance tools are controlled, off-site equipment is sanitised, nonlocal maintenance uses MFA and is terminated when finished, and unescorted maintenance personnel are supervised (3.7.1 to 3.7.6).

7. System and communications protection (SC, 16)

• Communications are monitored and protected at external and key internal boundaries (3.13.1), with publicly accessible components on separate subnetworks (3.13.5).
• Network traffic is denied by default and allowed by exception (3.13.6), and split tunnelling for remote devices is prevented (3.13.7).
• CUI is encrypted in transit (3.13.8) and at rest (3.13.16), and cryptography used to protect CUI is FIPS-validated (3.13.11). Using strong but non-validated cryptography earns only partial credit under 32 CFR 170.24.
• Collaborative computing devices, mobile code and VoIP are controlled (3.13.12 to 3.13.14), session authenticity is protected (3.13.15), and cryptographic keys are established and managed (3.13.10).

8. Evidence and assessment logistics

• For each requirement, evidence covers the three assessment methods used by assessors: examine (documents, configurations, records), interview (people who perform the control) and test (demonstrate it working).
• Evidence is current, dated and taken from the in-scope environment, not a test lab.
• Control owners who will be interviewed are briefed and know where their evidence lives.
• Artefacts are organised so they can be hashed and retained for six years, as 32 CFR 170.17 requires for certification assessments.
• A mock assessment by an independent party, such as a Registered Practitioner Organisation, has been completed and its findings closed. See CMMC C3PAO and RPO Selection.

Implementation guidance

Order of work: fix scope first, because every other answer depends on it, and shrinking the CUI boundary to an enclave is usually the cheapest control. Then bring the SSP in line with reality, then close the 5-point requirements (MFA, encryption, boundary protection, incident response), then the rest.

Small and large organisations: a small subcontractor can often move all CUI into a single cloud enclave with a customer responsibility matrix, which removes most on-premises assets from scope. A larger prime contractor with several business units should set up one SSP per assessed system, a central evidence library and quarterly internal assessments against SP 800-171A objectives.

Note on Rev 3: NIST's publication page shows SP 800-171 Rev 2 as withdrawn on 14 May 2024 and superseded by Rev 3, which renumbers the requirements (for example multi-factor authentication becomes 03.05.03). The DoD CIO page states that Rev 2 is what DoD enforces now, so assess against Rev 2 and track Rev 3 for future change.

Metrics: current SPRS score; number of open POA&M items and days to the 180-day limit; percentage of requirements with evidence for all three assessment methods; accounts in scope with MFA; and percentage of in-scope assets with a recorded category.

References: DoD CIO: About CMMC · eCFR: 32 CFR Part 170 Cybersecurity Maturity Model Certification Program · eCFR: 32 CFR 170.24 Scoring methodology · eCFR: 32 CFR 170.21 Plan of Action and Milestones · NIST: SP 800-171 Rev 2 · eCFR: DFARS 252.204-7021

This template summarises requirements under 32 CFR Part 170, NIST SP 800-171 Rev 2 and the DFARS clauses named above and is not legal advice. Related NHI Mgmt Group resources: CMMC 2.0 Level 2 Assessment Guide · CMMC Scoping Guide · System Security Plan Template and Guide · NIST SP 800-171A Rev 3 Assessment Guide