You've got a solicitation approaching, a prime contractor asking for your CMMC status, and an environment that grew organically rather than from a clean compliance architecture. Your policies may look complete, but the assessor will want to see whether access controls, logging, vulnerability management, incident response, and system protections operate consistently across the systems that handle FCI or CUI.
That's the practical meaning of CMMC compliance requirements in 2026. CMMC isn't a document-writing exercise. It's an evidence and program-management discipline supported by repeatable security operations, including penetration testing, remediation tracking, and controlled evidence retention.
Table of Contents
- Why CMMC Compliance Requirements Matter Right Now
- The Three CMMC Levels Explained
- Control Families and Example Controls Under NIST 800-171
- Assessment Types and the Roles of C3PAOs and Assessors
- Evidence and Documentation Requirements That Actually Pass Review
- Running a Gap Analysis and Building a Remediation Plan
- Where Penetration Testing Fits in CMMC
- A 90-Day Preparation Checklist for MSSPs and Security Consultancies
Why CMMC Compliance Requirements Matter Right Now
CMMC moved into enforceable implementation through two connected rulemaking steps. The 32 CFR final rule became effective on December 16, 2024, and the 48 CFR acquisition rule began allowing CMMC requirements in applicable DoD solicitations and contracts on November 10, 2025. The DoD says implementation began on November 10, 2025 and is proceeding in phases, with later phases extending through 2028. Crowell's analysis of the CMMC rulemaking timeline explains why those milestones matter during active procurement and renewal cycles.
A contractor can no longer treat CMMC as a distant deadline. A contracting officer may require the relevant status before award, option exercise, or extension when the solicitation includes the applicable language. Prime contractors also have a commercial reason to demand evidence from subcontractors, because security obligations flow through the defense supply chain and a missing status can disrupt the prime's ability to use a supplier.
The scale is substantial. The DoD estimates that 337,968 unique entities may be subject to CMMC requirements by Year 4 of the phased rollout, including 229,818 small businesses, about 68% of that total, as reported in Greenberg Traurig's coverage of industry readiness research. The same reporting cites readiness findings in which 4% of DoD contractors were ready, 41% had completed the required self-assessment process, and the average score was -12 against the 110-control benchmark.
Practical rule: Treat the solicitation clause, not a marketing presentation or an old customer email, as the trigger for your immediate compliance path.
The right response is operational. Establish the assessment boundary, identify every system that touches regulated information, produce evidence continuously, and test the controls that protect that boundary. The contractors that wait for a perfect environment often spend budget on broad tooling while leaving basic ownership, asset inventory, and evidence gaps unresolved.
The Three CMMC Levels Explained
CMMC level selection should start with the contract and the information your team handles. Level 1 protects FCI, Level 2 governs systems that store, process, or transmit CUI, and Level 3 adds protections for the most sensitive programs. Treat each level as an evidence and program-management commitment, not a checklist label.
| Level | Practices | Assessment Type | Cadence | Trigger |
|---|---|---|---|---|
| Level 1 | 15 security requirements from FAR 52.204-21 | Annual self-assessment | Annual assessment and affirmation | FCI |
| Level 2 | 110 requirements across 14 NIST SP 800-171 control families | Self-assessment or C3PAO assessment, depending on solicitation | Annual affirmation, with status valid for three years | CUI |
| Level 3 | 110 NIST SP 800-171 requirements plus 24 NIST SP 800-172 requirements | Government-led assessment | Every three years, with enhanced testing obligations | Highly sensitive CUI programs |
Level 1 requires an annual self-assessment and annual affirmation against 15 security requirements. It does not require certification against NIST SP 800-171. Davis Wright Tremaine's explanation of the Level 1 baseline separates FCI protection from the broader CUI obligations. Build a small, clearly bounded evidence package: system scope, policies, account reviews, training records, and retained assessment results.
Level 2 requires evidence that an assessor can trace from each requirement to an implemented control and a current artifact. NIST SP 800-171 supplies the technical foundation. A C3PAO assessment applies to prioritized acquisitions, while a solicitation for a non-prioritized acquisition may require an annual self-assessment against the same 110 requirements, as explained in Winston & Strawn's summary of the procurement rule. Configure your pentest platform and MSSP workflows to retain test results, remediation tickets, alert reviews, and dated approvals in the same evidence pipeline.
Level 3 adds 24 requirements from NIST SP 800-172 and a government-led assessment. Its assessment expectations also make penetration testing explicit, including annual testing and testing after significant system changes, according to the CMMC Level 3 Assessment Guide.
Choose the level required by the contract, data category, solicitation language, and prime customer expectations. Do not pursue a higher level for appearances. The extra scope creates more evidence, remediation, and assessment work.
Control Families and Example Controls Under NIST 800-171
Level 2 covers all 110 security requirements across 14 control families. Treat that scope as an evidence-management program, not a policy checklist. For every requirement, an engineer, MSSP, or assessor should be able to trace the implementation, responsible owner, operating record, and current artifact.
Use the NIST control family reference as an organizing index. Then map each family to the systems, workflows, and evidence your environment uses. Generic policy language will not prove that a control operates.
| Control family | Practical implementation | Evidence to retain | Common failure |
|---|---|---|---|
| Access Control | Role-based access, least privilege, remote access restrictions | Access reviews, conditional access logs, approval records | Dormant accounts and excessive privileges |
| Awareness and Training | Security training tied to job responsibilities | Completion records and training content | Training exists without role-specific coverage |
| Audit and Accountability | Centralized collection and review of security events | SIEM exports, alert records, review tickets | Logs aren't retained or reviewed consistently |
| Configuration Management | Approved secure baselines for endpoints and servers | Baseline exports, change records | Systems drift from the approved configuration |
| Identification and Authentication | Strong authentication and unique identities | Identity-provider settings and authentication logs | Shared accounts or incomplete MFA coverage |
| Incident Response | Documented playbooks with assigned responders | Tabletop records, incident tickets, after-action reports | The plan hasn't been exercised |
| Maintenance | Controlled maintenance access and records | Maintenance tickets and remote-session logs | Vendors receive unmanaged access |
| Media Protection | Restrictions for removable media and media sanitization | Device-control logs and disposal records | Media handling is assumed rather than recorded |
| Personnel Security | Screening and termination procedures | Personnel records and access-removal tickets | Departing users retain access |
| Physical Protection | Controlled facility and equipment access | Badge logs, visitor records, camera procedures | Physical scope is omitted from the system boundary |
| Risk Assessment | Periodic risk identification and analysis | Risk register and assessment outputs | Risks aren't linked to owners or decisions |
| Security Assessment | Internal reviews, vulnerability testing, and corrective action | Assessment reports, findings, retests | Testing is a one-time event |
| System and Communications Protection | Segmentation, encrypted connections, boundary controls | Firewall rules, architecture diagrams, scan outputs | Encryption is treated as logical separation |
| System and Information Integrity | Malware protection, flaw remediation, and alerting | Scanner results, remediation records, exploit verification | Findings remain open without risk decisions |
For pentest platforms and MSSP teams, System and Communications Protection and System and Information Integrity usually generate the clearest technical evidence. Retain authenticated scan results, validated exploit evidence, remediation tickets, screenshots, alert reviews, and retest results. Automate collection where possible, but require an owner and review date for every artifact.
Those records support the technical narrative. They do not replace training records, access approvals, incident procedures, risk decisions, or other operational evidence. Build the evidence pipeline around the full control family, then use automated testing to feed findings, tickets, approvals, and verification results into that record.
Assessment Types and the Roles of C3PAOs and Assessors
The contracting officer's solicitation language determines the assessment path. Don't choose a self-assessment because it's convenient, and don't schedule a C3PAO assessment before confirming that the contract requires one.
Level 1 uses an annual self-assessment and annual affirmation. Level 2 can use an annual self-assessment for contracts that permit it, or a C3PAO assessment where the solicitation requires third-party validation. Level 3 uses a government-led assessment, rather than the standard C3PAO route, and involves the government assessment structure associated with the Defense Contract Management Agency's Defense Industrial Base Cybersecurity Assessment Center.
| Assessment Type | Applies To | Performed By | Cadence | Outcome |
|---|---|---|---|---|
| Level 1 self-assessment | FCI environments | Contractor | Annual | Self-assessment result and affirmation |
| Level 2 self-assessment | Solicitations that permit self-assessment | Contractor | Annual assessment, annual affirmation | Recorded self-assessment status |
| Level 2 third-party assessment | Solicitations requiring independent validation | C3PAO assessment team | Status valid for three years, annual affirmation | CMMC Level 2 status |
| Level 3 government assessment | Programs requiring the highest level | Government-led assessment | Every three years | Government assessment result |
A C3PAO is authorized through the CMMC accreditation ecosystem. Within the assessment team, the Lead Assessor directs the assessment and signs the decision, while the Quality Assurance reviewer checks that the methodology and conclusions meet required standards. Ask the provider to explain who performs each role, how findings are handled, and what quality review occurs before results are finalized.
Scope is where budgets are won or wasted. An enterprise boundary may include broad identity, endpoint, network, cloud, and physical environments. An enclave can reduce the assessment population, but only if CUI is contained and data flows are controlled. Encryption by itself doesn't establish logical separation, and a cloud service shouldn't be treated as compliant merely because it encrypts data. DoD CMMC guidance should anchor the current program interpretation.
Select a C3PAO with experience in your technology stack and contract context. Negotiate an assessment window only after the SSP, evidence repository, asset inventory, and remediation owners are ready.
Evidence and Documentation Requirements That Actually Pass Review
A policy binder can explain intent. It can't prove that a control operates. Assessors need a chain that connects the requirement, the system, the configuration, the event record, and the person responsible for maintaining it.
Build evidence as a production deliverable. A useful package usually combines system-generated records with approved documentation:
- Configuration proof: Capture screenshots or exports with timestamps, system identifiers, and enough context to show the relevant setting.
- Operational logs: Preserve records that show enforcement, review, alerting, and response over a meaningful look-back period. Don't rely on a single point-in-time screenshot.
- Controlled policies: Store the owner, version, approval date, review history, and scope for every policy.
- Security testing: Retain scan exports, authenticated configuration pulls, exploit proof-of-concept logs, remediation screenshots, and retest results.
- Traceable organization: Index every artifact to a control reference, asset, collection date, and evidence owner.
Build a repository, not a dumping ground
Put the evidence in a controlled assessment repository. Organize it by control family and requirement, then cross-reference assets, policies, tickets, logs, and test outputs. An assessor should be able to start with a requirement and follow the evidence chain without asking your team to search across email, shared drives, and ticketing systems.
MSSPs should templatize collection by family. For example, an access-control workflow can request identity exports, privileged access reviews, conditional access logs, and exception approvals. A system-integrity workflow can ingest scanner results, verified findings, remediation tickets, and retest reports. The template should still allow client-specific systems and control owners.
Use immutable or access-controlled storage for assessor samples. Label files with the control reference, asset identifier, collection date, source system, and collector. Restrict modification after collection, record any approved replacement, and preserve the original artifact.
Policies without operational evidence fail the practical review, even when the policy language is excellent.
For executive readers, a concise summary should show scope, major gaps, risk ownership, and remediation status. A useful executive summary example resource can help MSSPs keep leadership reporting separate from the technical evidence set.
Running a Gap Analysis and Building a Remediation Plan
Start with the CUI boundary, not the questionnaire. If CUI never reaches a system, that system should not consume assessment budget. Document where CUI enters, moves, rests, and leaves, then include the identity, endpoint, network, cloud, backup, administrative, and physical systems that can affect its protection.
Five phases that produce usable work
Scope the assessment boundary. Record data flows, trust relationships, inherited services, and system owners. Make the boundary specific enough that a tester can reproduce it and an assessor can verify it.
Inventory in-scope assets. List hardware, software, services, accounts, repositories, external providers, and owners. Reconcile the list with vulnerability-scanner coverage, penetration-test targets, and monitoring sources. Any asset missing from all three deserves investigation.
Baseline each requirement against operation. Review the applicable requirement against the implemented process. Record the artifact location, system owner, collection method, and collection date. A narrative answer is not evidence. Configuration exports, access reviews, tickets, logs, test results, and retest reports are evidence.
Score the control. Use Met, Partially Met, or Not Met. A product that can perform a function does not establish compliance. The organization must configure it, operate it, and retain proof that it operated as required.
Prioritize by risk and contract urgency. Address exposed assets, boundary weaknesses, identity failures, and exploitable vulnerabilities before rewriting policy language. Automated testing helps here when scanner findings and platform results create dated records, link to affected assets, and open remediation tickets automatically.
A remediation plan is an internal management tool. A POA&M is a formal assessment artifact subject to eligibility and closeout rules. Do not use a POA&M to park fundamental failures that should be fixed before assessment.
Convert test findings into accountable tasks
Turn every penetration-test or automated-test finding into a record containing:
- Control reference: Map the issue to the applicable requirement or family.
- Evidence of gap: Attach the verified finding, affected asset, screenshots, and test context.
- Remediation action: Specify the configuration, code, architecture, or process change.
- Owner and target date: Assign one accountable person.
- Residual risk decision: Record acceptance, transfer, mitigation, or escalation.
- Closure evidence: Require a retest, configuration export, screenshot, or ticket trail.
For Level 2, conditional status is limited to 180 days, and final status requires valid POA&M closeout, as summarized by Inside Government Contracts. Fix Met and Partially Met gaps before the assessment window. Reserve POA&M entries for bounded work that can close within that period.
Where Penetration Testing Fits in CMMC
Penetration testing is valuable because it tests whether defensive controls hold under adversarial conditions. It doesn't satisfy every CMMC requirement, and a test report won't substitute for access reviews, training records, incident procedures, or configuration management.
For Level 2, testing can provide direct or partial evidence for activities associated with NIST SP 800-171 requirements 3.11, 3.12, and 3.13, depending on the test design and the evidence produced. Those areas relate to risk assessment, security assessment, and system and communications protection. The test supports the assessment, but the organization still needs documented methodology, scope, findings, remediation, and retest evidence.
A mature testing program separates attack surfaces:
- External network testing examines internet-facing services, exposed administrative interfaces, and perimeter controls.
- Internal network testing examines segmentation, privilege escalation, lateral movement, and the effect of compromised credentials.
- Web application testing examines application logic, authentication, authorization, APIs, and data exposure.
Run each test against the CMMC boundary and record inherited services separately. A cloud provider or external service unit may support your controls, but you must document what it owns, what your organization owns, and how the service is assessed. Cloud encryption also doesn't automatically establish logical separation or remove an environment from scope.
Penetration testing for CMMC compliance offers a useful way to connect test design with the broader compliance evidence model. The practical objective is recurring proof: findings, severity classification, remediation tickets, retests, and updated scope records that remain useful for annual affirmations and future reassessment.
For Level 3, the testing expectation is explicit. The Level 3 guide references annual penetration testing and additional testing after significant system changes, using automated tools and subject-matter expertise. That makes continuous testing more than a security preference. It becomes part of maintaining assessment readiness.
A 90-Day Preparation Checklist for MSSPs and Security Consultancies
MSSPs should run CMMC readiness as a managed delivery program, not as a collection of ad hoc consulting tasks. Assign one program owner, one technical lead, one evidence manager, and named client owners for every remediation stream.
Days 1 through 30
Start by confirming the contract language, required level, assessment type, and CUI or FCI handling model. Then produce the assessment boundary and asset inventory.
The 30-day scoping deliverable should include:
- In-scope systems and excluded systems
- CUI data flows and storage locations
- Identity, endpoint, network, cloud, backup, and administrative dependencies
- External service providers and inherited controls
- Asset owners and evidence owners
- Initial penetration testing scope
Run an authenticated vulnerability scan and a focused external test only after the boundary is stable. Otherwise, the MSSP will generate findings against assets that later move out of scope.
Days 31 through 60
Baseline every requirement as Met, Partially Met, or Not Met. Collect existing policies, configurations, logs, access reviews, incident records, training evidence, and test artifacts into the assessment repository.
Deliver the 60-day SSP draft with system boundaries, data flows, control implementation statements, responsible roles, dependencies, and evidence references. The SSP must describe the environment. Copying a template and leaving generic language is one of the fastest ways to create assessor questions.
Days 61 through 90
Execute remediation in risk order. Retest security findings after fixes, update the POA&M where permitted, and capture closure evidence immediately. Schedule the C3PAO early enough to avoid competing for an assessment window after the environment is supposedly ready.
The 80-day mock assessment should test three things: whether the control operates, whether the evidence is easy to locate, and whether the owner can explain it without reading the SSP. Finish the remaining days with evidence normalization, leadership review, assessor coordination, and a written list of unresolved risks.
MSSPs usually underestimate evidence ownership, cloud scoping, and retest scheduling. Assign evidence owners at kickoff, document logical separation instead of assuming encryption solves it, and reserve time for verification after remediation. A clean report with unverified fixes is not readiness.
ThreatExploit AI provides automated penetration testing across web applications, internal and external networks, and cloud environments, with evidence-backed reports that can map findings to CMMC control references. If you're an MSSP or defense contractor building a repeatable testing and evidence pipeline, visit ThreatExploit AI to evaluate how it can support recurring CMMC readiness work.