CMMC Level 2 Compliance: A Defense Contractor's Complete Guide

If your company holds a DoD contract — or wants one — CMMC 2.0 is no longer a distant regulatory horizon. The rule became effective December 16, 2024, and the Department of Defense has been embedding CMMC requirements into solicitations at an accelerating pace since then. If you handle Controlled Unclassified Information (CUI), you need Level 2. If you can't demonstrate it, you won't win contracts — and contracts you currently hold may be at risk at renewal.

This guide covers everything a defense contractor needs to understand about CMMC Level 2: what the framework actually requires, how the 110 security practices map to real-world systems, what your System Security Plan and Plan of Action & Milestones must contain, when you need a third-party assessor versus when you can self-attest, and what IT Center consistently finds wrong in contractor environments that thought they were ready.

What CMMC 2.0 Actually Requires

The Cybersecurity Maturity Model Certification program was comprehensively redesigned with the 2.0 revision, announced in November 2021 and finalized through a DoD rulemaking process completed in late 2024. The current version consolidates what was previously five maturity levels into three, and it grounds those levels in existing federal standards rather than creating new proprietary requirements.

The three levels are:

• Level 1 (Foundational): 17 practices drawn from FAR clause 52.204-21. Covers basic cyber hygiene for contractors that handle Federal Contract Information (FCI) but not CUI. Annual self-attestation by a company senior official.
• Level 2 (Advanced): 110 practices fully aligned with NIST SP 800-171 Revision 2. Required for contractors that handle CUI. May require triennial third-party assessment depending on contract sensitivity. The subject of this guide.
• Level 3 (Expert): 110 practices from NIST SP 800-171 plus a subset of NIST SP 800-172 requirements. Required for contractors on the most sensitive programs — highest-priority critical programs and technologies. Government-led assessments by DCSA.

Who needs Level 2? Any contractor or subcontractor whose systems process, store, or transmit CUI as defined in the CUI Registry maintained by the National Archives. CUI is a broad category that includes export-controlled technical data (EAR, ITAR), defense technical information, and certain types of procurement-sensitive information. If your contract contains DFARS clause 252.204-7012 — and virtually all DoD contracts do — you have CUI obligations and CMMC Level 2 is your target.

The 14 NIST SP 800-171 Control Families Explained

NIST SP 800-171 Revision 2 organizes 110 security requirements into 14 control families. Understanding what each family covers — and what the common failure modes are — is essential before you can scope your System Security Plan or prioritize your remediation work.

The practical weight of these families is not evenly distributed. Access Control (22 requirements) and System & Communications Protection (16 requirements) together account for more than a third of all Level 2 requirements. They are also among the most technically complex to implement correctly and the most commonly deficient in initial assessments.

System Security Plan (SSP) — What It Is, Who Writes It, What It Must Contain

The System Security Plan is the foundational document of your CMMC Level 2 posture. It is not optional, it is not a checkbox exercise, and it cannot be purchased as a template and submitted as-is. A C3PAO assessor will read your SSP in detail. Discrepancies between what the SSP claims and what they observe during the assessment are treated as non-compliance findings.

What the SSP Is

The SSP is a comprehensive, written description of how your organization implements — or plans to implement — each of the 110 NIST SP 800-171 security requirements as they apply to your specific system boundary. It describes your environment in enough technical detail that an independent assessor can understand the architecture and evaluate whether the controls you describe are actually in place.

Who Writes It

The SSP is written by the contractor — you, your IT team, or your IT partner. A C3PAO assessor does not write it for you; they assess against it. Your CISO, IT director, or MSP should own the technical sections. Your legal and compliance leadership should review the organizational policy sections. For many small-to-mid-size contractors, an experienced MSP or CMMC Registered Practitioner Organization (RPO) like IT Center effectively authors the SSP on behalf of the contractor, drawing on knowledge of the specific systems in scope.

What It Must Contain

NIST SP 800-171A provides the assessment methodology, and the DoD Assessment Methodology specifies the evidence expectations. At minimum, your SSP must address:

