CMMC Phase 2 assessment evidence — the Level 2 and Level 3 playbook

The CMMC program rule, 32 CFR Part 170, took effect on 16 December 2024. The acquisition rule that puts CMMC into contracts, with the DFARS clause at 252.204-7021 and the solicitation provision at 252.204-7025, took effect on 10 November 2025. Part 170 ties the phases to that date, each starting one calendar year after the previous one (§170.3(e)):

• Phase 1, from 10 November 2025: DoD intends to require Level 1 (Self) or Level 2 (Self) status as a condition of award, and may ask for Level 2 (C3PAO) instead.
• Phase 2, from 10 November 2026: DoD intends to add Level 2 (C3PAO) status as a condition of award for applicable solicitations and contracts. It may, at its discretion, move that requirement to an option period, and may also require Level 3 (DIBCAC).
• Phase 3, from 10 November 2027: Level 2 (C3PAO) also becomes a condition for exercising option periods, and DoD intends to require Level 3 (DIBCAC) for applicable solicitations.
• Phase 4, from 10 November 2028: full implementation, including option periods on contracts awarded before Phase 4.

Under the provision at 252.204-7025, an offeror is not eligible for award unless each contractor information system that will process, store or transmit FCI or CUI has a current CMMC status at the required level in SPRS and a current affirmation of continuous compliance. The clause at 252.204-7021 then requires that status to be maintained for the duration of the contract, with an annual affirmation. For three years after 10 November 2025 the clause is used when the program office determines that a specific CMMC level is required; after that, whenever FCI or CUI will be processed, except in contracts solely for COTS items.

Level 2 requirements are identical to NIST SP 800-171 Revision 2: 110 requirements in 14 families (§170.14(c)(3)). NIST withdrew Revision 2 in May 2024 in favour of Revision 3, but Part 170 incorporates Revision 2 by reference, so that is the version assessed. A C3PAO assesses each requirement against the assessment objectives of NIST SP 800-171A (June 2018), within the scope defined under §170.19, and scores it under §170.24:

• MET only when every applicable objective is satisfied by evidence. Evidence must be in final form; drafts, working papers and unapproved policies do not count.
• The score starts from 110 and subtracts 5, 3 or 1 point for each requirement NOT MET.
• Conditional Level 2 (C3PAO) is possible when the POA&M rules below are met; the POA&M must then be closed by a C3PAO closeout assessment within 180 days, or the status expires.
• Final Level 2 (C3PAO) lasts three years, with an affirmation of continuing compliance by the Affirming Official after each assessment and annually (§170.22).

Two evidence rules are easy to overlook. The contractor must hash the artifacts used as evidence with a NIST-approved hashing algorithm, give the C3PAO the list of artifact names and hash values, and keep the artifacts for six years from the CMMC Status Date (§170.17(c)(4)). And a requirement scored NOT MET can be re-evaluated during the assessment and for 10 business days after it only if additional evidence is available, other MET results are unaffected and the findings report has not yet been delivered.

Three requirements, each with assessment objectives that the assessor marks one by one:

• 3.11.1 Risk assessment (3 points): [a] the frequency of risk assessments is defined; [b] risk is assessed at that frequency.
• 3.11.2 Vulnerability scanning (5 points): [a] a scanning frequency is defined; [b] and [c] systems and applications are scanned at that frequency; [d] and [e] systems and applications are scanned when new vulnerabilities affecting them are identified.
• 3.11.3 Vulnerability remediation (1 point): [a] vulnerabilities are identified; [b] they are remediated in accordance with risk assessments.

For 3.11.2 and 3.11.3 the assessor may examine the scanning tools and their configuration documentation, scan results, and patch and vulnerability management records; interview the people who run scans and remediate; and test the scanning and remediation mechanisms themselves.

Part 170 defines “periodically” as a regular interval set by the contractor that may not exceed one year (§170.4 and §170.14(d)). A written frequency is therefore required, and one year is the ceiling, not the target. The NIST discussion of 3.11.2 lists what scanning covers (patch levels; functions, ports, protocols and services that should not be accessible; misconfigured information flow controls), notes that privileged access to selected components allows more thorough scanning, and names red team exercises as a further source of vulnerabilities to scan for.

Four requirements. The first three carry points; the fourth decides whether the assessment can happen at all:

• 3.12.1 Security control assessment (5 points): [a] the frequency of control assessments is defined; [b] controls are assessed at that frequency to determine whether they are effective in their application.
• 3.12.2 Plans of action (3 points): [a] deficiencies and vulnerabilities are identified; [b] a plan of action is developed to correct them; [c] the plan is implemented.
• 3.12.3 Continuous monitoring (5 points): controls are monitored on an ongoing basis to ensure they remain effective.
• 3.12.4 System security plan: without a current SSP the assessment cannot be completed, and the SSP cannot be placed on a POA&M.

The 3.12.2 plan of action is an operational document, not the CMMC POA&M, and the difference matters. Under §170.24(b)(1)(ii), temporary deficiencies that are appropriately addressed in operational plans of action, with deficiency reviews and visible progress, are assessed as MET. A vulnerability found by last week's scan does not make 3.11.2 or 3.11.3 NOT MET if the process that found it is working and the fix is tracked and moving.

For 3.12.1, the NIST discussion expects results that are current, relevant and obtained with the appropriate level of assessor independence, and allows vulnerability scanning and system monitoring as further assessment activities. A control that exists on paper but has never been shown to work, such as network segmentation that has not been tested, is exactly what this requirement is meant to catch.

A Conditional status, and therefore a POA&M, is only allowed if all of these hold (§170.21(a)(2)):

