The control structure for CMMC 2.0 Level 2 can be understood as a hierarchy that progresses from broad domains to specific verification criteria. At the highest level are control families—fourteen in total. In CMMC 2.0, a control family is a grouping of related security requirements organized around a shared cybersecurity domain (for example, Access Control, Incident Response, or Audit & Accountability). Each of the 110 requirements in NIST SP 800-171 Rev 2 is assigned to one of these fourteen families.
Each control family should be supported by an associated policy and/or procedure that documents how the organization implements and sustains compliance within that domain. Collectively, these governance documents form the foundation of the security program by describing the operational mechanisms—processes, responsibilities, and enforcement practices—that ensure controls are implemented consistently and effectively. In other words, while controls define what must be done, policies and procedures define how the organization does it.
Within this structure, controls represent the discrete requirements an organization must implement to achieve compliance with CMMC 2.0 Level 2. These requirements establish the security practices necessary to protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). Practically speaking, controls specify the security outcomes the organization must produce—such as limiting system access, enforcing encryption, or generating and retaining audit logs. Controls therefore represent the “what” of compliance: the expected security behaviors and conditions that must exist within the environment.
Each control is supported by one or more assessment objectives, and NIST SP 800-171 Rev 2 includes 320 assessment objectives, published in the companion document NIST SP 800-171A. Assessment objectives serve as measurable verification points used to determine whether a control is properly implemented and operating as intended. If controls represent the “what,” assessment objectives represent the “how do we know?” They translate each requirement into specific evaluative statements that guide auditors and internal assessors in validating compliance through testing, observation, and evidence review. For example, a control may require that access be restricted to authorized users, while associated assessment objectives examine whether users are identified correctly, access authorizations are managed appropriately, and access mechanisms consistently enforce permissions.
In environments that rely on a Cloud Service Provider (CSP), certain controls may be inherited or partially inherited from the CSP. CMMC-aligned CSPs—such as Microsoft or AWS—typically provide a Customer Responsibility Matrix (CRM) describing how controls are implemented within the provider’s environment and delineating responsibilities between the CSP and the customer. This enables the Organization Seeking Assessment (OSA) to clearly determine which requirements are satisfied by the CSP and which must be implemented and evidenced internally.
To evaluate compliance against NIST SP 800-171 Rev 2, organizations should apply the NIST SP 800-171 DoD Assessment Methodology (Version 1.2.1). When used alongside the assessment objectives in NIST SP 800-171A, this methodology enables organizations to calculate a Supplier Performance Risk System (SPRS) score. The resulting score can be submitted to the Department of Defense database used to evaluate contractor risk, delivery readiness, quality performance, and cybersecurity posture.
All information assembled in support of compliance must be consolidated into a System Security Plan (SSP). The SSP serves as the authoritative written description of the system boundary and the organization’s security implementation. It represents a point-in-time summary of all in-scope controls applicable to the environment and should consistently reference supporting policies, procedures, inherited responsibilities, and evidence artifacts in a uniform manner.
Where gaps, deficiencies, or exceptions exist, they should be formally documented and tracked within the organization’s risk register. In the context of CMMC 2.0, such exceptions are captured as Plans of Action and Milestones (POA&Ms). A POA&M is a structured remediation plan that documents identified security weaknesses and outlines the corrective actions required to resolve them, including assigned responsibilities, required resources, and target completion dates. POA&Ms provide a formal mechanism for continuous improvement by converting identified risks into measurable remediation efforts with clear accountability and timelines.
To sum everything up, CMMC 2.0 Level 2 compliance is built upon a structured hierarchy that begins with control families, flows down into specific NIST SP 800-171 requirements, and is validated through clearly defined assessment objectives. Together, these elements establish both the governance framework (through policies and procedures) and the technical and operational safeguards required to protect FCI and CUI. Where cloud services are used, inherited responsibilities must be documented through the CSP’s Customer Responsibility Matrix to ensure accountability is properly assigned. Compliance is measured using the DoD Assessment Methodology to produce an SPRS score, supported by evidence that demonstrates implementation effectiveness. All of these components must be consolidated into a System Security Plan that accurately reflects the in-scope environment and control implementation at a given point in time, while any gaps or deficiencies are tracked through POA&Ms as structured remediation plans—ensuring the security program remains auditable, defensible, and continuously improving.