• System description and boundary: A narrative and diagram of all hardware, software, services, and personnel that constitute the system that handles CUI. Cloud services, remote access infrastructure, and contractor-operated systems off-site must all be addressed if CUI flows through them.
• CUI data flows: Where CUI enters your environment, where it is stored, how it moves between systems, how it exits (to customers, subcontractors, or government systems), and where it is eventually destroyed or returned.
• Implementation statements for all 110 requirements: For each requirement, the SSP must describe how you implement it — what specific technology, policy, or procedure satisfies the requirement in your specific environment. "We use Active Directory" is not an implementation statement. "Access to CUI systems is controlled through Active Directory security groups, with group membership reviewed quarterly by the IT Director per policy AD-ACCESS-001" is an implementation statement.
• Responsible roles: For each control, who is responsible for implementation and ongoing operation. This must map to real named positions in your organization, not generic titles.
• References to supporting policies and procedures: Each implementation statement should cite the internal policy document, configuration standard, or procedure that governs the control. Your SSP should not be a standalone document — it should be the top of a policy pyramid.

SSPs for CMMC Level 2 environments typically run 80 to 200 pages for a small contractor with a well-defined system boundary. Larger environments with multiple sites, cloud services, and complex CUI data flows may produce substantially larger documents. The length is not the measure of quality — completeness, specificity, and accuracy are.

Plan of Action & Milestones (POA&M) — Documenting Deficiencies Without Sinking Your Assessment

No contractor walks into a CMMC assessment with 110 out of 110 requirements fully implemented and documented. The POA&M is the mechanism for honestly acknowledging where you have gaps, committing to specific remediation timelines, and demonstrating that you are managing those gaps as a risk management activity rather than ignoring them.

What the POA&M Does

The POA&M documents each security requirement that is not yet fully implemented, describes the specific deficiency, assigns an owner, sets a target completion date, and identifies interim mitigations being used while the permanent fix is in progress. It is a living document — updated as remediation work completes and as new findings emerge.

What It Does Not Do

A POA&M does not grant permission to skip requirements indefinitely. Under CMMC 2.0 rules, a contractor may receive a conditional certification if their POA&M items meet specific criteria — the deficiencies cannot be from a defined set of high-priority requirements, and the contractor must demonstrate remediation progress on an agreed schedule. The specific list of requirements that cannot be open POA&M items at assessment time — sometimes called "POA&M-ineligible" requirements — has evolved through DoD guidance and should be verified against the current version of the CMMC Assessment Process (CAP) documentation before assessment.

How to Write a POA&M That Helps Rather Than Hurts

The strategic error many contractors make is treating the POA&M as an admission of failure rather than as a demonstration of mature risk management. Assessors are not grading you on having zero POA&M items — they are assessing whether you have a credible, actively managed remediation program. A POA&M with 15 items, clear owners, realistic timelines, and documented interim controls signals a contractor that knows their environment. A POA&M with two vague items and no assigned owners signals a contractor that hasn't looked hard enough.

Each POA&M entry should include: the NIST SP 800-171 requirement identifier (e.g., 3.1.3), a plain-language description of the gap, the root cause (missing technology, missing policy, or missing procedure), the interim mitigation in place while remediation is underway, the name and title of the person responsible for remediation, and the scheduled completion date. Dates should be specific — "Q3 2026" is not a milestone date; "September 15, 2026" is.

C3PAO vs. Self-Attestation — When Each Applies at Level 2

CMMC 2.0 introduced a distinction within Level 2 that the original CMMC 1.0 did not have: not all Level 2 contracts require a third-party assessment. Understanding which path applies to your specific contract is essential — choosing the wrong one is both a compliance failure and a waste of resources.

Self-Attestation (Affirming Your Own Compliance)

For Level 2 contracts that DoD has designated as lower sensitivity or lower criticality, a company senior official may submit an annual self-attestation affirming that the contractor meets all 110 NIST SP 800-171 requirements. This attestation is submitted through the Supplier Performance Risk System (SPRS) and is a legally binding statement — submitting a false attestation is a potential violation of the False Claims Act, with qui tam exposure and civil penalties that dwarf the value of most contracts.

Self-attestation does not mean no documentation. You must still have a completed SSP, a POA&M, supporting policies, and the technical controls in place. The difference is that no external assessor verifies the documentation before you submit. That verification happens only if DoD initiates a review — which they increasingly do on the basis of SPRS scores that appear inconsistent with contract scope.

Third-Party Assessment by a C3PAO