• The score is at least 80 percent of the maximum, which with 110 requirements means 88 points.
• No requirement on the POA&M is worth more than 1 point, except SC.L2-3.13.11 when encryption is used but is not FIPS-validated.
• None of six named requirements is on it, among them CA.L2-3.12.4, the system security plan.

Applied to the two families above: 3.11.1 (3 points), 3.11.2 (5), 3.12.1 (5), 3.12.2 (3) and 3.12.3 (5) cannot be deferred, 3.12.4 is excluded by name, and only 3.11.3 (1 point) can sit on a POA&M. A POA&M is also not a substitute for implementation: a requirement that is not implemented is scored NOT MET whether or not it appears on the plan (§170.24). The closeout assessment must confirm every POA&M item within 180 days of the Conditional status date; otherwise the Conditional status expires and the contractor is ineligible for new awards that require that status for the system until it achieves a new one.

Level 3 is assessed by DCMA DIBCAC and requires a Final Level 2 (C3PAO) status on the same scope first (§170.18). It adds 24 requirements selected from NIST SP 800-172 (February 2021), with parameters assigned by DoD in table 1 to §170.14(c)(4). The ones closest to testing:

• CA.L3-3.12.1e: penetration testing at least annually or when significant security changes are made to the system, using automated scanning tools and ad hoc tests by subject matter experts.
• RA.L3-3.11.5e: assess the effectiveness of security solutions at least annually, on receipt of relevant cyber threat information, or in response to a relevant cyber incident.
• RA.L3-3.11.1e and SI.L3-3.14.6e: use threat intelligence from open or commercial sources and any DoD-provided sources to inform risk assessment, intrusion detection and threat hunting.
• RA.L3-3.11.2e: threat hunting on an ongoing aperiodic basis or when indications warrant.
• SC.L3-3.13.4e: physical isolation techniques, logical isolation techniques, or both.

NIST's discussion of 3.12.1e explains what it expects beyond Level 2 scanning. Penetration testing goes beyond automated vulnerability scanning and can validate whether vulnerabilities are exploitable; it may be supplemented by red team exercises; rules of engagement are agreed before testing starts; and the team needs the right skills and must be objective in its assessment. NIST withdrew the February 2021 edition of SP 800-172 on 13 May 2026, when it published Revision 3. As of the eCFR text of September 2026, Part 170 still incorporates the 2021 edition, and the Level 3 table is built on it.

Security tools are not outside the CMMC boundary. Part 170 defines Security Protection Data as data stored or processed by the assets that protect the assessed environment, including data related to the configuration or vulnerability status of in-scope assets and passwords that grant access to the in-scope environment (§170.4). Scan results, penetration test findings and the credentials a gray-box test uses all fall under that definition.

The scoping rules then decide how a tool is treated (§170.19(c) and its table 4):

• A tool you run inside the enclave is a Security Protection Asset: it goes in the asset inventory, the SSP and the network diagram, and is assessed against the Level 2 requirements relevant to what it does.
• An External Service Provider is defined by processing, storing or transmitting CUI or Security Protection Data. A cloud service that receives your vulnerability data is in your assessment scope and assessed as a Security Protection Asset, and its use must be documented in your SSP and in the provider's service description and customer responsibility matrix.
• If that cloud service also processes CUI, which can happen when a test reaches a file share or a database, the provider must meet the FedRAMP requirements of DFARS 252.204-7012: FedRAMP Moderate authorisation or equivalent (§170.17(c)(5)).

A testing tool that sends prompts and findings to an external AI model falls under these rules like any other provider. Keeping the testing and the models inside the enclave keeps CUI and Security Protection Data inside the boundary you already document, adds no external provider to the scope, and works where the enclave is physically isolated, the kind of separation that Level 3 requirement 3.13.4e describes.

An autonomous AI red team is not a C3PAO, does not issue or predict a CMMC status, and does not replace the subject matter experts that 3.12.1e calls for. It gives the contractor a way to run, and evidence, the testing the requirements describe, inside the enclave.

• Scanning and validation at a defined frequency and when new vulnerabilities appear (3.11.2), with findings shown to be exploitable in your environment so remediation follows risk (3.11.3). See fix what was proven exploitable first.
• Control effectiveness testing (3.12.1): whether segmentation, authentication and hardening hold under attack, in black-box mode from outside a segment and gray-box mode with the access of a standard user. See black-box vs gray-box testing.
• Plans of action that move (3.12.2): each fix re-tested with the same proof that found the flaw.
• Rules of engagement enforced in the engine: scope validation and an emergency stop, five autonomy levels that decide what waits for an operator's approval, and exploit proofs of concept held for operator review when the campaign level does not allow them. See human in the loop.
• Evidence integrity: every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain per campaign, verifiable offline.
• Private AI inside the boundary: ZeroHunt Apex models run on the appliance, with no external AI API and no internet connection required, so CUI and Security Protection Data stay where your SSP says they are. See private AI in cybersecurity.

• 32 CFR Part 170, Cybersecurity Maturity Model Certification (CMMC) Program (eCFR)
• CMMC Program final rule, 89 FR 83092, 15 October 2024 (Federal Register)
• DFARS Case 2019-D041 final rule, 90 FR 43560, 10 September 2025 (Federal Register)
• NIST SP 800-171 Rev. 2, Protecting CUI in Nonfederal Systems and Organizations (NIST CSRC)
• NIST SP 800-171A, Assessing Security Requirements for CUI (NIST CSRC)
• NIST SP 800-172, Enhanced Security Requirements for Protecting CUI, February 2021 (NIST CSRC)