For contracts that DoD has designated as requiring a third-party assessment — typically those involving more sensitive CUI categories or programs of higher criticality — the contractor must engage a CMMC Third-Party Assessment Organization (C3PAO) authorized by the CMMC Accreditation Body (Cyber AB). The C3PAO conducts a formal assessment, interviews personnel, reviews documentation, and tests technical controls. A successful assessment results in a certification that is entered into eMASS and shared with DoD.

The C3PAO assessment is a significant undertaking. Expect a 2–5 day on-site (or hybrid remote/on-site) assessment for a small-to-mid contractor, with a preparation period of several months. The C3PAO will request documentation in advance — SSP, POA&M, supporting policies, network diagrams, asset inventory, and evidence packages for specific controls. Surprises during the assessment are expensive: findings that could have been remediated in preparation become open POA&M items that can delay or condition your certification.

How do you know which path applies? The solicitation or your contracting officer's technical representative (COTR) will specify the CMMC level and assessment type required in the contract language. If your existing contract was awarded before CMMC clauses were embedded, engage your contracting officer to understand what will be required at the next option period or recompete.

Common CMMC Gaps IT Center Finds in Contractor Environments

We have assessed and helped remediate CMMC Level 2 environments across a range of defense contractors — from small machine shops with a single CUI workstation to mid-size engineering firms with complex multi-site architectures. Certain deficiencies appear so consistently that we consider them baseline expectations for a first-time assessment.

• 1
  Non-compliant MFA implementation. Requirement 3.5.3 mandates multi-factor authentication for local and network access to privileged accounts and for all network access to non-privileged accounts. The most common failure is Microsoft 365 with MFA enforced for some users but not all — particularly shared mailboxes, service accounts, and accounts used by external IT vendors. Every account that can access a system containing CUI must have MFA enforced without exception. Authenticator apps are acceptable; SMS is acceptable but not preferred; hardware tokens (YubiKey, etc.) are the strongest option for privileged access.
• 2
  Missing or incomplete audit logs. Requirement 3.3.1 mandates logging of user activities, exceptions, and security events. In practice, we find contractors running Windows environments where Windows Security Event Logging is either disabled, configured at a level too low to capture the required events, or generating logs that are not retained for any meaningful period. NIST SP 800-171A specifies that logs must cover logon/logoff events, object access, policy changes, privilege use, and account management. A SIEM or centralized log management platform is effectively required for any environment with more than a handful of systems.
• 3
  Unencrypted CUI at rest and in transit. Requirement 3.13.8 (encryption in transit) and 3.13.16 (encryption at rest) together mandate that CUI is protected by FIPS-validated cryptography. The most common failures: email containing CUI sent without encryption (standard SMTP is not acceptable for CUI transmission), laptops without BitLocker or FileVault enabled and key-management documented, and network shares on Windows file servers accessible without encryption. Microsoft 365 Government Community Cloud (GCC) or GCC High is the standard platform for email and collaboration CUI; standard commercial M365 is not CMMC-authorized for CUI without additional configuration and documentation.
• 4
  No documented disaster recovery or continuity plan. Requirement 3.6.1 addresses incident response, and the broader context of Security Assessment (CA) family requirements effectively requires that you can demonstrate recovery capability. In practice, contractors frequently have backups but no documented recovery time objective (RTO), no tested recovery procedure, and no business continuity plan. During an assessment, being unable to describe how long it would take to restore CUI systems from backup — and being unable to produce evidence of a test restoration — is a finding against multiple requirements simultaneously.
• 5
  Undefined or unenforced configuration baselines. Configuration Management (CM) requires documented baseline configurations for all CUI-handling systems and a process for managing deviations. What we find instead are ad hoc configurations across endpoints and servers with no documented standard, no mechanism for detecting drift, and no change control process. A Group Policy Object that enforces a documented security baseline, with alerting for GPO changes, satisfies the technical requirement. Without it, you cannot claim compliance with 3.4.1 through 3.4.9.

Implementation Timeline: A Realistic 6-to-12 Month Roadmap

Contractors who engage with CMMC preparation for the first time frequently underestimate the lead time required. Below is a realistic phased timeline based on what it actually takes to move from an assessed baseline to a defensible SSP and a passing C3PAO assessment.

Months 1–2: Scoping and Gap Assessment

Before you can remediate, you need to know where you stand. This phase involves defining your assessment boundary — which systems, people, and locations handle CUI — and conducting a structured gap assessment against all 110 requirements. The output is a scored baseline (mirroring the SPRS scoring methodology, which assigns point values to each requirement) and a prioritized list of deficiencies. IT Center conducts this assessment using the DoD Assessment Methodology and NIST SP 800-171A assessment procedures, producing a gap report that maps directly to SSP and POA&M structure.

Months 2–5: Remediation — Technical Controls

Technical remediation includes MFA enforcement across all accounts, EDR deployment on all endpoints, centralized log management configuration, network segmentation implementation (separating CUI-handling systems from general corporate networks), BitLocker encryption enrollment and key escrow configuration, vulnerability scanning baseline and patch management cadence establishment, and cloud environment configuration hardening (Azure Government, M365 GCC/GCC High as applicable). Technical remediation is the longest phase and should begin immediately after the gap assessment, in priority order by requirement weight and remediation complexity.

Months 3–7: Policy and Documentation Development

Running in parallel with technical remediation, this phase produces the policy library that supports the SSP. Required policies include: Information Security Policy, Access Control Policy and Procedures, Incident Response Plan and Procedures, Configuration Management Policy, Media Protection Policy, Awareness and Training Policy and annual training completion records, System and Communications Protection Policy, and Maintenance Policy. Each policy must be version-controlled, reviewed and approved by named organizational leadership, and referenced appropriately in the SSP. Generic downloadable policy templates may provide a structural starting point, but every policy must be tailored to describe your actual organization and systems — not a hypothetical contractor.

Months 6–9: SSP Drafting and Internal Review

With technical controls implemented and policy library complete, the SSP can be drafted in full. This phase also involves an internal mock assessment — walking through the NIST SP 800-171A assessment procedures as if you were the C3PAO, producing evidence packages for each requirement, and identifying any remaining gaps before the formal assessment. Evidence packages typically include screenshots, configuration exports, log samples, policy documents, and records of periodic activities (training completion, vulnerability scan reports, access reviews). The mock assessment outputs a final-state POA&M with only those items that remain genuinely open at assessment time.

Months 9–12: C3PAO Engagement and Assessment

Engage a C3PAO through the Cyber AB marketplace 60–90 days before your target assessment date. Provide the SSP and supporting documentation in advance per the C3PAO's pre-assessment checklist. The assessment itself spans multiple days and covers document review, personnel interviews, and technical testing. Post-assessment, the C3PAO issues a Final Assessment Report and the certification (or conditional certification with open POA&M items) is submitted to eMASS. Ongoing maintenance — annual SPRS attestation updates, policy reviews, vulnerability scan reporting — begins immediately after certification.

The 6-to-12 month timeline assumes a starting point with some existing IT infrastructure and at least partial policy documentation. Organizations starting from a near-zero baseline — common in small subcontractors that have never invested in formal security programs — should plan toward the 12-month end of the range, with the possibility of a conditional certification followed by continued remediation.

How IT Center Supports Defense Contractors Through CMMC Level 2

IT Center is not a compliance documentation shop that produces paperwork without technical capability behind it. We are a managed IT and cybersecurity firm with direct hands-on experience implementing the technical controls that NIST SP 800-171 requires — in actual contractor environments, on actual production systems, with actual assessors reviewing the results.

Our CMMC Level 2 engagement begins with the gap assessment and ends with a contractor who can walk into a C3PAO assessment with confidence. We deploy and manage the technical stack: EDR, SIEM, MFA, encrypted endpoints, network segmentation, patch management, and vulnerability scanning. We author or co-author the SSP in partnership with your team, using implementation statements that reflect how your specific systems actually work. We build the policy library, conduct the internal mock assessment, prepare your staff for assessor interviews, and remain available during the C3PAO assessment to support evidence retrieval and technical questions.

We also provide ongoing managed compliance — maintaining your SSP currency as systems change, managing your POA&M through the remediation lifecycle, running periodic vulnerability scans and reporting against the SPRS scoring methodology, and keeping your annual self-attestation or C3PAO recertification on track.

If you hold DoD contracts with CUI obligations, the question is not whether CMMC is coming — it is already here. The question is whether you will be ready before it costs you a contract.