CMMC Toolkit Wiki - User contributions [en]

Main Page

2026-04-24T14:32:02Z

David:

32 CFR Part 170

2026-03-02T01:33:24Z

David:

'''Source of Reference: The official [https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program Cybersecurity Maturity Model Certification (CMMC) Program] final rule.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== PART 170 - CYBERSECURITY MATURITY MODEL CERTIFICATION (CMMC) PROGRAM ==

=== Subpart A - General Information ===
Sec.
* 170.1 Purpose.
* 170.2 Incorporation by reference.
* 170.3 Applicability.
* 170.4 Acronyms and definitions.
* 170.5 Policy.

=== Subpart B - Government Roles and Responsibilities ===
* 170.6 CMMC PMO.
* 170.7 DCMA DIBCAC.

=== Subpart C - CMMC Assessment and Certification Ecosystem ===
* 170.8 Accreditation Body.
* 170.9 CMMC Third-Party Assessment Organizations (C3PAOs).
* 170.10 CMMC Assessor and Instructor Certification Organization (CAICO).
* 170.11 CMMC Certified Assessor (CCA).
* 170.12 CMMC Instructor.
* 170.13 CMMC Certified Professional (CCP).

=== Subpart D - Key Elements of the CMMC Program ===
* 170.14 CMMC Model.
* 170.15 CMMC Level 1 self-assessment and affirmation requirements.
* 170.16 CMMC Level 2 self-assessment and affirmation requirements.
* 170.17 CMMC Level 2 certification assessment and affirmation requirements.
* 170.18 CMMC Level 3 certification assessment and affirmation requirements.
* 170.19 CMMC scoping.
* 170.20 Standards acceptance.
* 170.21 Plan of Action and Milestones requirements.
* 170.22 Affirmation.
* 170.23 Application to subcontractors.
* 170.24 CMMC Scoring Methodology.
* Appendix A to Part 170 - Guidance

'''Authority''': 5 U.S.C. 301; Sec. 1648, Pub. L. 116-92, 133 Stat. 1198.

== Subpart A - General Information. ==
=== § 170.1 Purpose. ===
(a) This part describes the Cybersecurity Maturity Model Certification (CMMC) Program of the Department of Defense (DoD) and establishes requirements for defense contractors and subcontractors to implement prescribed cybersecurity standards for safeguarding Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). This part (the CMMC Program) also establishes requirements for conducting an assessment of compliance with the applicable prescribed cybersecurity standard for contractor information systems that: process, store, or transmit FCI or CUI; provide security protections for systems which process, store, or transmit CUI; or are not logically or physically isolated from systems which process, store, or transmit CUI.

(b) The CMMC Program provides DoD with a viable means of conducting the volume of assessments necessary to verify contractor and subcontractor implementation of required cybersecurity requirements.

(c) The CMMC Program is designed to ensure defense contractors are properly safeguarding FCI and CUI that is processed, stored, or transmitted on defense contractor information systems. FCI and CUI must be protected to meet evolving threats and safeguard nonpublic, unclassified information that supports and enables the warfighter. The CMMC Program provides a consistent methodology to assess a defense contractor’s implementation of required cybersecurity requirements. The CMMC Program utilizes the security standards set forth in the 48 CFR 52.204-21; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, ''Basic Safeguarding of Covered Contractor Information Systems, ''Revision 2, February 2020 (includes updates as of January 28, 2021) (NIST SP 800-171 R2); and selected requirements from the NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, ''February 2021 (NIST SP 800-172 Feb2021), as applicable (see table 1 to § 170.14(c)(4) for requirements, see § 170.2 for availability of NIST publications).

(d) The CMMC Program balances the need to safeguard FCI and CUI and the requirement to share information appropriately with defense contractors in order to develop capabilities for the DoD. The CMMC Program is designed to ensure implementation of cybersecurity practices for defense contractors and to provide DoD with increased assurance that FCI and CUI information will be adequately safeguarded when residing on or transiting contractor information systems.

(e) The CMMC Program creates no right or benefit, substantive or procedural, enforceable by law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.

=== § 170.2 Incorporation by reference. ===

Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. Material approved for incorporation by reference (IBR) is available for inspection at the Department of Defense (DoD) and at the National Archives and Records Administration (NARA). Contact DoD online: ''https://DoDcio.defense.gov/CMMC/''; email: ''osd.mc-alex.DoD-cio.mbx.cmmc-rule@mail.mil''; or phone: (202) 770-9100. For information on the availability of this material at NARA, visit: ''www.archives.gov/federal-register/ cfr/ibr-locations'' or email: ''fr.inspection@nara.gov''. The material may be obtained from the following sources:

(a) National Institute of Standards and Technology, U.S. Department of Commerce, 100 Bureau Drive, Gaithersburg, MD 20899; phone: (301) 975-8443; website: ''https://csrc.nist.gov/ publications/''.

(1) FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006 (FIPS PUB 200 Mar2006); IBR approved for § 170.4(b).

(2) FIPS PUB 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022 (FIPS PUB 201-3 Jan2022); IBR approved for § 170.4(b).

(3) SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, Revision 2, December 2018 (NIST SP 800-37 R2); IBR approved for § 170.4(b).

(4) SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, March 2011 (NIST SP 800-39 Mar2011); IBR approved for § 170.4(b).

(5) SP 800-53, Security and Privacy Controls for Information Systems and Organizations, Revision 5, September 2020 (includes updates as of December 10, 2020) (NIST SP 800-53 R5); IBR approved for § 170.4(b).

(6) SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023 (NIST SP 800-82r3); IBR approved for § 170.4(b).

(7) SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008 (NIST SP 800-115 Sept2008); IBR approved for § 170.4(b).

(8) SP 800-160, Volume 2, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, Revision 1, December 2021 (NIST SP 800-160 V2R1); IBR approved for § 170.4(b).

(9) SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 2, February 2020 (includes updates as of January 28, 2021), (NIST SP 800-171 R2); IBR approved for §§ 170.4(b) and 170.14(a) through (c).

(10) SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information, June 2018 (NIST SP 800-171A Jun2018); IBR approved for §§ 170.11(a), 170.14(d), 170.15(c), 170.16(c), 170.17(c), and 170.18(c).

(11) SP 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, February 2021 (NIST SP 800-172 Feb2021); IBR approved for §§ 170.4(b), 170.5(a), and 170.14(a) and (c).

(12) SP 800-172A, Assessing Enhanced Security Requirements for Controlled Unclassified Information, March 2022 (NIST SP 800-172A Mar2022); IBR approved for §§ 170.4(b), 170.14(d), and 170.18(c).

(b) International Organization for Standardization (ISO) Chemin de Blandonnet 8, CP 401 - 1214 Vernier, Geneva, Switzerland; phone: +41 22 749 01 11; website: ''www.iso.org/popular- standards.html''.

(1) ISO/IEC 17011:2017(E), Conformity assessment - Requirements for accreditation bodies accrediting conformity assessment bodies, Second edition, November 2017 (ISO/IEC 17011:2017(E)); IBR approved for §§ 170.8(b)(3), 170.9(b)(13), and 170.10(b)(4).

(2) ISO/IEC 17020:2012(E), Conformity assessment - Requirement for the operation of various types of bodies performing inspection, Second edition, March 1, 2012 (ISO/IEC 17020:2012(E)); IBR approved for §§ 170.8(a), (b)(1), (b)(3) and 170.9(b)(2) and (b)(13).

(3) ISO/IEC 17024:2012(E), Conformity assessment - General requirements for bodies operating certification of persons, second edition, July 1, 2012 (ISO/IEC 17024:2012(E)); IBR approved for §§ 170.8(b)(2) and 170.10(a) and (b)(4), (7), and (8).

'''Note 1 to paragraph (b):''' The ISO/IEC standards incorporated by reference in this part may be viewed at no cost in ‘‘read only’’ format at ''https://ibr.ansi.org''.

=== § 170.3 Applicability. ===

(a) The requirements of this part apply to:

(1) All DoD contract and subcontract awardees that will process, store, or transmit information, in performance of the DoD contract, that meets the standards for FCI or CUI on contractor information systems; and,

(2) Private-sector businesses or other entities comprising the CMMC Assessment and Certification Ecosystem, as specified in subpart C of this part.

(b) The requirements of this part do not apply to Federal information systems operated by contractors or subcontractors on behalf of the Government.

(c) CMMC Program requirements apply to all DoD solicitations and contracts pursuant to which a defense contractor or subcontractor will process, store, or transmit FCI or CUI on unclassified contractor information systems, including those for the acquisition of commercial items (except those exclusively for COTS items) valued at greater than the micro- purchase threshold except under the following circumstances:

(1) The procurement occurs during Implementation Phase 1, 2, or 3 as described in paragraph (e) of this section, in which case CMMC Program requirements apply in accordance with the requirements for the relevant phase- in period; or

(2) Application of CMMC Program requirements to a procurement or class of procurements may be waived in advance of the solicitation at the discretion of DoD in accordance with all applicable policies, procedures, and approval requirements.

(d) DoD Program Managers or requiring activities are responsible for selecting the CMMC Status that will apply for a particular procurement or contract based upon the type of information, FCI or CUI, that will be processed on, stored on, or transmitted through a contractor information system. Application of the CMMC Status for subcontractors will be determined in accordance with § 170.23.

(e) DoD is utilizing a phased approach for the inclusion of CMMC Program requirements in solicitations and contracts. Implementation of CMMC Program requirements will occur over four (4) phases:

(1) ''Phase 1''. Begins on the effective date of the complementary 48 CFR part 204 CMMC Acquisition final rule. DoD intends to include the requirement for CMMC Statuses of Level 1 (Self) or Level 2 (Self) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, include the requirement for CMMC Status of Level 1 (Self) or Level 2 (Self) for applicable DoD solicitations and contracts as a condition to exercise an option period on a contract awarded prior to the effective date. DoD may also, at its discretion, include the requirement for CMMC Status of Level 2 (C3PAO) in place of the Level 2 (Self) CMMC Status for applicable DoD solicitations and contracts.

(2) ''Phase 2''. Begins one calendar year following the start date of Phase 1. In addition to Phase 1 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 2 (C3PAO) to an option period instead of as a condition of contract award. DoD may also, at its discretion, include the requirement for CMMC Status of Level 3 (DIBCAC) for applicable DoD solicitations and contracts.

(3) ''Phase 3''. Begins one calendar year following the start date of Phase 2. In addition to Phase 1 and 2 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for all applicable DoD solicitations and contracts as a condition of contract award and as a condition to exercise an option period on a contract awarded after the effective date. DoD intends to include the requirement for CMMC Status of Level 3 (DIBCAC) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 3 (DIBCAC) to an option period instead of as a condition of contract award.

(4) ''Phase 4, full implementation''. Begins one calendar year following the start date of Phase 3. DoD will include CMMC Program requirements in all applicable DoD solicitations and contracts including option periods on contracts awarded prior to the beginning of Phase 4.

=== § 170.4 Acronyms and definitions. ===

(a) ''Acronyms. ''Unless otherwise noted, the following acronyms and their terms are for the purposes of this part.

AC - Access Control 
APT - Advanced Persistent Threat 
AT - Awareness and Training 
C3PAO - CMMC Third-Party Assessment Organization 
CA - Security Assessment CAICO - CMMC Assessors and Instructors Certification Organization 
CAGE - Commercial and Government Entity 
CCA - CMMC-Certified Assessor 
CCI - CMMC-Certified Instructor 
CCP - CMMC-Certified Professional 
CFR - Code of Federal Regulations 
CIO - Chief Information Officer 
CM - Configuration Management 
CMMC - Cybersecurity Maturity Model Certification 
CMMC PMO - CMMC Program Management Office 
CNC - Computerized Numerical Control 
CoPC - Code of Professional Conduct 
CSP - Cloud Service Provider 
CUI - Controlled Unclassified Information 
DCMA - Defense Contract Management Agency 
DD - Represents any two-character CMMC Domain acronym 
DFARS - Defense Federal Acquisition Regulation Supplement 
DIB - Defense Industrial Base 
DIBCAC - DCMA’s Defense Industrial Base Cybersecurity Assessment Center 
DoD - Department of Defense DoDI - Department of Defense Instruction 
eMASS - Enterprise Mission Assurance Support Service 
ESP - External Service Provider 
FAR - Federal Acquisition Regulation 
FCI - Federal Contract Information 
FedRAMP - Federal Risk and Authorization Management Program 
GFE - Government Furnished Equipment 
IA - Identification and Authentication 
ICS - Industrial Control System 
IIoT - Industrial Internet of Things 
IoT - Internet of Things 
IR - Incident Response 
IS - Information System 
IEC - International Electrotechnical Commission 
ISO/IEC - International Organization for Standardization/International Electrotechnical Commission 
IT - Information Technology 
L# - CMMC Level Number 
MA - Maintenance 
MP - Media Protection 
MSSP - Managed Security Service Provider 
NARA - National Archives and Records Administration 
NAICS - North American Industry Classification System 
NIST - National Institute of Standards and Technology 
N/A - Not Applicable 
ODP - Organization-Defined Parameter 
OSA - Organization Seeking Assessment 
OSC - Organization Seeking Certification 
OT - Operational Technology 
PI - Provisional Instructor 
PIEE - Procurement Integrated Enterprise Environment 
PII - Personally Identifiable Information 
PLC - Programmable Logic Controller 
POA&M - Plan of Action and Milestones 
PRA - Paperwork Reduction Act 
RM - Risk Management 
SAM - System of Award Management 
SC - System and Communications Protection 
SCADA - Supervisory Control and Data Acquisition 
SI - System and Information Integrity 
SIEM - Security Information and Event Management 
SP - Special Publication 
SPD - Security Protection Data 
SPRS - Supplier Performance Risk System 
SSP - System Security Plan 

(b) ''Definitions''. Unless otherwise noted, these terms and their definitions are for the purposes of this part.

''Access Control (AC) ''means the process of granting or denying specific requests to obtain and use information and related information processing services; and/or entry to specific physical facilities (''e.g., ''Federal buildings, military establishments, or border crossing entrances), as defined in FIPS PUB 201-3 Jan2002 (incorporated by reference, see § 170.2).

''Accreditation'' means a status pursuant to which a CMMC Assessment and Certification Ecosystem member (person or organization), having met all criteria for the specific role they perform including required ISO/IEC accreditations, may act in that role as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC- custom term)

''Accreditation Body'' is defined in § 170.8 and means the one organization DoD contracts with to be responsible for authorizing and accrediting members of the CMMC Assessment and Certification Ecosystem, as required. The Accreditation Body must be approved by DoD. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program. (CMMC-custom term)

''Advanced Persistent Threat (APT) ''means an adversary that possesses sophisticated levels of expertise and significant resources that allow it to create opportunities to achieve its objectives by using multiple attack vectors (''e.g.'', cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period-of-time, adapts to defenders’ efforts to resist it, and is determined to maintain the level of interaction needed to execute its objectives, as is defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Affirming Official'' means the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations. (CMMC-custom term)

''Assessment'' means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in §§ 170.15 through 170.18. (CMMC-custom term)

(i) ''Level 1 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 1 (Self).

(ii) ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).

(iii) ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).

(iv) ''Level 3 certification assessment'' is the term for the activity performed by the DCMA DIBCAC to evaluate the information system of an OSC when seeking a CMMC Status of Level 3 (DIBCAC).

(v) ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).

(vi) ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.

''Assessment Findings Report'' means the final written assessment results by the third-party or government assessment team. The Assessment Findings Report is submitted to the OSC and to the DoD via CMMC eMASS. (CMMC-custom term)

''Assessment objective'' means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) or NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). (CMMC-custom term)

''Assessment Team'' means participants in the Level 2 certification assessment (CMMC Certified Assessors and CMMC Certified Professionals) or the Level 3 certification assessment (DCMA DIBCAC assessors). This does not include the OSC participants preparing for or participating in the assessment. (CMMC-custom term)

''Asset'' means an item of value to stakeholders. An asset may be tangible (''e.g.'', a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (''e.g.'', humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Asset Categories'' means a grouping of assets that process, store or transmit information of similar designation, or provide security protection to those assets. (CMMC-custom term)

''Authentication'' is defined in FIPS PUB 200 Mar2006 (incorporated by reference, see § 170.2).

''Authorized'' means an interim status during which a CMMC Ecosystem member (person or organization), having met all criteria for the specific role they perform other than the required ISO/IEC accreditations, may act in that role for a specified time as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC-custom term)

''Capability'' means a combination of mutually reinforcing controls implemented by technical means, physical means, and procedural means. Such controls are typically selected to achieve a common information security or privacy purpose, as defined in NIST SP 800-37 R2 (incorporated by reference, see § 170.2).

''Cloud Service Provider (CSP) ''means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable computing resources (''e.g.'', networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This definition is based on the definition for cloud computing in NIST SP 800-145 Sept2011. (CMMC-custom term)

''CMMC Assessment and Certification Ecosystem'' means the people and organizations described in subpart C of this part. This term is sometimes shortened to CMMC Ecosystem. (CMMC-custom term)

''CMMC Assessment Scope'' means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements. (CMMC-custom term)

''CMMC Assessor and Instructor Certification Organization (CAICO) ''is defined in § 170.10 and means the organization responsible for training, testing, authorizing, certifying, and recertifying CMMC certified assessors, certified instructors, and certified professionals. (CMMC-custom term)

''CMMC Instantiation of eMASS'' means a CMMC instance of the Enterprise Mission Assurance Support Service (eMASS), a government owned and operated system. (CMMC-custom term)

''CMMC Security Requirements'' means the 15 Level 1 requirements listed in the 48 CFR 52.204-21(b)(1), the 110 Level 2 requirements from NIST SP 800-171 R2 (incorporated by reference, see § 170.2), and the 24 Level 3 requirements selected from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2).

''CMMC Status'' is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC. The potential CMMC Statuses are outlined in the paragraphs that follow. (CMMC-custom term)

(i) ''Final Level 1 (Self) ''is defined in § 170.15(a)(1) and (c)(1). (CMMC-custom term)

(ii) ''Conditional Level 2 (Self) ''is defined in § 170.16(a)(1)(ii). (CMMC- custom term)

(iii) ''Final Level 2 (Self) ''is defined in § 170.16(a)(1)(iii). (CMMC-custom term)

(iv) ''Conditional Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(ii). (CMMC- custom term)

(v) ''Final Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(iii). (CMMC-custom term)

(vi) ''Conditional Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(ii). (CMMC- custom term)

(vii) ''Final Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(iii). (CMMC-custom term)

''CMMC Status Date'' means the date that the CMMC Status results are submitted to SPRS or the CMMC instantiation of eMASS, as appropriate. The date of the Conditional CMMC Status will remain as the CMMC Status Date after a successful POA&M closeout. A new date is not set for a Final that follows a Conditional. (CMMC-custom term)

''CMMC Third-Party Assessment Organization (C3PAO) ''means an organization that has been authorized or accredited by the Accreditation Body to conduct Level 2 certification assessments and has the roles and responsibilities identified in § 170.9. (CMMC-custom term)

''Contractor'' is defined in 48 CFR 3.502-1.

''Contractor Risk Managed Assets'' are defined in table 3 to § 170.19(c)(1). (CMMC-custom term)

''Controlled Unclassified Information (CUI) ''is defined in 32 CFR 2002.4(h).

''Controlled Unclassified Information (CUI) Assets'' means assets that can process, store, or transmit CUI. (CMMC- custom term)

''DCMA DIBCAC High Assessment'' means an assessment that is conducted by Government personnel in accordance with NIST SP 800-171A Jun2018 and leveraging specific guidance in the DoD Assessment Methodology that:

(i) Consists of: (A) A review of a contractor’s Basic Assessment;

(B) A thorough document review;

(C) Verification, examination, and demonstration of a contractor’s system security plan to validate that NIST SP 800-171 R2 security requirements have been implemented as described in the contractor’s system security plan; and

(D) Discussions with the contractor to obtain additional information or clarification, as needed; and

(ii) Results in a confidence level of ‘‘High’’ in the resulting score. (Source: 48 CFR 252.204-7020).

''Defense Industrial Base (DIB) ''is defined in 32 CFR 236.2.

''DoD Assessment Methodology (DoDAM) ''documents a standard methodology that enables a strategic assessment of a contractor’s implementation of NIST SP 800-171 R2, a requirement for compliance with 48 CFR 252.204-7012. (Source: DoDAM Version 1.2.1)

''Enduring Exception'' means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be enduring exceptions. (CMMC-custom term)

''Enterprise'' means an organization with a defined mission/goal and a defined boundary, using information systems to execute that mission, and with responsibility for managing its own risks and performance. An enterprise may consist of all or some of the following business aspects: acquisition, program management, financial management (''e.g.'', budgets), human resources, security, and information systems, information and mission management, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''External Service Provider (ESP) ''means external people, technology, or facilities that an organization utilizes for provision and management of IT and/or cybersecurity services on behalf of the organization. In the CMMC Program, CUI or Security Protection Data (''e.g.'', log data, configuration data), must be processed, stored, or transmitted on the ESP assets to be considered an ESP. (CMMC-custom term)

''Federal Contract Information (FCI) ''is defined in 48 CFR 4.1901.

''Government Furnished Equipment (GFE) ''has the same meaning as ‘‘government-furnished property’’ as defined in 48 CFR 45.101.

''Industrial Control Systems (ICS) ''means a general term that encompasses several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations that are often found in the industrial sectors and critical infrastructures, such as Programmable Logic Controllers (PLC). An ICS consists of combinations of control components (''e.g.'', electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (''e.g.'', manufacturing, transportation of matter or energy), as defined in NIST SP 800-82r3 (incorporated by reference, see § 170.2).

''Information System (IS) ''is defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

''Internet of Things (IoT) ''means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Operational plan of action'' as used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies (''e.g.'', necessary information system updates, patches, or reconfiguration as threats evolve) in implementation of requirements and documents how they will be mitigated, corrected, or eliminated. The OSA defines the format (''e.g.'', document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment for remediation of deficiencies that must be completed within 180 days. (CMMC- custom term)

''Operational Technology (OT) ''means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Organization-defined'' means as determined by the OSA except as defined in the case of Organization- Defined Parameter (ODP). (CMMC- custom term)

''Organization-Defined Parameters (ODPs) ''means selected enhanced security requirements contain selection and assignment operations to give organizations flexibility in defining variable parts of those requirements, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Note 1 to ODPs:'' The organization defining the parameters is the DoD.

''Organization Seeking Assessment (OSA) ''means the entity seeking to undergo a self-assessment or certification assessment for a given information system for the purposes of achieving and maintaining any CMMC Status. The term OSA includes all Organizations Seeking Certification (OSCs). (CMMC-custom term)

''Organization Seeking Certification (OSC) ''means the entity seeking to undergo a certification assessment for a given information system for the purposes of achieving and maintaining the CMMC Status of Level 2 (C3PAO) or Level 3 (DIBCAC). An OSC is also an OSA. (CMMC-custom term)

''Out-of-Scope Assets'' means assets that cannot process, store, or transmit CUI because they are physically or logically separated from information systems that do process, store, or transmit CUI, or are inherently unable to do so; except for assets that provide security protection for a CUI asset (see the definition for ''Security Protection Assets''). (CMMC- custom term)

''Periodically'' means occurring at a regular interval as determined by the OSA that may not exceed one year. (CMMC-custom term)

''Personally Identifiable Information'' means information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Plan of Action and Milestones (POA&M) ''means a document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in NIST SP 800-115 Sept2008 (incorporated by reference, see § 170.2).

''Prime Contractor'' is defined in 48 CFR 3.502-1.

''Process, store, or transmit'' means data can be used by an asset (''e.g.'', accessed, entered, edited, generated, manipulated, or printed); data is inactive or at rest on an asset (''e.g.'', located on electronic media, in system component memory, or in physical format such as paper documents); or data is being transferred from one asset to another asset (''e.g.'', data in transit using physical or digital transport methods). (CMMC-custom term)

''Restricted Information Systems'' means systems (and associated IT components comprising the system) that are configured based on government requirements (''e.g.'', connected to something that was required to support a functional requirement) and are used to support a contract (''e.g.'', fielded systems, obsolete systems, and product deliverable replicas). (CMMC-custom term)

''Risk'' means a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of:

(i) The adverse impacts that would arise if the circumstance or event occurs; and

(ii) The likelihood of occurrence, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Risk Assessment'' means the process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. Risk Assessment is part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis, as defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Security Protection Assets (SPA) ''means assets providing security functions or capabilities for the OSA’s CMMC Assessment Scope. (CMMC- custom term)

''Security Protection Data (SPD) ''means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC’s assessed environment. SPD is security relevant information and includes but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment. (CMMC-custom term)

''Specialized Assets'' means types of assets considered specialized assets for CMMC: Government Furnished Equipment, Internet of Things (IoT) or Industrial Internet of Things (IIoT), Operational Technology (OT), Restricted Information Systems, and Test Equipment. (CMMC-custom term)

''Subcontractor'' is defined in 48 CFR 3.502-1.

''Supervisory Control and Data Acquisition (SCADA) ''means a generic name for a computerized system that is capable of gathering and processing data and applying operational controls over long distances. Typical uses include power transmission and distribution and pipeline systems. SCADA was designed for the unique communication challenges (''e.g.'', delays, data integrity) posed by the various media that must be used, such as phone lines, microwave, and satellite. Usually shared rather than dedicated, as defined in NIST SP 800- 82r3 (incorporated by reference, see § 170.2).

''System Security Plan (SSP) ''means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Temporary deficiency'' means a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency. (CMMC-custom term)

''Test Equipment'' means hardware and/ or associated IT components used in the testing of products, system components, and contract deliverables. (CMMC- custom term)

''User'' means an individual, or (system) process acting on behalf of an individual, authorized to access a system, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

=== § 170.5 Policy. ===

(a) Protection of FCI and CUI on contractor information systems is of paramount importance to the DoD and can directly impact its ability to successfully conduct essential missions and functions. It is DoD policy that defense contractors and subcontractors shall be required to safeguard FCI and CUI that is processed, stored, or transmitted on contractor information systems by applying specified security requirements. In addition, defense contractors and subcontractors may be required to implement additional safeguards defined in NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2), implementing DoD specified parameters to meet CMMC Level 3 security requirements (see table 1 to § 170.14(c)(4)). These additional requirements are necessary to protect CUI being processed, stored, or transmitted in contractor information systems, when designated by a requirement for CMMC Status of Level 3 (DIBCAC) as defined by a DoD program manager or requiring activity. In general, the Department will identify a requirement for a CMMC Status of Level 3 (DIBCAC) for solicitations and resulting contracts supporting its most critical programs and technologies.

(b) Program managers and requiring activities are responsible for identifying the CMMC Status that will apply to a procurement. Selection of the applicable CMMC Status will be based on factors including but not limited to:

(1) Criticality of the associated mission capability;

(2) Type of acquisition program or technology;

(3) Threat of loss of the FCI or CUI to be shared or generated in relation to the effort;

(4) Impacts from exploitation of information security deficiencies; and

(5) Other relevant policies and factors, including Milestone Decision Authority guidance.

(c) In accordance with the implementation plan described in § 170.3, CMMC Program requirements will apply to new DoD solicitations and contracts, and shall flow down to subcontractors who will process, store, or transmit FCI or CUI in performance of the subcontract, as described in § 170.23.

(d) In very limited circumstances, and in accordance with all applicable policies, procedures, and requirements, a Service Acquisition Executive or Component Acquisition Executive in the DoD, or as delegated, may elect to waive inclusion of CMMC Program requirements in a solicitation or contract. In such cases, contractors and subcontractors will remain obligated to comply with all applicable cybersecurity and information security requirements.

(e) The CMMC Program does not alter any separately applicable requirements to protect FCI or CUI, including those requirements in accordance with 48 CFR 52.204-21'', Basic Safeguarding of Covered Contractor Information Systems'', or covered defense information in accordance with 48 CFR 252.204- 7012'', Safeguarding Covered Defense Information and Cyber Incident Reporting'', or any other applicable information protection requirements. The CMMC Program provides a means of verifying implementation of the security requirements set forth in 48 CFR 52.204-21, NIST SP 800-171 R2, and NIST SP 800-172 Feb2021, as applicable.

== Subpart B - Government Roles and Responsibilities. ==
=== § 170.6 CMMC PMO. ===

(a) The Office of the Department of Defense Chief Information Officer (DoD CIO) Office of the Deputy CIO for Cybersecurity (DoD CIO(CS)) provides oversight of the CMMC Program and is responsible for establishing CMMC assessment, accreditation, and training requirements as well as developing and updating CMMC Program policies and implementing guidance.

(b) The CMMC PMO is responsible for monitoring the CMMC AB’s performance of roles assigned in this rule and acting as necessary to address problems pertaining to effective performance.

(c) The CMMC PMO retains, on behalf of the DoD CIO(CS), the prerogative to review decisions of the CMMC Accreditation Body as part of its oversight of the CMMC program and evaluate any alleged conflicts of interest purported to influence the CMMC Accreditation Body’s objectivity.

(d) The CMMC PMO is responsible for sponsoring necessary DCSA activities including FOCI risk assessment and Tier 3 security background investigations for the CMMC Ecosystem members as specified in §§ 170.8(b)(4) and (5), 170.9(b)(3) through (5), 170.11(b)(3) and (4), and 170.13(b)(3) and (4).

(e) The CMMC PMO is responsible for investigating and acting upon indications that an active CMMC Status has been called into question. Indications that may trigger investigative evaluations include, but are not limited to, reports from the CMMC Accreditation Body, a C3PAO, or anyone knowledgeable of the security processes and activities of the OSA. Investigative evaluations include, but are not limited to, reviewing pertinent assessment information, and exercising the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020.

(f) If a subsequent DCMA DIBCAC assessment shows that adherence to the provisions of this rule and the required CMMC Status have not been achieved or maintained, the DIBCAC results will take precedence over any pre-existing CMMC Status recorded in SPRS, or its successor capability. The DoD will update SPRS to reflect that the OSA is out of compliance and does not meet DoD CMMC requirements. If the OSA is working on an active contract requiring CMMC compliance, then standard contractual remedies will apply.

=== § 170.7 DCMA DIBCAC. ===

(a) DCMA DIBCAC assessors in support of the CMMC Program will:

(1) Complete CMMC Level 2 and Level 3 training.

(2) Conduct Level 3 certification assessments and upload assessment results into the CMMC instantiation of eMASS, or its successor capability.

(3) Issue Certificates of CMMC Status resulting from Level 3 certification assessments.

(4) Conduct Level 2 certification assessments of the Accreditation Body and prospective C3PAOs’ information systems that process, store, and/or transmit CUI.

(5) Create and maintain a process for assessors to collect the list of assessment artifacts to include artifact names, their return value of the hashing algorithm, the hashing algorithm used, and upload that data into the CMMC instantiation of eMASS.

(6) As authorized and in accordance with all legal requirements, enter and track, OSC appeals and updated results arising from Level 3 certification assessment activities into the CMMC instantiation of eMASS.

(7) Retain all records in accordance with DCMA-MAN 4501-04.

(8) Conduct an assessment of the OSA, when requested by the CMMC PMO per §§ 170.6(e) and (f), as provided for under the 48 CFR 252.204-7019 and 48 CFR 252.204-7020.

(9) Identify assessments that meet the criteria in § 170.20 and verify that SPRS accurately reflects the CMMC Status.

(b) An OSC, the CMMC AB, or a C3PAO may appeal the outcome of its DCMA DIBCAC conducted assessment within 21 days by submitting a written basis for appeal with the requirements in question for DCMA DIBCAC consideration. Appeals may be submitted for review by visiting ''www.dcma.mil/DIBCAC'' for contact information, and a DCMA DIBCAC Quality Assurance Review Team will provide a written response or request additional supporting documentation.

== Subpart C - CMMC Assessment and Certification Ecosystem. ==
=== § 170.8 Accreditation Body. ===

(a)''Roles and responsibilities''. The Accreditation Body is responsible for authorizing and ensuring the accreditation of CMMC Third-Party Assessment Organizations (C3PAOs) in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and all applicable authorization and accreditation requirements set forth. The Accreditation Body is responsible for establishing the C3PAO authorization requirements and the C3PAO Accreditation Scheme and submitting both for approval by the CMMC PMO. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program.

(b)''Requirements''. The CMMC Accreditation Body shall:

(1) Be US-based and be and remain a member in good standing of the Inter- American Accreditation Cooperation (IAAC) and become an International Laboratory Accreditation Cooperation (ILAC) Mutual Recognition Arrangement (MRA) signatory, with a signatory status scope of ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2).

(2) Be and remain a member in good standing of the International Accreditation Forum (IAF) with mutual recognition arrangement signatory status scope of ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(3) Achieve and maintain full compliance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2) and complete a peer assessment by other ILAC signatories for competence in accrediting conformity assessment bodies to ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), both within 24 months of DoD approval.

(i) Prior to achieving full compliance as set forth in this paragraph (b)(3), the Accreditation Body shall:

(A) Authorize C3PAOs who meet all requirements set forth in § 170.9 as well as administrative requirements as determined by the Accreditation Body to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the assessment results.

(B) Require all C3PAOs to achieve and maintain the ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) requirements within 27 months of authorization.

(ii) The Accreditation Body shall accredit C3PAOs, in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), who meet all requirements set forth in § 170.9 to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the results.

(4) Ensure that the Accreditation Body’s Board of Directors, professional staff, Information Technology (IT) staff, accreditation staff, and independent CMMC Certified Assessor staff complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions'') and ]submitted by DoD CIO Security to Washington Headquarters Services (WHS) for coordination for processing by the Defense Counterintelligence and Security Agency (DCSA). These positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing the Standard Form (SF) 328 (''www.gsa.gov/reference/forms/ certificate-pertaining-to-foreign- interests''), ]''Certificate Pertaining to Foreign Interests'', and submit it directly to Defense Counterintelligence and Security Agency (DCSA) and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c). The Accreditation Body must receive a non-disqualifying eligibility determination by the CMMC PMO to be recognized by the Department of Defense.

(ii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the Accreditation Body losing its authorization or accreditation under the CMMC Program.

(iii) Identifying all prospective C3PAOs to the CMMC PMO. The CMMC PMO will sponsor the prospective C3PAO for a FOCI risk assessment conducted by the DCSA using the SF 328 as part of the authorization and accreditation processes.

(iv) Notifying prospective C3PAOs of the CMMC PMO’s eligibility determination resulting from the FOCI risk assessment.

(6) Obtain a Level 2 certification assessment in accordance with the procedures specified in § 170.17(a)(1) and (c). This assessment, conducted by DCMA DIBCAC, shall meet all requirements for a Final Level 2 (C3PAO) but will not result in a CMMC Status of Level 2 (C3PAO). The Level 2 certification assessment process must be performed every three years.

(7) Provide all documentation and records in English.

(8) Establish, maintain, and manage an up-to-date list of authorized and accredited C3PAOs on a single publicly accessible website and provide the list of these entities and their status to the DoD through submission in the CMMC instantiation of eMASS.

(9) Provide the CMMC PMO with current data on C3PAOs, including authorization and accreditation records and status in the CMMC instantiation of eMASS. This data shall include the dates associated with the authorization and accreditation of each C3PAO.

(10) Provide the DoD with information about aggregate statistics pertaining to operations of the CMMC Ecosystem to include the authorization and accreditation status of C3PAOs or other information as requested.

(11) Provide inputs for assessor supplemental guidance to the CMMC PMO. Participate and support coordination of these and other inputs through DoD-led Working Groups.

(12) Ensure that all information about individuals is encrypted and protected in all Accreditation Body information systems and databases.

(13) Provide all plans that are related to potential sources of revenue, to include but not limited to: fees, licensing, processes, membership, and/ or partnerships to the Department’s CMMC PMO.

(14) Ensure that the CMMC Assessors and Instructors Certification Organization (CAICO) is compliant with ISO/IEC 17024:2012(E)

(15) Ensure all training products, instruction, and testing materials are of high quality and subject to CAICO quality control policies and procedures, to include technical accuracy and alignment with all applicable legal, regulatory, and policy requirements.

(16) Develop and maintain an internal appeals process, as required by ISO/IEC 17020:2017(E), and render a final decision on all elevated appeals.

(17) Develop and maintain a comprehensive plan and schedule to comply with all ISO/IEC 17011:2017(E), and DoD requirements for Conflict of Interest, Code of Professional Conduct, and Ethics policies as set forth in the DoD contract. All policies shall apply to the Accreditation Body, and other individuals, entities, and groups within the CMMC Ecosystem who provide Level 2 certification assessments, CMMC instruction, CMMC training materials, or Certificates of CMMC Status on behalf of the Accreditation Body. All policies in this section must be approved by the CMMC PMO prior to effectivity in accordance with the following requirements.

(i) ''Conflict of Interest (CoI) policy.''

The CoI policy shall:

(A) Include a detailed risk mitigation plan for all potential conflicts of interest that may pose a risk to compliance with ISO/IEC 17011:2017(E).

(B) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees to disclose to the CMMC PMO, in writing, as soon as it is known or reasonably should be known, any actual, potential, or perceived conflict of interest with sufficient detail to allow for assessment.

(C) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees who leave the board or organization to enter a ‘‘cooling off period’’ of one (1) year whereby they are prohibited from working with the Accreditation Body or participating in any and all CMMC activities described in Subpart C.

(D) Require CMMC Ecosystem members to actively avoid participating in any activity, practice, or transaction that could result in an actual or perceived conflict of interest.

(E) Require CMMC Ecosystem members to disclose to Accreditation Body leadership, in writing, any actual or potential conflict of interest as soon as it is known, or reasonably should be known.

(ii) ''Code of Professional Conduct (CoPC) policy.''

The CoPC policy shall:

(A) Describe the performance standards by which the members of the CMMC Ecosystem will be held accountable and the procedures for addressing violations of those performance standards.

(B) Require the Accreditation Body to investigate and resolve any potential violations that are reported or are identified by the DoD.

(C) Require the Accreditation Body to inform the DoD in writing of new investigations within 72 hours.

(D) Require the Accreditation Body to report to the DoD in writing the outcome of completed investigations within 15 business days.

(E) Require CMMC Ecosystem members to represent themselves and their companies accurately; to include not misrepresenting any professional credentials or status, including CMMC authorization or CMMC Status, nor exaggerating the services that they or their company are capable or authorized to deliver.

(F) Require CMMC Ecosystem members to be honest and factual in all CMMC-related activities with colleagues, clients, trainees, and others with whom they interact.

(G) Prohibit CMMC Ecosystem members from participating in the Level 2 certification assessment process for an assessment in which they previously served as a consultant to prepare the organization for any CMMC assessment within 3 years.

(H) Require CMMC Ecosystem members to maintain the confidentiality of customer and government data to preclude unauthorized disclosure.

(I) Require CMMC Ecosystem members to report results and data from Level 2 certification assessments and training objectively, completely, clearly, and accurately.

(J) Prohibit CMMC Ecosystem members from cheating, assisting another in cheating, or allowing cheating on CMMC examinations.

(K) Require CMMC Ecosystem members to utilize official training content developed by a CMMC training organization approved by the CAICO in all CMMC certification courses.

(iii) ''Ethics policy.''

The Ethics policy shall:

(A) Require CMMC Ecosystem members to report to the Accreditation Body within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

(B) Prohibit harassment or discrimination by CMMC Ecosystem members in all interactions with individuals whom they encounter in connection with their roles in the CMMC Ecosystem.

(C) Require CMMC Ecosystem members to have and maintain a satisfactory record of integrity and business ethics.

=== § 170.9 CMMC Third-Party Assessment Organizations (C3PAOs). ===

(a)''Roles and responsibilities''. C3PAOs are organizations that are responsible for conducting Level 2 certification assessments and issuing Certificates of CMMC Status to OSCs based on the results. C3PAOs must be accredited or authorized by the Accreditation Body in accordance with the requirements set forth.

(b)''Requirements''. C3PAOs shall:

(1) Obtain authorization or accreditation from the Accreditation Body in accordance with § 170.8(b)(3)(i) and (ii).

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain compliance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) within 27 months of authorization.

(3) Require all C3PAO company personnel participating in the Level 2 certification assessment process to complete a Tier 3 background investigation resulting in a determination of national security eligibility. This includes the CMMC Assessment Team and the quality assurance individual. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/ reference/forms/questionnaire-for-national-security-positions''). These ]positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Require all C3PAO company personnel participating in the Level 2 certification assessment process who are not eligible to obtain a Tier 3 background investigation to meet the equivalent of a favorably adjudicated Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing and submitting Standard Form (SF) 328 (''www.gsa.gov/ reference/forms/certificate-pertaining-to-foreign-interests''), Certificate Pertaining to Foreign Interests'', upon request from DCSA and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c).

(ii) Receiving a non-disqualifying eligibility determination from the CMMC PMO resulting from the FOCI risk assessment in order to proceed to a DCMA DIBCAC CMMC Level 2 assessment, as part of the authorization and accreditation process set forth in paragraph (b)(6) of this section.

(iii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the C3PAO losing its authorization or accreditation.

(6) Undergo a Level 2 certification assessment meeting all requirements for a Final Level 2 (C3PAO) in accordance with the procedures specified in § 170.17(a)(1) and (c), with the following exceptions:

(i) The assessment will be conducted by DCMA DIBCAC.

(ii) The assessment will not result in a CMMC Status of Level 2 (C3PAO) nor receive a Certificate of CMMC Status.

(7) Provide all documentation and records in English.

(8) Submit pre-assessment and planning material, final assessment reports, and CMMC certificates of assessment into the CMMC instantiation of eMASS.

(9) Unless disposition is otherwise authorized by the CMMC PMO, maintain all assessment related records for a period of six (6) years. Such records include any materials generated by the C3PAO in the course of an assessment, any working papers generated from Level 2 certification assessments; and materials relating to monitoring, education, training, technical knowledge, skills, experience, and authorization of all personnel involved in assessment activities; contractual agreements with OSCs; and organizations for whom consulting services were provided.

(10) Provide any requested audit information, including any out-of-cycle from ISO/IEC 17020:2012(E) requirements, to the Accreditation Body.

(11) Ensure that all personally identifiable information (PII) is encrypted and protected in all C3PAO information systems and databases.

(12) Meet the requirements for Assessment Team composition. An Assessment Team must include at least two people: a Lead CCA, as defined in § 170.11(b)(10), and at least one other CCA. Additional CCAs and CCPs may also participate on an Assessment Team.

(13) Implement a quality assurance function that ensures the accuracy and completeness of assessment data prior to upload into the CMMC instantiation of eMASS. Any individual fulfilling the quality assurance function must be a CCA and cannot be a member of an Assessment Team for which they are performing a quality assurance role. A quality assurance individual shall manage the C3PAO’s quality assurance reviews as defined in paragraph (b)(14) of this section and the appeals process as required by paragraphs (b)(19) and (20) of this section and in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(14) Conduct quality assurance reviews for each assessment, including observations of the Assessment Team’s conduct and management of CMMC assessment processes.

(15) Ensure that all Level 2 certification assessment activities are performed on the information system within the CMMC Assessment Scope.

(16) Maintain all facilities, personnel, and equipment involved in CMMC activities that are in scope of their Level 2 certification assessment and comply with all security requirements and procedures as prescribed by the Accreditation Body.

(17) Ensure that all assessment data and information uploaded into the CMMC instantiation of eMASS assessment data is compliant with the CMMC assessment data standard as set forth in eMASS CMMC Assessment Import Templates on the CMMC eMASS website: ''https://cmmc.emass.apps.mil''. This system is accessible only to authorized users.

(18) Issue Certificates of CMMC Status to OSCs in accordance with the Level 2 certification assessment requirements set forth in § 170.17, that include, at a minimum, all industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope, the C3PAO name, assessment unique identifier, the OSC name, and the CMMC Status date and level.

(19) Address all OSC appeals arising from Level 2 certification assessment activities. If the OSC or C3PAO is not satisfied with the result of the appeal either the OSC or the C3PAO can elevate the matter to the Accreditation Body for final determination.

(20) Submit assessment appeals, review records, and decision results of assessment appeals to DoD using the CMMC instantiation of eMASS.

=== § 170.10 CMMC Assessor and Instructor Certification Organization (CAICO). ===

(a)''Roles and responsibilities''. The CAICO is responsible for training, testing, authorizing, certifying, and recertifying CMMC assessors, instructors, and related professionals. Only the CAICO may make decisions relating to examination certifications, including the granting, maintaining, recertifying, expanding, and reducing the scope of certification, and suspending or withdrawing certification in accordance with current ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2). At any given point in time, there will be only one CAICO for the DoD CMMC Program.

(b)''Requirements''. The CAICO shall: (1) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain ISO/IEC 17024(E) accreditation within 12 months of December 16, 2024.

(2) Provide all documentation and records in English.

(3) Train, test, and designate PIs in accordance with the requirements of this section. Train, test, certify, and recertify CCPs, CCAs, and CCIs in accordance with the requirements of this section.

(4) Ensure the instructor and assessor certification examinations are certified under ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2), by a recognized US-based accreditor who is not a member of the CMMC Accreditation Body. The US-based accreditor must be a signatory to International Laboratory Accreditation Cooperation (ILAC) or relevant International Accreditation Forum (IAF) Mutual Recognition Arrangement (MRA) and must operate in accordance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(5) Establish quality control policies and procedures for the generation of training products, instruction, and testing materials.

(6) Oversee development, administration, and management pertaining to the quality of training and examination materials for CMMC assessor and instructor certification and recertification.

(7) Establish and publish an authorization and certification appeals process to receive, evaluate, and make decisions on complaints and appeals in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(8) Address all appeals arising from the CCA, CCI, and CCP authorizations and certifications process through use of internal processes in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(9) Maintain records for a period of six (6) years of all procedures, processes, and actions related to fulfillment of the requirements set forth in this section and provide the Accreditation Body access to those records.

(10) Provide the Accreditation Body information about the authorization and accreditation status of assessors, instructors, training community, and publishing partners.

(11) Ensure separation of duties between individuals involved in testing activities, training activities, and certification activities.

(12) Safeguard and require any CAICO training support service providers, as applicable, to safeguard the confidentiality of applicant, candidate, and certificate-holder information and ensure the overall security of the certification process.

(13) Ensure that all PII is encrypted and protected in all CAICO information systems and databases and those of any CAICO training support service providers.

(14) Ensure the security of assessor and instructor examinations and the fair and credible administration of examinations.

(15) Neither disclose nor allow any CAICO training support service providers, as applicable, to disclose CMMC data or metrics related to authorization or certification activities to any entity other than the Accreditation Body and DoD, except as required by law.

(16) Require retraining and redesignation of PIs upon significant change to DoD’s CMMC Program requirements. Require retraining and recertification of CCPs, CCAs, and CCIs upon significant change to DoD’s CMMC Program requirements, as determined by the DoD or the CAICO.

(17) Require CMMC Ecosystem members to report to the CAICO within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

=== § 170.11 CMMC Certified Assessor (CCA). ===

(a)''Roles and responsibilities''. CCAs, in support of a C3PAO, conduct Level 2 certification assessments of OSCs in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2), the assessment processes defined in § 170.17, and the scoping requirements defined in § 170.19(c). CCAs must meet all of the requirements set forth in paragraph (b) of this section. A CCA may conduct Level 2 certification assessments and participate on a C3PAO Assessment Team.

(b)''Requirements''. CCAs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/ questionnaire-for-national-security- positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible for a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Be a CCP who has at least 3 years of cybersecurity experience, at least 1 year of assessment or audit experience, and at least one foundational qualification, aligned to at least the Intermediate Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program'' (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at ''https://public.cyber.mil/dcwf-work-role/security-control-assessor/''.

(7) Only use IT, cloud, cybersecurity services, and end-point devices provided by the authorized/accredited C3PAO that has been engaged to perform that OSA’s Level 2 certification assessment and which has undergone a Level 2 certification assessment by DCMA DIBCAC (or higher) for all assessment activities. Individual assessors are prohibited from using any other IT, including IT that is personally owned, to include internal and external cloud services and end-point devices, to process, store, or transmit CMMC assessment reports or any other CMMC assessment-related information. The evaluation of assessment evidence within the OSC environment, using OSC tools, is permitted.

(8) Immediately notify the responsible C3PAO of any breach or potential breach of security to any CMMC-related assessment materials under the assessors’ purview.

(9) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

(10) Qualify as a Lead CCA by having at least 5 years of cybersecurity experience, 5 years of management experience, 3 years of assessment or audit experience, and at least one foundational qualification aligned to Advanced Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at '' https://public.cyber.mil/dcwf-work-role/security-control-assessor/.''

=== § 170.12 CMMC Instructor. ===

(a) ''CMMC Provisional Instructor (PI) roles and responsibilities''. A CMMC Provisional Instructor (PI) teaches CCA and CCP candidates during the transitional period that ends 18 months after December 16, 2024. A PI is trained, tested, and designated to perform CMMC instructional duties by the CAICO to teach CCP and CCA candidates. PIs are designated by the CAICO after successful completion of the PI training and testing requirements set forth by the CAICO. A PI with a valid CCP certification may instruct CCP candidates, while a PI with a valid CCA certification may instruct CCP and CCA candidates. PIs are required to meet requirements in (c) of this section.

(b) ''CMMC Certified Instructor (CCI) roles and responsibilities''. A CMMC Certified Instructor (CCI) teaches CCP, CCA, and CCI candidates and performs CMMC instructional duties. Candidate CCIs are certified by the CAICO after successful completion of the CCI training and testing requirements. A CCI is required to obtain and maintain assessor and instructor certifications from the CAICO in accordance with the requirements set forth in § 170.10 and in paragraph (c) of this section. A CCI with a valid CCP certification may instruct CCP candidates, while a CCI with a valid CCA certification may instruct CCP, CCA, and CCI candidates. Certifications are valid for 3 years from the date of issuance. CCIs are required to meet requirements in paragraph (c) of this section.

(c)''Requirements''. CMMC Instructors shall:

(1) Obtain and maintain instructor designation or certification, as appropriate, from the CAICO in accordance with the requirements set forth in § 170.10.

(2) Obtain and maintain CCP or CCA certification to deliver CCP training.

(3) Obtain and maintain a CCA certification to deliver CCA training.

(4) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(5) Provide all documentation and records in English.

(6) Provide the Accreditation Body and the CAICO annually with accurate information detailing their qualifications, training experience, professional affiliations, and certifications, and, upon reasonable request, submit documentation verifying this information.

(7) Not provide CMMC consulting services while serving as a CMMC instructor; however, subject to the Code of Professional Conduct and Conflict of Interest policies, can serve on an assessment team.

(8) Not participate in the development of exam objectives and/or exam content or act as an exam proctor while at the same time serving as a CCI.

(9) Keep confidential all information obtained or created during the performance of CMMC training activities, including trainee records, except as required by law.

(10) Not disclose any CMMC-related data or metrics that is PII, FCI, or CUI to anyone without prior coordination with and approval from DoD.

(11) Notify the Accreditation Body or the CAICO if required by law or authorized by contractual commitments to release confidential information.

(12) Not share with anyone any CMMC training-related information not previously publicly disclosed.

=== § 170.13 CMMC Certified Professional (CCP). ===

(a)''Roles and responsibilities''. A CMMC Certified Professional (CCP) completes rigorous training on CMMC and the assessment process to provide advice, consulting, and recommendations to their OSA clients. Candidate CCPs are certified by the CAICO after successful completion of the CCP training and testing requirements set forth in paragraph (b) of this section. CCPs are eligible to become CMMC Certified Assessors and can participate as a CCP on Level 2 certification assessments with CCA oversight where the CCA makes all final determinations.

(b)''Requirements''. CCPs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics as set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible to obtain a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

== Subpart D - Key Elements of the CMMC Program ==
=== § 170.14 CMMC Model. ===

(a)''Overview''. The CMMC Model incorporates the security requirements from:

(1) 48 CFR 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems;''

(2) NIST SP 800-171 R2'', Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' (incorporated by reference, see § 170.2); and

(3) Selected security requirements from NIST SP 800-172 Feb2021, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'' (incorporated by reference, see § 170.2).

(b) ''CMMC domains''. The CMMC Model consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

(c) ''CMMC level requirements''. CMMC Levels 1-3 utilize the safeguarding requirements and security requirements specified in 48 CFR 52.204-21 (for Level 1), NIST SP 800-171 R2 (incorporated by reference, see § 170.2) (for Level 2), and selected security requirements from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2) (for Level 3). This paragraph discusses the numbering scheme and the security requirements for each level.

(1)''Numbering''. Each security requirement has an identification number in the format - DD.L#-REQ - where:

(i) DD is the two-letter domain abbreviation;

(ii) L# is the CMMC level number; and

(iii) REQ is the 48 CFR 52.204-21 paragraph number, NIST SP 800-171 R2 requirement number, or NIST SP 800- 172 Feb2021 requirement number.

(2) ''CMMC Level 1 security requirements''. The security requirements in CMMC Level 1 are those set forth in 48 CFR 52.204-21(b)(1)(i) through (xv).

(3) ''CMMC Level 2 security requirements''. The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.

(4) ''CMMC Level 3 security requirements''. The security requirements in CMMC Level 3 are selected from NIST SP 800-172 Feb2021, and where applicable, Organization-Defined Parameters (ODPs) are assigned. Table 1 to this paragraph identifies the selected requirements and applicable ODPs that represent the CMMC Level 3 security requirements. ODPs for the NIST SP 800-172 Feb2021 requirements are italicized, where applicable:

==== Table 1 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 1 TO § 170.14(c)(4)
|-
! style="width: 25%;text-align:center" | Security requirement No.*
! style="width: 75%;text-align:center" | CMMC Level 3 security requirements (selected NIST SP 800-172 Feb2021 security requirement with DoD ODPs italicized)
|-
|(i) AC.L3-3.1.2e
|Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
|-
|(ii) AC.L3-3.1.3e
|Employ ''secure information transfer solutions'' to control information flows between security domains on con-nected systems.
|-
|(iii) AT.L3-3.2.1e
|Provide awareness training ''upon initial hire, following a significant cyber event, and at least annually'', focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training ''at least annually'' or when there are significant changes to the threat.
|-
|(iv) AT.L3-3.2.2e
|Include practical exercises in awareness training for ''all users, tailored by roles, to include general users, users with specialized roles, and privileged users'', that are aligned with current threat scenarios and provide feed-back to individuals involved in the training and their supervisors.
|-
|(v) CM.L3-3.4.1e
|Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
|-
|(vi) CM.L3-3.4.2e
|Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, ''remove the components or place the components in a quarantine or remediation network'' to facilitate patching, re-configuration, or other mitigations.
|-
|(vii) CM.L3-3.4.3e
|Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|-
|(viii) IA.L3-3.5.1e
|Identify and authenticate ''systems and system components, where possible'', before establishing a network con-nection using bidirectional authentication that is cryptographically based and replay resistant.
|-
|(ix) IA.L3-3.5.3e
|Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|-
|(x) IR.L3-3.6.1e
|Establish and maintain a security operations center capability that operates ''24/7, with allowance for remote/on-call staff''.
|-
|(xi) IR.L3-3.6.2e
|Establish and maintain a cyber-incident response team that can be deployed by the organization within ''24 hours''.
|-
|(xii) PS.L3-3.9.2e
|Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.
|-
|(xiii) RA.L3-3.11.1e
|Employ ''threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources'', as part of a risk assessment to guide and inform the development of organizational systems, security architec-tures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
|-
|(xiv) RA.L3-3.11.2e
|Conduct cyber threat hunting activities ''on an on-going aperiodic basis or when indications warrant'', to search for indicators of compromise in'' organizational systems'' and detect, track, and disrupt threats that evade exist-ing controls.
|-
|(xv) RA.L3-3.11.3e
|Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|(xvi) RA.L3-3.11.4e
|Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
|-
|(xvii) RA.L3-3.11.5e
|Assess the effectiveness of security solutions ''at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident'', to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|(xviii) RA.L3-3.11.6e
|Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
|-
|(xix) RA.L3-3.11.7e
|Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan ''at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident''.
|-
|(xx) CA.L3-3.12.1e
|Conduct penetration testing ''at least annually or when significant security changes are made to the system'', leveraging automated scanning tools and ad hoc tests using subject matter experts.
|-
|(xxi) SC.L3-3.13.4e
|Employ ''physical isolation techniques or logical isolation techniques or both'' in organizational systems and system components.
|-
|(xxii) SI.L3-3.14.1e
|Verify the integrity of ''security critical and essential software'' using root of trust mechanisms or cryptographic signatures.
|-
|(xxiii) SI.L3-3.14.3e
|Ensure that ''specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems, and test equipment'' are included in the scope of the specified enhanced security requirements or are segregated in pur-pose-specific networks.
|-
|(xxiv) SI.L3-3.14.6e
|Use threat indicator information and effective mitigations obtained from'', at a minimum, open or commercial sources, and any DoD-provided sources'', to guide and inform intrusion detection and threat hunting.
|-
|colspan="2"|* Roman numerals in parentheses before the Security Requirement are for numbering purposes only. The numerals are not part of the naming convention for the requirement.
|}

(d) ''Implementation''. Assessment of security requirements is prescribed by NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). Descriptive text in these documents support OSA implementation of the security requirements and use the terms organization-defined and periodically. Except where referring to Organization- Defined Parameters (ODPs), organization-defined means as determined by the OSA. Periodically means occurring at regular intervals. As used in many requirements within CMMC, the interval length is organization-defined to provided contractor flexibility, with an interval length of no more than one year.

=== § 170.15 CMMC Level 1 self-assessment and affirmation requirements. ===

(a) ''Level 1 self-assessment''. To comply with CMMC Level 1 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 1 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of Final Level 1 (Self).

(1) ''Level 1 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(2) to achieve the CMMC Status of Final Level 1 (Self). No POA&Ms are permitted for CMMC Level 1. The OSA must conduct a self-assessment in accordance with the procedures set forth in § 170.15(c)(1) and submit assessment results in SPRS. To maintain compliance with the requirements for the CMMC Status of Final Level 1 (Self), the OSA must conduct a Level 1 self- assessment on an annual basis and submit the results in SPRS, or its successor capability.

(i) ''Inputs to SPRS''. The Level 1 self-assessment results in the Supplier Performance Risk System (SPRS) shall include, at minimum, the following items:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Compliance result.

(ii) [Reserved]

(2) ''Affirmation''. Affirmation of the Level 1 (Self) CMMC Status is required for all Level 1 self-assessments. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 1 (Self), OSAs must both achieve a CMMC Status of Level 1 (Self) and have submitted an affirmation of compliance into SPRS for all information systems within the CMMC Assessment Scope.

(c) ''Procedures - (1) Level 1 self-assessment''. The OSA must conduct a Level 1 self-assessment scored in accordance with the CMMC Scoring Methodology described in § 170.24. The Level 1 self-assessment must be performed in accordance with the CMMC Level 1 scope requirements set forth in § 170.19(a) and (b) and the following:

(i) The Level 1 self-assessment must be performed using the objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) for the security requirement that maps to the CMMC Level 1 security requirement as specified in table 1 to paragraph (c)(1)(ii) of this section. In any case where an objective addresses CUI, FCI should be substituted for CUI in the objective.

(ii) Mapping table for CMMC Level 1 security requirements to the NIST SP 800-171A Jun2018 objectives.

==== Table 2 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 2 TO § 170.15(c)(1)(ii) - CMMC LEVEL 1 SECURITY REQUIREMENTS MAPPED TO NIST SP 800-171A JUN2018
|-
! style="width: 65%;text-align:left" | CMMC Level 1 security requirements as set forth in § 170.14(c)(2)
! style="width: 35%;text-align:right" | NIST SP 800-171A Jun2018
|-
|AC.L1-b.1.i
| style="text-align:right" | 3.1.1
|-
|AC.L1-b.1.ii
| style="text-align:right" | 3.1.2
|-
|AC.L1-b.1.iii
| style="text-align:right" | 3.1.20
|-
|AC.L1-b.1.iv
| style="text-align:right" | 3.1.22
|-
|IA.L1-b.1.v
| style="text-align:right" | 3.5.1
|-
|IA.L1-b.1.vi
| style="text-align:right" | 3.5.2
|-
|MP.L1-b.1.vii
| style="text-align:right" | 3.8.3
|-
|PE.L1-b.1.viii
| style="text-align:right" | 3.10.1
|-
|First phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.3
|-
|Second phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.4
|-
|Third phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.5
|-
|SC.L1-b.1.x
| style="text-align:right" | 3.13.1
|-
|SC.L1-b.1.xi
| style="text-align:right" | 3.13.5
|-
|SI.L1-b.1.xii
| style="text-align:right" | 3.14.1
|-
|SI.L1-b.1.xiii
| style="text-align:right" | 3.14.2
|-
|SI.L1-b.1.xiv
| style="text-align:right" | 3.14.4
|-
|SI.L1-b.1.xv
| style="text-align:right" | 3.14.5
|-
|colspan="2"|* Three of the 48 CFR 52.204-21 requirements were broken apart by ‘‘phrase’’ when NIST SP 800-171 R2 was developed.
|}

(iii) Additional guidance can be found in the guidance document listed in paragraph (b) of appendix A to this part.

(2) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.16 CMMC Level 2 self-assessment and affirmation requirements. ===

(a) ''Level 2 self-assessment''. To comply with Level 2 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 2 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (Self). Achieving a CMMC Status of Level 2 (Self) also satisfies the requirements for a CMMC Status of Level 1 (Self) detailed in § 170.15 for the same CMMC Assessment Scope.

(1) ''Level 2 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (Self). The OSA must conduct a self- assessment in accordance with the procedures set forth in paragraph (c)(1) of this section and submit assessment results in Supplier Performance Risk System (SPRS). To maintain compliance with the requirements for a CMMC Status of Level 2 (Self), the OSA must conduct a Level 2 self-assessment every three years and submit the results in SPRS, within three years of the CMMC Status Date associated with the Conditional Level 2 (Self).

(i) ''Inputs to SPRS''. The Level 2 self-assessment results in the SPRS shall include, at minimum, the following information:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Overall Level 2 self-assessment score (''e.g''., 105 out of 110). 
(F) POA&M usage and compliance status, if applicable.

(ii) ''Conditional Level 2 (Self)''. The OSA has achieved the CMMC Status of Conditional Level 2 (Self) if the Level 2 self-assessment results in a POA&M and the POA&M meets all the CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSA must remediate any NOT MET requirements, must perform a POA&M closeout self- assessment, and must post compliance results to SPRS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (Self). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (Self) CMMC Status for the information system will expire. If Conditional Level 2 (Self) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSA will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (Self)''. The OSA has achieved the CMMC Status of Final Level 2 (Self) if the Level 2 self- assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial self-assessment or as the result of a POA&M closeout self- assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSA will be ineligible for additional awards with CMMC Status requirement of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (Self) CMMC Status is required for all Level 2 self-assessments at the time of each assessment, and annually thereafter. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 2 (Self), the following two requirements must be met:

(1) The OSA must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (Self) or Final Level 2 (Self).

(2) The OSA must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 self-assessment of the OSA''. The OSA must conduct a Level 2 self-assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in §§ 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 self-assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the OSA must upload the results into SPRS. If a POA&M exists, a POA&M closeout self-assessment must be performed by the OSA when all NOT MET requirements have been remediated. The POA&M closeout self- assessment must be performed within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in the guidance document listed in paragraph (c) of appendix A to this part.

(2) ''Level 2 self-assessment with the use of Cloud Service Provider (CSP)''. An OSA may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the Customer Responsibility Matrix (CRM) must be documented or referred to in the OSA’s System Security Plan (SSP).

(3) ''Level 2 self-assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and CRM.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

(4) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.17 CMMC Level 2 certification assessment and affirmation requirements. ===

(a) ''Level 2 certification assessment''. To comply with Level 2 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 2 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (C3PAO). Achieving a CMMC Status of Level 2 (C3PAO) also satisfies the requirements for a CMMC Statuses of Level 1 (Self) and Level 2 (Self) set forth in §§ 170.15 and 170.16 respectively for the same CMMC Assessment Scope.

(1) ''Level 2 certification assessment requirements''. The OSC must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (C3PAO). The OSC must obtain a Level 2 certification assessment from an authorized or accredited C3PAO following the procedures outlined in paragraph (c) of this section. The C3PAO must submit the Level 2 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 2 (C3PAO), the Level 2 certification assessment must be completed within three years of the CMMC Status Date associated with the Conditional Level 2 (C3PAO).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 2 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following information:

(A) Date and level of the assessment. 
(B) C3PAO name. 
(C) Assessment unique identifier. 
(D) For each Assessor conducting the assessment, name and business contact information. 
(E) All industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope. 
(F) The name, date, and version of the SSP. 
(G) CMMC Status Date. 
(H) Assessment result for each requirement objective. 
(I) POA&M usage and compliance, as applicable. 
(J) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Conditional Level 2 (C3PAO) if the Level 2 certification assessment results in a POA&M and the POA&M meets all CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from a C3PAO, and the C3PAO must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (C3PAO). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (C3PAO) CMMC Status for the information system will expire. If Conditional Level 2 (C3PAO) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Final Level 2 (C3PAO) if the Level 2 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (C3PAO) CMMC Status is required for all Level 2 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 certification assessment of the OSC''. An authorized or accredited C3PAO must perform a Level 2 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in § 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 certification assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the C3PAO must upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 2 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) Cannot change or limit the effectiveness of other requirements that have been scored MET; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment must be performed by a C3PAO within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in § 170.21 and in the guidance document listed in paragraph (c) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. The OSC must provide the C3PAO with a list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm for upload into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 2 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 2 certification assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

=== § 170.18 CMMC Level 3 certification assessment and affirmation requirements. ===

(a) ''Level 3 certification assessment''. To comply with Level 3 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 3 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 3 (DIBCAC). A CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope is a prerequisite to undergo a Level 3 certification assessment. CMMC Level 3 recertification also has a prerequisite for a new CMMC Level 2 assessment. Achieving a CMMC Status of Level 3 (DIBCAC) also satisfies the requirements for CMMC Statuses of Level 1 (Self), Level 2 (Self), and Level 2 (C3PAO) set forth in §§ 170.15 through 170.17 respectively for the same CMMC Assessment Scope.

(1) ''Level 3 certification assessment requirements''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) on the Level 3 CMMC Assessment Scope, as defined in § 170.19(d), prior to initiating a Level 3 certification assessment, which will be performed by DCMA DIBCAC (''www.dcma.mil/DIBCAC'') on behalf of the DoD. The OSC ]must complete and achieve a MET result for all security requirements specified in table 1 to § 170.14(c)(4) to achieve the CMMC Status of Level 3 (DIBCAC). DCMA DIBCAC will submit the Level 3 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 3 (DIBCAC), the Level 3 certification assessment must be performed every three years for all information systems within the Level 3 CMMC Assessment Scope. In addition, given that compliance with Level 2 requirements is a prerequisite for applying for CMMC Level 3, a Level 2 (C3PAO) certification assessment must also be conducted every three years to maintain CMMC Level 3 (DIBCAC) status. Level 3 certification assessment must be completed within three years of the CMMC Status Date associated with the Final Level 3 (DIBCAC) or, if there was a POA&M, then within three years of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 3 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following items:

(A) Date and level of the assessment. 
(B) For each Assessor(s) conducting the assessment, name and government organization information. 
(C) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(D) The name, date, and version of the system security plan(s) (SSP). 
(E) CMMC Status Date. (F) Result for each security requirement objective. 
(G) POA&M usage and compliance, as applicable. 
(H) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Conditional Level 3 (DIBCAC) if the Level 3 certification assessment results in a POA&M and the POA&M meets all CMMC Level 3 POA&M requirements listed in § 170.21(a)(3).

(A) ''Plan of Action and Milestones''. A Level 3 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from DCMA DIBCAC, and DCMA DIBCAC must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 3 (DIBAC) CMMC Status for the information system will expire. If Conditional Level 3 (DIBCAC) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Final Level 3 (DIBCAC) if the Level 3 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 3 (DIBCAC) CMMC Status is required for all Level 3 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 3 (DIBCAC), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 3 (DIBCAC) or Final Level 3 (DIBCAC).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 3 certification assessment of the OSC''. The CMMC Level 3 certification assessment process includes:

(i) ''Final Level 2 (C3PAO)''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope prior to the CMMC Level 3 certification assessment. The CMMC Assessment Scope for the Level 3 certification assessment must be equal to, or a subset of, the CMMC Assessment Scope associated with the OSC’s Final Level 2 (C3PAO). Asset requirements differ for each CMMC Level. Scoping differences are set forth in § 170.19.

(ii) ''Initiating the Final Level 3 (DIBCAC)''. The OSC (including ESPs that voluntarily elect to undergo a Level 3 certification assessment) initiates a Level 3 certification assessment by emailing a request to DCMA DIBCAC point of contact found at ''www.dcma.mil/DIBCAC''. The request ]must include the Level 2 certification assessment unique identifier. DCMA DIBCAC will validate the OSC has achieved a CMMC Status of Level 2 (C3PAO) and will contact the OSC to schedule their Level 3 certification assessment.

(iii) ''Conducting the Final Level 3 (DIBCAC)''. DCMA DIBCAC will perform a Level 3 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2) and the CMMC Level 3 scoping requirements set forth in § 170.19(d) for the information systems within the CMMC Assessment Scope. The Level 3 certification assessment will be scored in accordance with the CMMC Scoring Methodology set forth in § 170.24 and DCMA DIBCAC will upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report. For assets that changed asset category (''i.e''., CRMA to CUI Asset) or assessment requirements (''i.e''., Specialized Assets) between the Level 2 and Level 3 certification assessments, DCMA DIBCAC will perform limited checks of Level 2 security requirements. If the OSC had these upgraded asset categories included in their Level 2 certification assessment, then DCMA DIBCAC may still perform limited checks for compliance. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 3 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) The additional evidence does not materially impact previously assessed security requirements; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment will be performed by DCMA DIBCAC within 180-days of the Conditional CMMC Status Date. Additional guidance is located in § 170.21 and in the guidance document listed in paragraph (d) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. Assessors will collect the list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used and upload that data into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 3 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The OSC may utilize a CSP product or service offering that meets the FedRAMP Moderate (or higher) baseline. If the CSP’s product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline, the product or service offering must meet security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline in accordance with DoD Policy.

(ii) Use of a CSP does not relieve an OSC of its obligation to implement the 24 Level 3 security requirements. These 24 requirements apply to every environment where the CUI data is processed, stored, or transmitted, when Level 3 (DIBCAC) is the designated CMMC Status. If any of these 24 requirements are inherited from a CSP, the OSC must demonstrate that protection during a Level 3 certification assessment via a Customer Implementation Summary/Customer Responsibility Matrix (CIS/CRM) and associated Body of Evidence (BOE). The BOE must clearly indicate whether the OSC or the CSP is responsible for meeting each requirement and which requirements are implemented by the OSC versus inherited from the CSP.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 3 certification assessment with the use of an ESP, not a CSP''. An OSC may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The use of the ESP, its relationship to the OSC, and the services provided are documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSC requirements are assessed within the scope of the OSC’s assessment against all Level 2 and Level 3 security requirements.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

=== § 170.19 CMMC scoping. ===

(a) ''Scoping requirement''. (1) The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of this section. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

(2) The requirements for defining the CMMC Assessment Scope for CMMC Levels 1, 2, and 3 are set forth in this section. Additional guidance regarding scoping can be found in the guidance documents listed in paragraphs (e) through (g) of appendix A to this part.

(b) ''CMMC Level 1 scoping''. Prior to performing a Level 1 self-assessment, the OSA must specify the CMMC Assessment Scope.

(1) ''Assets in scope for Level 1 self-assessment''. OSA information systems which process, store, or transmit FCI are in scope for CMMC Level 1 and must be self-assessed against applicable CMMC security requirements.

(2) ''Assets not in scope for Level 1 self-assessment'' - (i) ''Out-of-Scope Assets''. OSA information systems which do not process, store, or transmit FCI are outside the scope for CMMC Level 1. An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of FCI beyond the Keyboard/Video/Mouse sent to the VDI client is considered out-of-scope. There are no documentation requirements for out-of-scope assets.

(ii) ''Specialized Assets''. Specialized Assets are those assets that can process, store, or transmit FCI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment. Specialized Assets are not part of the Level 1 CMMC Assessment Scope and are not assessed against CMMC security requirements.

(3) ''Level 1 self-assessment scoping considerations''. To scope a Level 1 self-assessment, OSAs should consider the people, technology, facilities, and External Service Providers (ESP) within its environment that process, store, or transmit FCI.

(c) ''CMMC Level 2 Scoping''. Prior to performing a Level 2 self-assessment or Level 2 certification assessment, the OSA must specify the CMMC Assessment Scope.

(1) The CMMC Assessment Scope for CMMC Level 2 is based on the specification of asset categories and their respective requirements as defined in table 3 to this paragraph (c)(1). Additional information is available in the guidance document listed in paragraph (f) of appendix A to this part.

==== Table 3 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 3 TO § 170.19(c)(1) - CMMC LEVEL 2 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against all Level 2 security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSA’s CMMC As-sessment Scope.
|
* Document in the asset inventory
* Document asset treatment in SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against Level 2 security requirements that are relevant to the ca-pabilities provided.
|- style="vertical-align:top;"
| Contractor Risk Managed Assets.
|
* Assets that can, but are not intended to, process, store, or transmit CUI be-cause of security policy, procedures, and practices in place.
* Assets are not required to be physically or logically separated from CUI assets.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC secu-rity requirements, except as noted.
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies.
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost.
** The limited check(s) will be assessed against CMMC security re-quirements.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Show these assets are managed using the contractor’s risk-based security poli-cies, procedures, and practices.
* Document in the network diagram of the CMMC Assessment Scope.
|
* Review the SSP.
* Do not assess against other CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
|Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 4 to this paragraph (c)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 4 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 4 TO § 170.19(c)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum assessment type for the ESP is dictated by the OSA’s DoD contract requirement.

(d) ''CMMC Level 3 scoping''. Prior to performing a Level 3 certification assessment, the CMMC Assessment Scope must be specified.

(1) The CMMC Assessment Scope for Level 3 is based on the specification of asset categories and their respective requirements as set forth in table 5 to this paragraph (d)(1). Additional information is available in the guidance document listed in paragraph (g) of appendix A to this part.

==== Table 5 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 5 TO § 170.19(d)(1) - CMMC LEVEL 3 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Assets that can, but are not intended to, process, store, or transmit CUI (de-fined as Contractor Risk Managed As-sets in table 1 to paragraph (c)(1) of this section CMMC Scoping).
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSC’s CMMC As-sessment Scope, irrespective of wheth-er or not these assets process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements that are relevant to the capabilities provided.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
* Intermediary devices are permitted to provide the capability for the special-ized asset to meet one or more CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 6 to this paragraph (d)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 6 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 6 TO § 170.19(d)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSC, and the services provided need to be documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSC and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum. The minimum assessment type for the ESP is dictated by the OSC’s DoD contract requirement.

(e) ''Relationship between Level 2 and Level 3 CMMC Assessment Scope''. The Level 3 CMMC Assessment Scope must be equal to or a subset of the Level 2 CMMC Assessment Scope in accordance with § 170.18(a) (''e.g.'', a Level 3 data enclave with greater restrictions and protections within a Level 2 data enclave). Any Level 2 POA&M items must be closed prior to the initiation of the Level 3 certification assessment. DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated. For further information regarding scoping of CMMC Level 3 assessments please contact DCMA DIBCAC at ''www.dcma.mil/DIBCAC/''.

=== § 170.20 Standards acceptance. ===

(a) ''NIST SP 800-171 R2 DoD assessments''. In order to avoid duplication of efforts, thereby reducing the aggregate cost to industry and the Department, OSCs that have completed a DCMA DIBCAC High Assessment aligned with CMMC Level 2 Scoping will be given the CMMC Status of Final Level 2 (C3PAO) under the following conditions:

(1) ''DCMA DIBCAC High Assessment''. An OSC that achieved a perfect score with no open POA&M from a DCMA DIBCAC High Assessment conducted prior to the effective date of this rule, will be given a CMMC Status of Level 2 Final (C3PAO) with a validity period of three (3) years from the date of the original DCMA DIBCAC High Assessment. DCMA DIBCAC will identify assessments that meet these criteria and verify that SPRS accurately reflects the CMMC Status. Eligible DCMA DIBCAC High Assessments include ones conducted with Joint Surveillance in accordance with the DCMA Manual 2302-01 Surveillance. The scope of the Level 2 certification assessment is identical to the scope of the DCMA DIBCAC High Assessment. In accordance with § 170.17(a)(2), the OSC must also submit an affirmation in SPRS and annually thereafter to achieve contractual eligibility.

(2) [Reserved]. 
(b) [Reserved]. 

=== § 170.21 Plan of Action and Milestones requirements. ===

(a) ''POA&M''. For purposes of achieving a Conditional CMMC Status, an OSA is only permitted to have a POA&M for select requirements scored as NOT MET during the CMMC assessment and only under the following conditions:

(1) ''Level 1 self-assessment''. A POA&M is not permitted at any time for Level 1 self-assessments.

(2) ''Level 2 self-assessment and Level 2 certification assessment''. An OSA is only permitted to achieve the CMMC Status of Conditional Level 2 (Self) or Conditional Level 2 (C3PAO), as appropriate, if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 2 security requirements is greater than or equal to 0.8;

(ii) None of the security requirements included in the POA&M have a point value of greater than 1 as specified in the CMMC Scoring Methodology set forth in § 170.24, except SC.L2-3.13.11 CUI Encryption may be included on a POA&M if encryption is employed but it is not FIPS-validated, which would result in a point value of 3; and

(iii) None of the following security requirements are included in the POA&M:

(A) AC.L2-3.1.20 External Connections (CUI Data). 
(B) AC.L2-3.1.22 Control Public Information (CUI Data). 
(C) CA.L2-3.12.4 System Security Plan. 
(D) PE.L2-3.10.3 Escort Visitors (CUI Data). 
(E) PE.L2-3.10.4 Physical Access Logs (CUI Data). 
(F) PE.L2-3.10.5 Manage Physical Access (CUI Data). 

(3) ''Level 3 certification assessment''. An OSC is only permitted to achieve the CMMC Status of Conditional Level 3 (DIBCAC) if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 3 security requirements is greater than or equal to 0.8; and

(ii) The POA&M does not include any of following security requirements:

(A) IR.L3-3.6.1e Security Operations Center. 
(B) IR.L3-3.6.2e Cyber Incident Response Team. 
(C) RA.L3-3.11.1e Threat-Informed Risk Assessment. 
(D) RA.L3-3.11.6e Supply Chain Risk Response. 
(E) RA.L3-3.11.7e Supply Chain Risk Plan. 
(F) RA.L3-3.11.4e Security Solution Rationale. 
(G) SI.L3-3.14.3e Specialized Asset Security. 

(b) ''POA&M closeout assessment''. A POA&M closeout assessment is a CMMC assessment that assesses only the NOT MET requirements that were identified with POA&M in the initial assessment. The closing of a POA&M must be confirmed by a POA&M closeout assessment within 180-days of the Conditional CMMC Status Date. If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional CMMC Status for the information system will expire.

(1) ''Level 2 self-assessment''. For a Level 2 self-assessment, the POA&M closeout self-assessment shall be performed by the OSA in the same manner as the initial self-assessment.

(2) ''Level 2 certification assessment''. For Level 2 certification assessment, the POA&M closeout certification assessment must be performed by an authorized or accredited C3PAO.

(3) ''Level 3 certification assessment''. For Level 3 certification assessment, DCMA DIBCAC will perform the POA&M closeout certification assessment.

=== § 170.22 Affirmation. ===

(a) ''General''. The OSA must affirm continuing compliance with the appropriate level self-assessment or certification assessment. An Affirming Official from each OSA, whether a prime or subcontractor, must affirm the continuing compliance of their respective organizations with the specified security requirement after every assessment, including POA&M closeout, and annually thereafter. Affirmations are entered electronically in SPRS. The affirmation shall be submitted in accordance with the following requirements:

(1) ''Affirming Official''. The Affirming Official is the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations.

(2) ''Affirmation content''. Each CMMC affirmation shall include the following information:

(i) Name, title, and contact information for the Affirming Official; and

(ii) Affirmation statement attesting that the OSA has implemented and will maintain implementation of all applicable CMMC security requirements to their CMMC Status for all information systems within the relevant CMMC Assessment Scope.

(3) ''Affirmation submission''. The Affirming Official shall submit a CMMC affirmation in the following instances:

(i) Upon achievement of a Conditional CMMC Status, as applicable;

(ii) Upon achievement of a Final CMMC Status;

(iii) Annually following a Final CMMC Status Date; and

(iv) Following a POA&M closeout assessment, as applicable.

(b) ''Submission procedures''. All affirmations shall be completed in SPRS. The Department will verify submission of the affirmation in SPRS to ensure compliance with CMMC solicitation or contract requirements.

(1) ''Level 1 self-assessment''. At the

completion of a Level 1 self-assessment and annually thereafter, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 1 (Self).

(2) ''Level 2 self-assessment''. At the

completion of a Level 2 self-assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (Self). An affirmation shall also be submitted at the completion of a POA&M closeout self-assessment.

(3) ''Level 2 certification assessment''. At

the completion of a Level 2 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (C3PAO). An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

(4) ''Level 3 certification assessment''. At

the completion of a Level 3 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 3 (DIBCAC). Because C3PAOs and DCMA DIBCAC check for compliance with different requirements in their respective assessments, OSCs must annually affirm their CMMC Status of Level 2 (C3PAO) in addition to their CMMC Status of Level 3 (DIBCAC) to maintain eligibility for contracts requiring compliance with Level 3. An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

=== § 170.23 Application to subcontractors. ===

(a) CMMC requirements apply to prime contractors and subcontractors throughout the supply chain at all tiers that will process, store, or transmit any FCI or CUI on contractor information systems in the performance of the DoD contract or subcontract. Prime contractors shall comply and shall require subcontractors to comply with and to flow down CMMC requirements, such that compliance will be required throughout the supply chain at all tiers with the applicable CMMC level and assessment type for each subcontract as follows:

(1) If a subcontractor will only process, store, or transmit FCI (and not CUI) in performance of the subcontract, then a CMMC Status of Level 1 (Self) is required for the subcontractor.

(2) If a subcontractor will process, store, or transmit CUI in performance of the subcontract, then a CMMC Status of Level 2 (Self) is the minimum requirement for the subcontractor.

(3) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for a CMMC Status of Level 2 (C3PAO), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(4) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for the CMMC Status of Level 3 (DIBCAC), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(b) As with any solicitation or contract, the DoD may provide specific guidance pertaining to flow-down.

=== § 170.24 CMMC Scoring Methodology. ===

(a) ''General''. This scoring methodology is designed to provide a measurement of an OSA’s implementation status of the NIST SP 800-171 R2 security requirements (incorporated by reference elsewhere in this part, see § 170.2) and the selected NIST SP 800-172 Feb2021 security requirements (incorporated by reference elsewhere in this part, see § 170.2). The CMMC Scoring Methodology is designed to credit partial implementation only in limited cases (''e.g.'', multi-factor authentication IA.L2-3.5.3).

(b) ''Assessment findings''. Each security requirement assessed under the CMMC Scoring Methodology must result in one of three possible assessment findings, as follows:

(1) ''Met''. All applicable objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include but are not limited to working papers, drafts, and unofficial or unapproved policies.

(i) Enduring exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.

(ii) Temporary deficiencies that are appropriately addressed in operational plans of action (''i.e.'', include deficiency reviews and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.

(2) ''Not Met''. One or more applicable objectives for the security requirement is not satisfied. During an assessment, for each security requirement objective marked NOT MET, the assessor will document why the evidence does not conform.

(3) ''Not Applicable (N/A)''. A security requirement and/or objective does not apply at the time of the CMMC assessment. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.

(c) ''Scoring''. At each CMMC Level, security requirements are scored as follows:

(1) ''CMMC Level 1''. All CMMC Level 1 security requirements must be fully implemented to be considered MET. No POA&M is permitted for CMMC Level 1, and self-assessment results are scored as MET or NOT MET in their entirety.

(2) ''CMMC Level 2 Scoring Methodology''. The maximum score achievable for a Level 2 self-assessment or Level 2 certification assessment is equal to the total number of CMMC Level 2 security requirements. If all CMMC Level 2 security requirements are MET, OSAs are awarded the maximum score. For each requirement NOT MET, the associated value of the security requirement is subtracted from the maximum score, which may result in a negative score.

(i) ''Procedures''. (A) Scoring methodology for Level 2 self-assessment and Level 2 certification assessment is based on all CMMC Level 2 security requirement objectives, including those NOT MET.

(B) In the CMMC Level 2 Scoring Methodology, each security requirement has a value (''e.g.'', 1, 3 or 5), which is related to the designation by NIST as basic or derived security requirements. Per NIST SP 800-171 R2, the basic security requirements are obtained from FIPS PUB 200 Mar2006, which provides the high-level and fundamental security requirements for Federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in NIST SP 800-53 R5.

(''1'') For NIST SP 800-171 R2 basic and derived security requirements that, if not implemented, could lead to significant exploitation of the network, or exfiltration of CUI, five (5) points are subtracted from the maximum score. The basic and derived security requirements with a value of five (5) points include:

(''i'') ''Basic security requirements''. AC.L2-3.1.1, AC.L2-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA-L2-3.5.1, IA-L2-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L2-3.8.3, PS.L2-3.9.2, PE.L2-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L2-3.13.1, SC.L2-3.13.2, SI.L2-3.14.1, SI.L2-3.14.2, and SI.L2-3.14.3.

(''ii'') ''Derived security requirements''. AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L2-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L2-3.14.4, and SI.L2-3.14.6.

(''2'') For basic and derived security requirements that, if not implemented, have a specific and confined effect on the security of the network and its data, three (3) points are subtracted from the maximum score. The basic and derived security requirements with a value of three (3) points include:

(''i'') ''Basic security requirements''. AU.L2-3.3.2, MA.L2-3.7.1, MP.L2-3.8.1, MP.L2-3.8.2, PS.L2-3.9.1, RA.L2-3.11.1, and CA.L2-3.12.2.

(''ii'') ''Derived security requirements''. AC.L2-3.1.5, AC.L2-3.1.19, MA.L2-3.7.4, MP.L2-3.8.8, SC.L2-3.13.8, SI.L2-3.14.5, and SI.L2-3.14.7.

(''3'') All remaining derived security requirements, other than the exceptions noted, if not implemented, have a limited or indirect effect on the security of the network and its data. For these, 1 point is subtracted from the maximum score.

(''4'') Two derived security requirements, IA.L2-3.5.3 and SC.L2-3.13.11, can be partially effective even if not completely or properly implemented, and the points deducted may be adjusted depending on how the security requirement is implemented.

(''i'') Multi-factor authentication (MFA) (CMMC Level 2 security requirement IA.L2-3.5.3) is typically implemented first for remote and privileged users (since these users are both limited in number and more critical) and then for the general user, so three (3) points are subtracted from the maximum score if MFA is implemented only for remote and privileged users. Five (5) points are subtracted from the maximum score if MFA is not implemented for any users.

(''ii'') FIPS-validated encryption (CMMC Level 2 security requirement SC.L2-3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS-validated, three (3) points are subtracted from the maximum score; if encryption is not employed; five (5) points are subtracted from the maximum score.

(''5'') OSAs must have a System Security Plan (SSP) (CMMC security requirement CA.L2-3.12.4) in place at the time of assessment to describe each information system within the CMMC Assessment Scope. The absence of an up to date SSP at the time of the assessment would result in a finding that ‘''an assessment could not be completed due to incomplete information and noncompliance with 48 CFR 252.204- 7012.''’

(''6'') For each NOT MET security requirement the OSA must have a POA&M in place. A POA&M addressing NOT MET security requirements is not a substitute for a completed requirement. Security requirements not implemented, whether described in a POA&M or not, is assessed as ‘NOT MET.’

(''7'') Specialized Assets must be evaluated for their asset category per the CMMC scoping guidance for the level in question and handled accordingly as set forth in § 170.19.

(''8'') If an OSC previously received a favorable adjudication from the DoD CIO indicating that a security requirement is not applicable or that an alternative security measure is equally effective (in accordance with 48 CFR 252.204-7008 or 48 CFR 252.204-7012), the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. A security requirement for which implemented security measures have been adjudicated by the DoD CIO as equally effective is assessed as MET if there have been no changes in the environment.

(ii) ''CMMC Level 2 Scoring Table''. CMMC Level 2 scoring has been assigned based on the methodology set forth in table 1 to this paragraph (c)(2)(ii).

==== Table 7 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 7 TO § 170.24(c)(2)(ii) - CMMC LEVEL 2 SCORING TABLE
|-
! style="width: 80%;text-align:left" | CMMC Level 2 requirement categories
! style="width: 20%;text-align:right" | Point value subtracted from maximum score
|-
| colspan="2" | ''Basic Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|-
| colspan="2" | ''Derived Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not completely or properly implemented, could be partially effective and points adjusted depending on how the security requirement is implemented:
:: - Partially effective implementation - 3 points.
:: - Non-effective (not implemented at all) - 5 points.
| style="text-align:right;" | 3 or 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|- style="vertical-align:top;"
|
: If not implemented, has a limited or indirect effect on the security of the network and its data
| style="text-align:right;" | 1
|}

(3) ''CMMC Level 3 assessment scoring methodology''. CMMC Level 3 scoring does not utilize varying values like the scoring for CMMC Level 2. All CMMC Level 3 security requirements use a value of one (1) point for each security requirement. As a result, the maximum score achievable for a Level 3 certification assessment is equivalent to the total number of the selected subset of NIST SP 800-172 Feb2021 security requirements for CMMC Level 3, see § 170.14(c)(4). The maximum score is reduced by one (1) point for each security requirement NOT MET. The CMMC Level 3 scoring methodology reflects the fact that all CMMC Level 2 security requirements must already be MET (for the Level 3 CMMC Assessment Scope). A maximum score on the Level 2 certification assessment is required to be eligible to initiate a Level 3 certification assessment. The Level 3 certification assessment score is equal to the number of CMMC Level 3 security requirements that are assessed as MET.

=== Appendix A to Part 170 - Guidance ===

Guidance documents include:

(a) ‘‘CMMC Model Overview’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(b) ‘‘CMMC Assessment Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(c) ‘‘CMMC Assessment Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(d) ‘‘CMMC Assessment Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(e) ‘‘CMMC Scoping Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(f) ‘‘CMMC Scoping Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(g) ‘‘CMMC Scoping Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(h) ‘‘CMMC Hashing Guide’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

Dated: September 30, 2024.

'''Patricia L. Toppings'', '''OSD Federal Register Liaison Officer, Department of Defense''. [FR Doc. 2024-22905 Filed 10-11-24; 8:45 am]

'''BILLING CODE 6001-FR-P'''

Model Overview

2026-03-02T01:33:12Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Model Overview Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==

The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing CMMC security requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== 1. Introduction ==
The theft of intellectual property and sensitive information from all industrial sectors because of malicious cyber activity threatens economic security and national security. The Council of Economic Advisors estimates that malicious cyber activity cost the U.S. economy between $57 billion and $109 billion in 2016 [1]. The Center for Strategic and International Studies estimates that the total global cost of cybercrime was as high as $600 billion in 2017 [2]. Over a ten-year period, that burden would equate to an estimated $570 billion to $1.09 trillion dollars in costs.

Malicious cyber actors have targeted and continue to target the Defense Industrial Base (DIB) sector and the Department of Defense (DoD) supply chain. These attacks not only focus on the large prime contractors, but also target subcontractors that make up the lower tiers of the DoD supply chain. Many of these subcontractors are small entities that provide critical support and innovation. Overall, the DIB sector consists of over 220,000 companies<ref>Based on information from the Federal Procurement Data System, the average number of unique prime contractors is approximately 212,657 and the number of known unique subcontractors is approximately 8,309. (FPDS from FY18-FY21).</ref> that process, store, or transmit Controlled Unclassified Information (CUI) or Federal Contract Information (FCI) in support of the warfighter and contribute towards the research, engineering, development, acquisition, production, delivery, sustainment, and operations of DoD systems, networks, installations, capabilities, and services. The aggregate loss of intellectual property and controlled unclassified information from the DoD supply chain can undercut U.S. technical advantages and innovation, as well as significantly increase the risk to national security.

As part of multiple lines of effort focused on the security and resiliency of the DIB sector, the DoD is working with industry to enforce the safeguarding requirements of the following types of unclassified information within the supply chain:
* ''Federal Contract Information (FCI):'' is defined in 32 CFR § 170.4 and 48 CFR 4.1901 [3].
* ''Controlled Unclassified Information (CUI):'' is defined in 32 CFR § 2002.4 (h) [4].

To this end, the Office of the Under Secretary of Defense for Acquisition and Sustainment (OUSD(A&S)) and DoD Chief Information Officer (CIO) have developed the Cybersecurity Maturity Model Certification (CMMC) in concert with DoD stakeholders, University Affiliated Research Centers (UARCs), Federally Funded Research and Development Centers (FFRDCs), and the DIB sector.

This document focuses on the Cybersecurity Maturity Model Certification (CMMC) Model as set forth in section 170.14 of title 32, Code of Federal Regulations (CFR). The model incorporates the security requirements from: 1) FAR 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems'', 2) NIST SP 800-171 Rev 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'', and 3) a subset of the requirements from NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171''. The CMMC Program is designed to provide increased assurance to the DoD that defense contractors and subcontractors are compliant with information protection requirements for FCI and CUI, and are protecting such information at a level commensurate with risk from cybersecurity threats, including Advanced Persistent Threats (APTs).

When implementing the CMMC model, an organization can achieve a specific CMMC level for its entire enterprise network or for a particular enclave(s), depending on where the information to be protected is handled and stored.

=== 1.1 Document Organization ===
Section 2 presents the CMMC Model and each of its elements in detail.[[Model Overview#Appendix A|Appendix A]] provides the model as a matrix and maps the CMMC model to other secondary sources. [[Model Overview#Appendix B|Appendix B]] lists the abbreviations and acronyms. Finally, [[Model Overview#Appendix C|Appendix C]] provides the references contained in this document.

=== 1.2 Supporting Documents ===
This document is supported by multiple companion documents that provide additional information. The ''CMMC Assessment Guides'' present assessment objectives, discussion, examples, potential assessment considerations, and key references for each CMMC security requirement. The ''CMMC Scoping Guides'' provide additional guidance on how to correctly scope an assessment. The ''CMMC Hashing Guide'' provides information on how to create the hash to validate the integrity of archived assessment artifacts.

These supplemental documents are intended to provide explanatory information to assist organizations with implementing and assessing the security requirements covered by CMMC in 32 CFR § 170. The documents are not prescriptive and their use is optional. Implementation of security requirements by following any examples is not a guarantee of compliance with any CMMC security requirement or objective.

== 2. CMMC Model ==
=== 2.1 Overview ===
The CMMC Model incorporates the security requirements from: 1) FAR 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems'', 2) NIST SP 800-171 Rev 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'', and 3) a subset of the requirements from NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800—171.'' These source documents may be revised in the future, however the CMMC security requirements will remain unchanged until the CMMC final rule is published. Any further modifications to the CMMC rule will follow appropriate rulemaking procedures.

The CMMC Model consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 Rev 2.

=== 2.2 CMMC Levels ===
There are three levels within CMMC – Level 1, Level 2, and Level 3.

==== 2.2.1 Descriptions ====
The CMMC model measures the implementation of cybersecurity requirements at three levels. Each level is independent and consists of a set of CMMC security requirements as set forth in 32 CFR § 170.14 (c):
* Level 1 Requirements. The security requirements in Level 1 are those set forth in FAR clause 52.204-21(b)(1)(i) – (b)(1)(xv).
* Level 2 Requirements. The security requirements in Level 2 are identical to the requirements in NIST SP 800-171 Rev 2.
* Level 3 Requirements. The security requirements in Level 3 are derived from NIST SP 800-172 with DoD-approved parameters where applicable, as identified in 32 CFR § 170.14(c)(4). DoD defined selections and parameters for the NIST SP 800-172 requirements are italicized, where applicable.

==== 2.2.2 CMMC Overview ====
'''Figure 1. CMMC Level Overview'''

==== 2.2.3 Level 1 ====
Level 1 focuses on the protection of FCI and consists of the security requirements that correspond to the 15 basic safeguarding requirements specified in 48 CFR 52.204-21, commonly referred to as the FAR Clause.

==== 2.2.4 Level 2 ====
Level 2 focuses on the protection of CUI and incorporates the 110 security requirements specified in NIST SP 800-171 Rev 2.

==== 2.2.5 Level 3 ====
Level 3 focuses on the protection of CUI and encompasses a subset of the NIST SP 800-172 security requirements [5] with DoD-approved parameters. DoD-approved parameters are denoted with underlining in section 2.4.1 below.

=== 2.3 CMMC Domains ===
The CMMC model consists of 14 domains that align with the families specified in NIST SP 800-171 Rev 2. These domains and their abbreviations are as follows:
* Access Control (AC)
* Awareness & Training (AT)
* Audit & Accountability (AU)
* Configuration Management (CM)
* Identification & Authentication (IA)
* Incident Response (IR)
* Maintenance (MA)
* Media Protection (MP)
* Personnel Security (PS)
* Physical Protection (PE)
* Risk Assessment (RA)
* Security Assessment (CA)
* System and Communications Protection (SC)
* System and Information Integrity (SI)

=== 2.4 CMMC Security Requirements ===
==== 2.4.1. List of Security Requirements ====
This subsection itemizes the security requirements for each domain and at each level. Each requirement has a requirement identification number in the format – '''DD.L#-REQ''' – where:
* DD is the two-letter domain abbreviation;
* L# is the level number; and
* REQ is the FAR Clause 52.204-21 paragraph number, NIST SP 800-171 Rev 2, or NIST SP800-172 security requirement number.

Below the identification number, a short name identifier is provided for each requirement, meant to be used for quick reference only. Finally, each requirement has a complete requirement statement.

==== Access Control (AC) ====
{| class="wikitable" style="margin:auto"
|+ '''ACCESS CONTROL (AC)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|'''[[ Practice_AC.L2-3.1.1_Details | AC.L1-b.1.i ]]''' ''Authorized Access Control [FCI Data]''
|Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''[[ Practice_AC.L2-3.1.2_Details | AC.L1-b.1.ii ]]''' ''Transaction & Function Control [FCI Data]''
|Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''[[ Practice_AC.L2-3.1.20_Details | AC.L1-b.1.iii ]]''' ''External Connections [FCI Data]''
|Verify and control/limit connections to and use of external information systems.
|-
|'''[[ Practice_AC.L2-3.1.22_Details | AC.L1-b.1.iv ]]''' ''Control Public Information [FCI Data]''
|Control information posted or processed on publicly accessible information systems.
|-
|| '''Level 2''' || '''Description'''
|-
|'''[[ Practice_AC.L2-3.1.1_Details | AC.L2-3.1.1 ]]''' ''Authorized Access Control [CUI Data]''
|Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
|-
|'''[[ Practice_AC.L2-3.1.2_Details | AC.L2-3.1.2 ]]''' ''Transaction & Function Control [CUI Data]''
|Limit system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''[[ Practice_AC.L2-3.1.3_Details | AC.L2-3.1.3 ]]''' ''Control CUI Flow''
|Control the flow of CUI in accordance with approved authorizations.
|-
|'''[[ Practice_AC.L2-3.1.4_Details | AC.L2-3.1.4 ]]''' ''Separation of Duties''
|Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''[[ Practice_AC.L2-3.1.5_Details | AC.L2-3.1.5 ]]''' ''Least Privilege''
|Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''[[ Practice_AC.L2-3.1.6_Details | AC.L2-3.1.6 ]]''' ''Non-Privileged Account Use''
|Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''[[ Practice_AC.L2-3.1.7_Details | AC.L2-3.1.7 ]]''' ''Privileged Functions''
|Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''[[ Practice_AC.L2-3.1.8_Details | AC.L2-3.1.8 ]]''' ''Unsuccessful Logon Attempts''
|Limit unsuccessful logon attempts.
|-
|'''[[ Practice_AC.L2-3.1.9_Details | AC.L2-3.1.9 ]]''' ''Privacy & Security Notices''
|Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''[[ Practice_AC.L2-3.1.10_Details | AC.L2-3.1.10 ]]''' ''Session Lock''
|Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''[[ Practice_AC.L2-3.1.11_Details | AC.L2-3.1.11 ]]''' ''Session Termination''
|Terminate (automatically) a user session after a defined condition.
|-
|'''[[ Practice_AC.L2-3.1.12_Details | AC.L2-3.1.12 ]]''' ''Control Remote Access''
|Monitor and control remote access sessions.
|-
|'''[[ Practice_AC.L2-3.1.13_Details | AC.L2-3.1.13 ]]''' ''Remote Access Confidentiality''
|Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''[[ Practice_AC.L2-3.1.14_Details | AC.L2-3.1.14 ]]''' ''Remote Access Routing''
|Route remote access via managed access control points.
|-
|'''[[ Practice_AC.L2-3.1.15_Details | AC.L2-3.1.15 ]]''' ''Privileged Remote Access''
|Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''[[ Practice_AC.L2-3.1.16_Details | AC.L2-3.1.16 ]]''' ''Wireless Access Authorization''
|Authorize wireless access prior to allowing such connections.
|-
|'''[[ Practice_AC.L2-3.1.17_Details | AC.L2-3.1.17 ]]''' ''Wireless Access Protection''
|Protect wireless access using authentication and encryption.
|-
|'''[[ Practice_AC.L2-3.1.18_Details | AC.L2-3.1.18 ]]''' ''Mobile Device Connection''
|Control connection of mobile devices.
|-
|'''[[ Practice_AC.L2-3.1.19_Details | AC.L2-3.1.19 ]]''' ''Encrypt CUI on Mobile''
|Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''[[ Practice_AC.L2-3.1.20_Details | AC.L2-3.1.20 ]]''' ''External Connections [CUI Data]''
|Verify and control/limit connections to and use of external systems.
|-
|'''[[ Practice_AC.L2-3.1.21_Details | AC.L2-3.1.21 ]]''' ''Portable Storage Use''
|Limit use of portable storage devices on external systems.
|-
|'''[[ Practice_AC.L2-3.1.22_Details | AC.L2-3.1.22 ]]''' ''Control Public Information [CUI Data] ''
|Control CUI posted or processed on publicly accessible systems.
|-
|| '''Level 3''' || '''Description'''
|-
|'''[[ Practice_AC.L3-3.1.2e_Details | AC.L3-3.1.2e ]]''' ''Organizationally Controlled Assets''
|Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
|-
|'''[[ Practice_AC.L3-3.1.3e_Details | AC.L3-3.1.3e ]]''' ''Secured Information Transfer''
|Employ secure information transfer solutions to control information flows between security domains on connected systems.
|}

==== Awareness & Training (AT) ====
{| class="wikitable" style="margin:auto"
|+ '''AWARENESS AND TRAINING (AT)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_AT.L2-3.2.1_Details | AT.L2-3.2.1 ]]''' ''Role-Based Risk Awareness''
|Inform managers, systems administrators, and users of organizational systems of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|
'''[[ Practice_AT.L2-3.2.2_Details | AT.L2-3.2.2 ]]''' ''Role-Based Training''
|
Train personnel to carry out their assigned information security-related duties and responsibilities.
|-
|
'''[[ Practice_AT.L2-3.2.3_Details | AT.L2-3.2.3 ]]''' ''Insider Threat Awareness''
|
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|| '''Level 3 ''' || '''Description'''
|-
|
'''[[ Practice_AT.L3-3.2.1e_Details | AT.L3-3.2.1e ]]''' ''Advanced Threat Awareness''
|
Provide awareness training upon initial hire, following a significant cyber event, and at least annually, focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training at least annually or when there are significant changes to the threat.
|-
|
'''[[ Practice_AT.L3-3.2.2e_Details | AT.L3-3.2.2e ]]''' ''Practical Training Exercises''
|
Include practical exercises in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users, that are aligned with current threat scenarios and provide feedback to individuals involved in the training and their supervisors.
|}

==== Audit & Accountability (AU) ====
{| class="wikitable" style="margin:auto"
|+ '''AUDIT AND ACCOUNTABILITY (AU)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_AU.L2-3.3.1_Details | AU.L2-3.3.1 ]]''' ''System Auditing''
|
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|
'''[[ Practice_AU.L2-3.3.2_Details | AU.L2-3.3.2 ]]''' ''User Accountability''
|
Uniquely trace the actions of individual system users, so they can be held accountable for their actions.
|-
|
'''[[ Practice_AU.L2-3.3.3_Details | AU.L2-3.3.3 ]]''' ''Event Review''
|
Review and update logged events.
|-
|
'''[[ Practice_AU.L2-3.3.4_Details | AU.L2-3.3.4 ]]''' ''Audit Failure Alerting''
|
Alert in the event of an audit logging process failure.
|-
|
'''[[ Practice_AU.L2-3.3.5_Details | AU.L2-3.3.5 ]]''' ''Audit Correlation''
|
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|
'''[[ Practice_AU.L2-3.3.6_Details | AU.L2-3.3.6 ]]''' ''Reduction & Reporting''
|
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|
'''[[ Practice_AU.L2-3.3.7_Details | AU.L2-3.3.7 ]]''' ''Authoritative Time Source''
|
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|
'''[[ Practice_AU.L2-3.3.8_Details | AU.L2-3.3.8 ]]''' ''Audit Protection''
|
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|
'''[[ Practice_AU.L2-3.3.9_Details | AU.L2-3.3.9 ]]''' ''Audit Management''
|
Limit management of audit logging functionality to a subset of privileged users.
|}

==== Configuration Management (CM) ====
{| class="wikitable" style="margin:auto"
|+ '''CONFIGURATION MANAGEMENT (CM)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_CM.L2-3.4.1_Details | CM.L2-3.4.1 ]]''' ''System Baselining''
|
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|
'''[[ Practice_CM.L2-3.4.2_Details | CM.L2-3.4.2 ]]''' ''Security Configuration Enforcement''
|
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|
'''[[ Practice_CM.L2-3.4.3_Details | CM.L2-3.4.3 ]]''' ''System Change Management''
|
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|
'''[[ Practice_CM.L2-3.4.4_Details | CM.L2-3.4.4 ]]''' ''Security Impact Analysis''
|
Analyze the security impact of changes prior to implementation.
|-
|
'''[[ Practice_CM.L2-3.4.5_Details | CM.L2-3.4.5 ]]''' ''Access Restrictions for Change''
|
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|
'''[[ Practice_CM.L2-3.4.6_Details | CM.L2-3.4.6 ]]''' ''Least Functionality''
|
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|
'''[[ Practice_CM.L2-3.4.7_Details | CM.L2-3.4.7 ]]''' ''Nonessential Functionality''
|
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|
'''[[ Practice_CM.L2-3.4.8_Details | CM.L2-3.4.8 ]]''' ''Application Execution Policy''
|
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|
'''[[ Practice_CM.L2-3.4.9_Details | CM.L2-3.4.9 ]]''' ''User-Installed Software''
|
Control and monitor user-installed software.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_CM.L3-3.4.1e_Details | CM.L3-3.4.1e ]]''' ''Authoritative Repository''
|
Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
|-
|
'''[[ Practice_CM.L3-3.4.2e_Details | CM.L3-3.4.2e ]]''' ''Automated Detection & Remediation''
|
Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place the components in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.
|-
|
'''[[ Practice_CM.L3-3.4.3e_Details | CM.L3-3.4.3e ]]''' ''Automated Inventory''
|
Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|}

==== Identification & Authentication (IA) ====
{| class="wikitable" style="margin:auto"
|+ '''IDENTIFICATION AND AUTHENTICATION (IA)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_IA.L2-3.5.1_Details | IA.L1-b.1.v ]]''' ''Identification [FCI Data]''
|
Identify information system users, processes acting on behalf of users, or devices.
|-
|
'''[[ Practice_IA.L2-3.5.2_Details | IA.L1-b.1.vi ]]''' ''Authentication [FCI Data]''
|
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|| '''Level 2''' || '''Description'''
|-
|
'''[[ Practice_IA.L2-3.5.1_Details | IA.L2-3.5.1 ]]''' ''Identification [CUI Data]''
|
Identify system users, processes acting on behalf of users, and devices.
|-
|
'''[[ Practice_IA.L2-3.5.2_Details | IA.L2-3.5.2 ]]''' ''Authentication [CUI Data]''
|
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
|-
|
'''[[ Practice_IA.L2-3.5.3_Details | IA.L2-3.5.3 ]]''' ''Multifactor Authentication''
|
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|
'''[[ Practice_IA.L2-3.5.4_Details | IA.L2-3.5.4 ]]''' ''Replay-Resistant Authentication''
|
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|
'''[[ Practice_IA.L2-3.5.5_Details | IA.L2-3.5.5 ]]''' ''Identifier Reuse''
|
Prevent reuse of identifiers for a defined period.
|-
|
'''[[ Practice_IA.L2-3.5.6_Details | IA.L2-3.5.6 ]]''' ''Identifier Handling''
|
Disable identifiers after a defined period of inactivity.
|-
|
'''[[ Practice_IA.L2-3.5.7_Details | IA.L2-3.5.7 ]]''' ''Password Complexity''
|
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|
'''[[ Practice_IA.L2-3.5.8_Details | IA.L2-3.5.8 ]]''' ''Password Reuse''
|
Prohibit password reuse for a specified number of generations.
|-
|
'''[[ Practice_IA.L2-3.5.9_Details | IA.L2-3.5.9 ]]''' ''Temporary Passwords''
|
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|
'''[[ Practice_IA.L2-3.5.10_Details | IA.L2-3.5.10 ]]''' ''Cryptographically-Protected Passwords''
|
Store and transmit only cryptographically protected passwords.
|-
|
'''[[ Practice_IA.L2-3.5.11_Details | IA.L2-3.5.11 ]]''' ''Obscure Feedback''
|
Obscure feedback of authentication information.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_IA.L3-3.5.1e_Details | IA.L3-3.5.1e ]]''' ''Bidirectional Authentication''
|
Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.
|-
|
'''[[ Practice_IA.L3-3.5.3e_Details | IA.L3-3.5.3e ]]''' ''Block Untrusted Assets''
|
Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|}

==== Incident Response (IR) ====
{| class="wikitable" style="margin:auto"
|+ '''INCIDENT RESPONSE (IR)'''
|-
! style="width: 25%; text-align:left" | '''Level 2'''
! style="width: 75%; text-align:left" | '''Description'''
|-
|
'''[[ Practice_IR.L2-3.6.1_Details | IR.L2-3.6.1 ]]''' ''Incident Handling''
|
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|
'''[[ Practice_IR.L2-3.6.2_Details | IR.L2-3.6.2 ]]''' ''Incident Reporting''
|
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|
'''[[ Practice_IR.L2-3.6.3_Details | IR.L2-3.6.3 ]]''' ''Incident Response Testing''
|
Test the organizational incident response capability.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_IR.L3-3.6.1e_Details | IR.L3-3.6.1e ]]''' ''Security Operations Center''
|
Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.
|-
|
'''[[ Practice_IR.L3-3.6.2e_Details | IR.L3-3.6.2e ]]''' ''Cyber Incident Response Team''
|
Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.
|}

==== Maintenance (MA) ====
{| class="wikitable" style="margin:auto"
|+ '''MAINTENANCE (MA)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_MA.L2-3.7.1_Details | MA.L2-3.7.1 ]]''' ''Perform Maintenance''
|
Perform maintenance on organizational systems.
|-
|
'''[[ Practice_MA.L2-3.7.2_Details | MA.L2-3.7.2 ]]''' ''System Maintenance Control''
|
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|
'''[[ Practice_MA.L2-3.7.3_Details | MA.L2-3.7.3 ]]''' ''Equipment Sanitization''
|
Sanitize equipment removed for off-site maintenance of any CUI.
|-
|
'''[[ Practice_MA.L2-3.7.4_Details | MA.L2-3.7.4 ]]''' ''Media Inspection''
|
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|
'''[[ Practice_MA.L2-3.7.5_Details | MA.L2-3.7.5 ]]''' ''Nonlocal Maintenance''
|
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|
'''[[ Practice_MA.L2-3.7.6_Details | MA.L2-3.7.6 ]]''' ''Maintenance Personnel''
|
Supervise the maintenance activities of maintenance personnel without required access authorization.
|}

==== Media Protection (MP) ====
{| class="wikitable" style="margin:auto"
|+ '''MEDIA PROTECTION (MP)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_MP.L2-3.8.3_Details | MP.L1-b.1.vii ]]''' ''Media Disposal [FCI Data]''
|
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|| '''Level 2''' || '''Description'''
|-
|
'''[[ Practice_MP.L2-3.8.1_Details | MP.L2-3.8.1 ]]''' ''Media Protection''
|
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|
'''[[ Practice_MP.L2-3.8.2_Details | MP.L2-3.8.2 ]]''' ''Media Access''
|
Limit access to CUI on system media to authorized users.
|-
|
'''[[ Practice_MP.L2-3.8.3_Details | MP.L2-3.8.3 ]]''' ''Media Disposal [CUI Data]''
|
Sanitize or destroy system media containing CUI before disposal or release for reuse.
|-
|
'''[[ Practice_MP.L2-3.8.4_Details | MP.L2-3.8.4 ]]''' ''Media Markings''
|
Mark media with necessary CUI markings and distribution limitations.
|-
|
'''[[ Practice_MP.L2-3.8.5_Details | MP.L2-3.8.5 ]]''' ''Media Accountability''
|
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|
'''[[ Practice_MP.L2-3.8.6_Details | MP.L2-3.8.6 ]]''' ''Portable Storage Encryption''
|
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|
'''[[ Practice_MP.L2-3.8.7_Details | MP.L2-3.8.7 ]]''' ''Removable Media''
|
Control the use of removable media on system components.
|-
|
'''[[ Practice_MP.L2-3.8.8_Details | MP.L2-3.8.8 ]]''' ''Shared Media''
|
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|
'''[[ Practice_MP.L2-3.8.9_Details | MP.L2-3.8.9 ]]''' ''Protect Backups''
|
Protect the confidentiality of backup CUI at storage locations.
|}

==== Personnel Security (PS) ====
{| class="wikitable" style="margin:auto"
|+ '''PERSONNEL SECURITY (PS)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_PS.L2-3.9.1_Details | PS.L2-3.9.1 ]]''' ''Screen Individuals''
|
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|
'''[[ Practice_PS.L2-3.9.2_Details | PS.L2-3.9.2 ]]''' ''Personnel Actions''
|
Protect organizational systems containing CUI during and after personnel actions such as terminations and transfers.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_PS.L3-3.9.2e_Details | PS.L3-3.9.2e ]]''' ''Adverse Information''
|
Protect organizational systems when adverse information develops or is obtained about individuals with access to CUI.
|}

==== Physical Protection (PE) ====
{| class="wikitable" style="margin:auto"
|+ '''PHYSICAL PROTECTION (PE)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_PE.L2-3.10.1_Details | PE.L1-b.1.viii ]]''' ''Limit Physical Access [FCI Data]''
|
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|
'''PE.L1-b.1.ix''' 
'''[[ Practice_PE.L2-3.10.3_Details | First Phase ]]''' 
'''[[ Practice_PE.L2-3.10.4_Details | Second Phase ]]''' 
'''[[ Practice_PE.L2-3.10.5_Details | Third Phase ]]''' 
''Manage Visitors & Physical Access [FCI Data]''
|
Escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices.
|-
|| '''Level 2''' || '''Description'''
|-
|
'''[[ Practice_PE.L2-3.10.1_Details | PE.L2-3.10.1 ]]''' ''Limit Physical Access [CUI Data]''
|
Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.
|-
|
'''[[ Practice_PE.L2-3.10.2_Details | PE.L2-3.10.2 ]]''' ''Monitor Facility''
|
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|
'''[[ Practice_PE.L2-3.10.3_Details | PE.L2-3.10.3 ]]''' ''Escort Visitors [CUI Data]''
|
Escort visitors and monitor visitor activity.
|-
|
'''[[ Practice_PE.L2-3.10.4_Details | PE.L2-3.10.4 ]]''' ''Physical Access Logs [CUI Data]''
|
Maintain audit logs of physical access.
|-
|
'''[[ Practice_PE.L2-3.10.5_Details | PE.L2-3.10.5 ]]''' ''Manage Physical Access [CUI Data]''
|
Control and manage physical access devices.
|-
|
'''[[ Practice_PE.L2-3.10.6_Details | PE.L2-3.10.6 ]]''' ''Alternative Work Sites''
|
Enforce safeguarding measures for CUI at alternate work sites.
|}

==== Risk Assessment (RA) ====
{| class="wikitable" style="margin:auto"
|+ '''RISK ASSESSMENT (RA)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_RA.L2-3.11.1_Details | RA.L2-3.11.1 ]]''' ''Risk Assessments''
|
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|
'''[[ Practice_RA.L2-3.11.2_Details | RA.L2-3.11.2 ]]''' ''Vulnerability Scan''
|
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|
'''[[ Practice_RA.L2-3.11.3_Details | RA.L2-3.11.3 ]]''' ''Vulnerability Remediation''
|
Remediate vulnerabilities in accordance with risk assessments.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_RA.L3-3.11.1e_Details | RA.L3-3.11.1e ]]''' ''Threat-Informed Risk Assessment''
|
Employ threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, as part of a risk assessment to guide and inform the development of organizational systems, security architectures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
|-
|
'''[[ Practice_RA.L3-3.11.2e_Details | RA.L3-3.11.2e ]]''' ''Threat Hunting''
|
Conduct cyber threat hunting activities on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems and detect, track, and disrupt threats that evade existing controls.
|-
|
'''[[ Practice_RA.L3-3.11.3e_Details | RA.L3-3.11.3e ]]''' ''Advanced Risk Identification''
|
Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|
'''[[ Practice_RA.L3-3.11.4e_Details | RA.L3-3.11.4e ]]''' ''Security Solution Rationale''
|
Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
|-
|
'''[[ Practice_RA.L3-3.11.5e_Details | RA.L3-3.11.5e ]]''' ''Security Solution Effectiveness''
|
Assess the effectiveness of security solutions at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|
'''[[ Practice_RA.L3-3.11.6e_Details | RA.L3-3.11.6e ]]''' ''Supply Chain Risk Response''
|
Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
|-
|
'''[[ Practice_RA.L3-3.11.7e_Details | RA.L3-3.11.7e ]]''' ''Supply Chain Risk Plan''
|
Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.
|}

==== Security Assessment (CA) ====
{| class="wikitable" style="margin:auto"
|+ '''SECURITY ASSESSMENT (CA)'''
|-
! style="width: 25%;text-align:left" | '''Level 2'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_CA.L2-3.12.1_Details | CA.L2-3.12.1 ]]''' ''Security Control Assessment''
|
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|
'''[[ Practice_CA.L2-3.12.2_Details | CA.L2-3.12.2 ]]''' ''Operational Plan of Action''
|
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|
'''[[ Practice_CA.L2-3.12.3_Details | CA.L2-3.12.3 ]]''' ''Security Control Monitoring''
|
Monitor security controls on an ongoing basis to determine the continued effectiveness of the controls.
|-
|
'''[[ Practice_CA.L2-3.12.4_Details | CA.L2-3.12.4 ]]''' ''System Security Plan''
|
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_CA.L3-3.12.1e_Details | CA.L3-3.12.1e ]]''' ''Penetration Testing''
|
Conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.
|}

==== System and Communications Protection (SC) ====
{| class="wikitable" style="margin:auto"
|+ '''SYSTEM AND COMMUNICATIONS PROTECTION (SC)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_SC.L2-3.13.1_Details | SC.L1-b.1.x ]]''' ''Boundary Protection [FCI Data]''
|
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|
'''[[ Practice_SC.L2-3.13.5_Details | SC.L1-b.1.xi ]]''' ''Public-Access System Separation [FCI Data]''
|
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|| '''Level 2''' || '''Description'''
|-
|
'''[[ Practice_SC.L2-3.13.1_Details | SC.L2-3.13.1 ]]''' ''Boundary Protection [CUI Data]''
|
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|
'''[[ Practice_SC.L2-3.13.2_Details | SC.L2-3.13.2 ]]''' ''Security Engineering''
|
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|
'''[[ Practice_SC.L2-3.13.3_Details | SC.L2-3.13.3 ]]''' ''Role Separation''
|
Separate user functionality from system management functionality.
|-
|
'''[[ Practice_SC.L2-3.13.4_Details | SC.L2-3.13.4 ]]''' ''Shared Resource Control''
|
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|
'''[[ Practice_SC.L2-3.13.5_Details | SC.L2-3.13.5 ]]''' ''Public-Access System Separation [CUI Data]''
|
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|
'''[[ Practice_SC.L2-3.13.6_Details | SC.L2-3.13.6 ]]''' ''Network Communication by Exception''
|
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|
'''[[ Practice_SC.L2-3.13.7_Details | SC.L2-3.13.7 ]]''' ''Split Tunneling''
|
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|
'''[[ Practice_SC.L2-3.13.8_Details | SC.L2-3.13.8 ]]''' ''Data in Transit''
|
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|
'''[[ Practice_SC.L2-3.13.9_Details | SC.L2-3.13.9 ]]''' ''Connections Termination''
|
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|
'''[[ Practice_SC.L2-3.13.10_Details | SC.L2-3.13.10 ]]''' ''Key Management''
|
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|
'''[[ Practice_SC.L2-3.13.11_Details | SC.L2-3.13.11 ]]''' ''CUI Encryption''
|
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|
'''[[ Practice_SC.L2-3.13.12_Details | SC.L2-3.13.12 ]]''' ''Collaborative Device Control''
|
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|
'''[[ Practice_SC.L2-3.13.13_Details | SC.L2-3.13.13 ]]''' ''Mobile Code''
|
Control and monitor the use of mobile code.
|-
|
'''[[ Practice_SC.L2-3.13.14_Details | SC.L2-3.13.14 ]]''' ''Voice over Internet Protocol''
|
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|
'''[[ Practice_SC.L2-3.13.15_Details | SC.L2-3.13.15 ]]''' ''Communications Authenticity''
|
Protect the authenticity of communications sessions.
|-
|
'''[[ Practice_SC.L2-3.13.16_Details | SC.L2-3.13.16 ]]''' ''Data at Rest''
|
Protect the confidentiality of CUI at rest.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_SC.L3-3.13.4e_Details | SC.L3-3.13.4e ]]''' ''Isolation''
|
Employ physical isolation techniques or logical isolation techniques or both in organizational systems and system components.
|}

==== System and Information Integrity (SI) ====
{| class="wikitable" style="margin:auto"
|+ '''SYSTEM AND INFORMATION INTEGRITY (SI)'''
|-
! style="width: 25%;text-align:left" | '''Level 1'''
! style="width: 75%;text-align:left" | '''Description'''
|-
|
'''[[ Practice_SI.L2-3.14.1_Details | SI.L1-b.1.xii ]]''' ''Flaw Remediation [FCI Data]''
|
Identify, report, and correct information and information system flaws in a timely manner.
|-
|
'''[[ Practice_SI.L2-3.14.2_Details | SI.L1-b.1.xiii ]]''' ''Malicious Code Protection [FCI Data]''
|
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|
'''[[ Practice_SI.L2-3.14.4_Details | SI.L1-b.1.xiv ]]''' ''Update Malicious Code Protection [FCI Data]''
|
Update malicious code protection mechanisms when new releases are available.
|-
|
'''[[ Practice_SI.L2-3.14.5_Details | SI.L1-b.1.xv ]]''' ''System & File Scanning [FCI Data]''
|
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|| '''Level 2''' || '''Description'''
|-
|
'''[[ Practice_SI.L2-3.14.1_Details | SI.L2-3.14.1 ]]''' ''Flaw Remediation [CUI Data]''
|
Identify, report, and correct system flaws in a timely manner.
|-
|
'''[[ Practice_SI.L2-3.14.2_Details | SI.L2-3.14.2 ]]''' ''Malicious Code Protection [CUI Data]''
|
Provide protection from malicious code at designated locations within organizational systems.
|-
|
'''[[ Practice_SI.L2-3.14.3_Details | SI.L2-3.14.3 ]]''' ''Security Alerts & Advisories''
|
Monitor system security alerts and advisories and take action in response.
|-
|
'''[[ Practice_SI.L2-3.14.4_Details | SI.L2-3.14.4 ]]''' ''Update Malicious Code Protection [CUI Data]''
|
Update malicious code protection mechanisms when new releases are available.
|-
|
'''[[ Practice_SI.L2-3.14.5_Details | SI.L2-3.14.5 ]]''' ''System & File Scanning [CUI Data]''
|
Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|
'''[[ Practice_SI.L2-3.14.6_Details | SI.L2-3.14.6 ]]''' ''Monitor Communications for Attacks''
|
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|
'''[[ Practice_SI.L2-3.14.7_Details | SI.L2-3.14.7 ]]''' ''Identify Unauthorized Use''
|
Identify unauthorized use of organizational systems.
|-
|| '''Level 3''' || '''Description'''
|-
|
'''[[ Practice_SI.L3-3.14.1e_Details | SI.L3-3.14.1e ]]''' ''Integrity Verification''
|
Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.
|-
|
'''[[ Practice_SI.L3-3.14.3e_Details | SI.L3-3.14.3e ]]''' ''Specialized Asset Security''
|
Include specialized assets such as IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment in the scope of the specified enhanced security requirements or are segregated in purpose-specific networks.
|-
|
'''[[ Practice_SI.L3-3.14.6e_Details | SI.L3-3.14.6e ]]''' ''Threat-Guided Intrusion Detection''
|
Use threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources, and any DoD-provided sources, to guide and inform intrusion detection and threat hunting.
|}

== Appendix A. ==
CMMC Model Matrix This appendix presents the model in matrix form by domain. The three columns list the associated security requirements for each CMMC level. Each level is independent and consists of a set of CMMC security requirements:
* Level 1: the ''basic safeguarding requirements'' for FCI specified in FAR Clause 52.204-21.
* Level 2: the ''security requirements'' for CUI specified in NIST SP 800-171 Rev 2 per DFARS Clause 252.204-7012
* Level 3: selected ''enhanced'' ''security requirements'' for CUI specified in NIST SP 800-172 with DoD-approved parameters where applicable.

Each requirement is contained in a single cell. The requirement identification number is bolded at the top of each cell. The next line contains the requirement short name identifier, in ''italics'', which is meant to be used for quick reference only. Below the short name is the complete CMMC security requirement statement. Some Level 3 requirement statements contain a DoD-approved parameter, which is underlined. Finally, the bulleted list at the bottom contains the FAR Clause 52.204-21, NIST SP 800-171 Rev 2, and NIST SP 800-172 reference as appropriate.

=== Access Control (AC) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_AC.L2-3.1.1_Details|AC.L1-b.1.i]]'''
''Authorized Access Control [FCI Data]'' 
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
* FAR Clause 52.204-21 b.1.i
* NIST SP 800-171 Rev 2 3.1.1
|'''[[Practice_AC.L2-3.1.1_Details|AC.L2-3.1.1]]'''
''Authorized Access Control [CUI Data]'' 
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
* NIST SP 800-171 Rev 2 3.1.1
* FAR Clause 52.204-21 b.1.i
|'''[[Practice_AC.L3-3.1.2e_Details|AC.L3-3.1.2e]]'''
''Organizationally Controlled Assets'' 
Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
* NIST SP 800-172 3.1.2e
|-
|'''[[Practice_AC.L2-3.1.2_Details|AC.L1-b.1.ii]]'''
''Transaction & Function Control [FCI Data]'' 
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
* FAR Clause 52.204-21 b.1.ii
* NIST SP 800-171 Rev 2 3.1.2
|'''[[Practice_AC.L2-3.1.2_Details|AC.L2-3.1.2]]'''
''Transaction & Function Control [CUI Data]'' 
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
* NIST SP 800-171 Rev 2 3.1.2
* FAR Clause 52.204-21 b.1.ii
|'''[[Practice_AC.L3-3.1.3e_Details|AC.L3-3.1.3e]]'''
''Secured Information Transfer'' 
Employ secure information transfer solutions to control information flows between security domains on connected systems.
* NIST SP 800-172 3.1.3e
|-
|'''[[Practice_AC.L2-3.1.20_Details|AC.L1-b.1.iii]]'''
''External Connections [FCI Data]'' 
Verify and control/limit connections to and use of external information systems.
* FAR Clause 52.204-21 b.1.iii
* NIST SP 800-171 Rev 2 3.1.20
|'''[[Practice_AC.L2-3.1.3_Details|AC.L2-3.1.3]]'''
''Control CUI Flow [CUI Data]'' 
Control the flow of CUI in accordance with approved authorizations.
* NIST SP 800-171 Rev 2 3.1.3
|
|-
|'''[[Practice_AC.L2-3.1.22_Details|AC.L1-b.1.iv]]'''
''Control Public Information [FCI Data]'' 
Control information posted or processed on publicly accessible information systems.
* FAR Clause 52.204-21 b.1.iv
* NIST SP 800-171 Rev 2 3.1.22
|'''[[Practice_AC.L2-3.1.4_Details|AC.L2-3.1.4]]'''
''Separation of Duties'' 
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
* NIST SP 800-171 Rev 2 3.1.4
|
|-
|
|'''[[Practice_AC.L2-3.1.5_Details|AC.L2-3.1.5]]'''
''Least Privilege'' 
Employ the principle of least privilege, including for specific security functions and privileged accounts.
* NIST SP 800-171 Rev 2 3.1.5
|
|-
|
|'''[[Practice_AC.L2-3.1.6_Details|AC.L2-3.1.6]]'''
''Non-Privileged Account Use'' 
Use non-privileged accounts or roles when accessing nonsecurity functions.
* NIST SP 800-171 Rev 2 3.1.6
|
|-
|
|'''[[Practice_AC.L2-3.1.7_Details|AC.L2-3.1.7]]'''
''Privileged Functions'' 
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
* NIST SP 800-171 Rev 2 3.1.7
|
|-
|
|'''[[Practice_AC.L2-3.1.8_Details|AC.L2-3.1.8]]'''
''Unsuccessful Logon Attempts'' 
Limit unsuccessful logon attempts.
* NIST SP 800-171 Rev 2 3.1.8
|
|-
|
|'''[[Practice_AC.L2-3.1.9_Details|AC.L2-3.1.9]]'''
''Privacy & Security Notices'' 
Provide privacy and security notices consistent with applicable CUI rules.
* NIST SP 800-171 Rev 2 3.1.9
|
|-
|
|'''[[Practice_AC.L2-3.1.10_Details|AC.L2-3.1.10]]'''
''Session Lock'' 
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
* NIST SP 800-171 Rev 2 3.1.10
|
|-
|
|'''[[Practice_AC.L2-3.1.11_Details|AC.L2-3.1.11]]'''
''Session Termination'' 
Terminate (automatically) a user session after a defined condition.
* NIST SP 800-171 Rev 2 3.1.11
|
|-
|
|'''[[Practice_AC.L2-3.1.12_Details|AC.L2-3.1.12]]'''
''Control Remote Access'' 
Monitor and control remote access sessions.
* NIST SP 800-171 Rev 2 3.1.12
|
|-
|
|'''[[Practice_AC.L2-3.1.13_Details|AC.L2-3.1.13]]'''
''Remote Access Confidentiality'' 
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
* NIST SP 800-171 Rev 2 3.1.13
|
|-
|
|'''[[Practice_AC.L2-3.1.14_Details|AC.L2-3.1.14]]'''
''Remote Access Routing'' 
Route remote access via managed access
control points.
* NIST SP 800-171 Rev 2 3.1.14
|
|-
|
|'''[[Practice_AC.L2-3.1.15_Details|AC.L2-3.1.15]]'''
''Privileged Remote Access'' 
Authorize remote execution of privileged commands and remote access to security-relevant information.
* NIST SP 800-171 Rev 2 3.1.15
|
|-
|
|'''[[Practice_AC.L2-3.1.16_Details|AC.L2-3.1.16]]'''
''Wireless Access Authorization'' 
Authorize wireless access prior to allowing
such connections.
* NIST SP 800-171 Rev 2 3.1.16
|
|-
|
|'''[[Practice_AC.L2-3.1.17_Details|AC.L2-3.1.17]]'''
''Wireless Access Protection'' 
Protect wireless access using authentication and encryption.
* NIST SP 800-171 Rev 2 3.1.17
|
|-
|
|'''[[Practice_AC.L2-3.1.18_Details|AC.L2-3.1.18]]'''
''Mobile Device Connection'' 
Control connection of mobile devices.
* NIST SP 800-171 Rev 2 3.1.18
|
|-
|
|'''[[Practice_AC.L2-3.1.19_Details|AC.L2-3.1.19]]'''
''Encrypt CUI on Mobile'' 
Encrypt CUI on mobile devices and mobile computing platforms.
* NIST SP 800-171 Rev 2 3.1.19
|
|-
|
|'''[[Practice_AC.L2-3.1.20_Details|AC.L2-3.1.20]]'''
''External Connections'' 
Verify and control/limit connections to and use of external information systems.
* NIST SP 800-171 Rev 2 3.1.20
* FAR Clause 52.204-21 b.1.iii
|
|-
|
|'''[[Practice_AC.L2-3.1.21_Details|AC.L2-3.1.21]]'''
''Portable Storage Use'' 
Limit use of portable storage devices on external systems.
* NIST SP 800-171 Rev 2 3.1.21
|
|-
|
|'''[[Practice_AC.L2-3.1.22_Details|AC.L2-3.1.22]]'''
''Control Public Information'' 
Control information posted or processed on publicly accessible information systems.
* NIST SP 800-171 Rev 2 3.1.22
* FAR Clause 52.204-21 b.1.iv
|
|}

=== Awareness and Training (AT) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_AT.L2-3.2.1_Details|AT.L2-3.2.1]]'''
''Role-Based Risk Awareness'' 
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
* NIST SP 800-171 Rev 2 3.2.1
|'''[[Practice_AT.L3-3.2.1e_Details|AT.L3-3.2.1e]]'''
''Advanced Threat Awareness'' 
Provide awareness training upon initial hire, following a significant cyber event, and at least annually, focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training at least annually or when there are significant changes to the threat.
* NIST SP 800-172 3.2.1e
|-
|
|'''[[Practice_AT.L2-3.2.2_Details|AT.L2-3.2.2]]'''
''Role-Based Training'' 
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
* NIST SP 800-171 Rev 2 3.2.2
|'''[[Practice_AT.L3-3.2.2e_Details|AT.L3-3.2.2e]]'''
''Practical Training Exercises'' 
Include practical exercises in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users, that are aligned with current threat scenarios and provide feedback to individuals involved in the training and their supervisors.
* NIST SP 800-172 3.2.2e
|-
|
|'''[[Practice_AT.L2-3.2.3_Details|AT.L2-3.2.3]]'''
''Insider Threat Awareness'' 
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
* NIST SP 800-171 Rev 2 3.2.3
|
|}

=== Audit and Accountability (AU) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_AU.L2-3.3.1_Details|AU.L2-3.3.1]]'''
''System Auditing'' 
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
* NIST SP 800-171 Rev 2 3.3.1
|
|-
|
|'''[[Practice_AU.L2-3.3.2_Details|AU.L2-3.3.2]]'''
''User Accountability'' 
Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.
* NIST SP 800-171 Rev 2 3.3.2
|
|-
|
|'''[[Practice_AU.L2-3.3.3_Details|AU.L2-3.3.3]]'''
''Event Review'' 
Review and update logged events.
* NIST SP 800-171 Rev 2 3.3.3
|
|-
|
|'''[[Practice_AU.L2-3.3.4_Details|AU.L2-3.3.4]]'''
''Audit Failure Alerting'' 
Alert in the event of an audit logging process failure.
* NIST SP 800-171 Rev 2 3.3.4
|
|-
|
|'''[[Practice_AU.L2-3.3.5_Details|AU.L2-3.3.5]]'''
''Audit Correlation'' 
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
* NIST SP 800-171 Rev 2 3.3.5
|
|-
|
|'''[[Practice_AU.L2-3.3.6_Details|AU.L2-3.3.6]]'''
''Reduction & Reporting'' 
Provide audit record reduction and report generation to support on-demand analysis and reporting.
* NIST SP 800-171 Rev 2 3.3.6
|
|-
|
|'''[[Practice_AU.L2-3.3.7_Details|AU.L2-3.3.7]]'''
''Authoritative Time Source'' 
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
* NIST SP 800-171 Rev 2 3.3.7
|
|-
|
|'''[[Practice_AU.L2-3.3.8_Details|AU.L2-3.3.8]]'''
''Audit Protection'' 
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
* NIST SP 800-171 Rev 2 3.3.8
|
|-
|
|'''[[Practice_AU.L2-3.3.9_Details|AU.L2-3.3.9]]'''
''Audit Management'' 
Limit management of audit logging functionality to a subset of privileged users.
* NIST SP 800-171 Rev 2 3.3.9
|
|}

=== Configuration Management (CM) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_CM.L2-3.4.1_Details|CM.L2-3.4.1]]'''
''System Baselining'' 
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
* NIST SP 800-171 Rev 2 3.4.1
|'''[[Practice_CM.L3-3.4.1e_Details|CM.L3-3.4.1e]]'''
''Authoritative Repository''
Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
* NIST SP 800-172 3.4.1e
|-
|
|'''[[Practice_CM.L2-3.4.2_Details|CM.L2-3.4.2]]'''
''Security Configuration Enforcement'' 
Establish and enforce security configuration settings for information technology products employed in organizational systems.
* NIST SP 800-171 Rev 2 3.4.2
|'''[[Practice_CM.L3-3.4.2e_Details|CM.L3-3.4.2e]]'''
Automated Detection & Remediation Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place the components in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.
* NIST SP 800-172 3.4.2e
|-
|
|'''[[Practice_CM.L2-3.4.3_Details|CM.L2-3.4.3]]'''
''System Change Management'' 
Track, review, approve or disapprove, and log changes to organizational systems.
* NIST SP 800-171 Rev 2 3.4.3
|'''[[Practice_CM.L3-3.4.3e_Details|CM.L3-3.4.3e]]'''
''Automated Inventory''
Employ automated discovery and management tools to maintain an up-to date, complete, accurate, and readily available inventory of system components.
* NIST SP 800-172 3.4.3e
|-
|
|'''[[Practice_CM.L2-3.4.4_Details|CM.L2-3.4.4]]'''
''Security Impact Analysis'' 
Analyze the security impact of changes prior to implementation.
* NIST SP 800-171 Rev 2 3.4.4
|
|-
|
|'''[[Practice_CM.L2-3.4.5_Details|CM.L2-3.4.5]]'''
''Access Restrictions for Change'' 
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
* NIST SP 800-171 Rev 2 3.4.5
|
|-
|
|'''[[Practice_CM.L2-3.4.6_Details|CM.L2-3.4.6]]'''
''Least Functionality'' 
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
* NIST SP 800-171 Rev 2 3.4.6
|
|-
|
|'''[[Practice_CM.L2-3.4.7_Details|CM.L2-3.4.7]]'''
''Nonessential Functionality'' 
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
* NIST SP 800-171 Rev 2 3.4.7
|
|-
|
|'''[[Practice_CM.L2-3.4.8_Details|CM.L2-3.4.8]]'''
''Application Execution Policy'' 
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
* NIST SP 800-171 Rev 2 3.4.8
|
|-
|
|'''[[Practice_CM.L2-3.4.9_Details|CM.L2-3.4.9]]'''
''User-Installed Software'' 
Control and monitor user-installed software.
* NIST SP 800-171 Rev 2 3.4.9
|
|}

=== Identification and Authentication (IA) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_IA.L2-3.5.1_Details|IA.L1-b.1.v]]'''
''Identification [FCI Data]'' 
Identify information system users, processes acting on behalf of users, or devices.
* FAR Clause 52.204-21 b.1.v
* NIST SP 800-171 Rev 2 3.5.1
|'''[[Practice_IA.L2-3.5.1_Details|IA.L2-3.5.1]]'''
''Identification [CUI Data]'' 
Identify information system users, processes acting on behalf of users, or devices.
* NIST SP 800-171 Rev 2 3.5.1
* FAR Clause 52.204-21 b.1.v
|'''[[Practice_IA.L3-3.5.1e_Details|IA.L3-3.5.1e]]'''
''Bidirectional Authentication'' 
Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.
* NIST SP 800-172 3.5.1e
|-
|'''[[Practice_IA.L2-3.5.2_Details|IA.L1-b.1.vi]]'''
''Authentication [FCI Data]'' 
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
* FAR Clause 52.204-21 b.1.vi
* NIST SP 800-171 Rev 2 3.5.2
|'''[[Practice_IA.L2-3.5.2_Details|IA.L2-3.5.2]]'''
''Authentication [CUI Data]'' 
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
* NIST SP 800-171 Rev 2 3.5.2
* FAR Clause 52.204-21 b.1.vi
|'''[[Practice_IA.L3-3.5.3e_Details|IA.L3-3.5.3e]]'''
''Block Untrusted Assets'' 
Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
* NIST SP 800-172 3.5.3e
|-
|
|'''[[Practice_IA.L2-3.5.3_Details|IA.L2-3.5.3]]'''
''Multifactor Authentication'' 
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
* NIST SP 800-171 Rev 2 3.5.3
|
|-
|
|'''[[Practice_IA.L2-3.5.4_Details|IA.L2-3.5.4]]'''
''Replay-Resistant Authentication'' 
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
* NIST SP 800-171 Rev 2 3.5.4
|
|-
|
|'''[[Practice_IA.L2-3.5.5_Details|IA.L2-3.5.5]]'''
''Identifier Reuse'' 
Prevent reuse of identifiers for a defined period.
* NIST SP 800-171 Rev 2 3.5.5
|
|-
|
|'''[[Practice_IA.L2-3.5.6_Details|IA.L2-3.5.6]]'''
''Identifier Handling'' 
Disable identifiers after a defined period of inactivity.
* NIST SP 800-171 Rev 2 3.5.6
|
|-
|
|'''[[Practice_IA.L2-3.5.7_Details|IA.L2-3.5.7]]'''
''Password Complexity'' 
Enforce a minimum password complexity and change of characters when new passwords are created.
* NIST SP 800-171 Rev 2 3.5.7
|
|-
|
|'''[[Practice_IA.L2-3.5.8_Details|IA.L2-3.5.8]]'''
''Password Reuse'' 
Prohibit password reuse for a specified number of generations.
* NIST SP 800-171 Rev 2 3.5.8
|
|-
|
|'''[[Practice_IA.L2-3.5.9_Details|IA.L2-3.5.9]]'''
''Temporary Passwords'' 
Allow temporary password use for system logons with an immediate change to a permanent password.
* NIST SP 800-171 Rev 2 3.5.9
|
|-
|
|'''[[Practice_IA.L2-3.5.10_Details|IA.L2-3.5.10]]'''
''Cryptographically-Protected Passwords''
Store and transmit only cryptographically protected passwords.
* NIST SP 800-171 Rev 2 3.5.10
|
|-
|
|'''[[Practice_IA.L2-3.5.11_Details|IA.L2-3.5.11]]'''
''Obscure Feedback'' 
Obscure feedback of authentication information.
* NIST SP 800-171 Rev 2 3.5.11
|
|}

=== Incident Response (IR) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_IR.L2-3.6.1_Details|IR.L2-3.6.1]]'''
''Incident Handling'' 
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
* NIST SP 800-171 Rev 2 3.6.1
|'''[[Practice_IR.L3-3.6.1e_Details|IR.L3-3.6.1e]]'''
''Security Operations Center'' 
Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.
* NIST SP 800-172 3.6.1e
|-
|
|'''[[Practice_IR.L2-3.6.2_Details|IR.L2-3.6.2]]'''
''Incident Reporting'' 
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
* NIST SP 800-171 Rev 2 3.6.2
|'''[[Practice_IR.L3-3.6.2e_Details|IR.L3-3.6.2e]]'''
''Cyber Incident Response Team'' 
Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.
* NIST SP 800-172 3.6.2e
|-
|
|'''[[Practice_IR.L2-3.6.3_Details|IR.L2-3.6.3]]'''
''Incident Response Testing'' 
Test the organizational incident response capability.
* NIST SP 800-171 Rev 2 3.6.3
|
|}

=== Maintenance (MA) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_MA.L2-3.7.1_Details|MA.L2-3.7.1]]'''
''Perform Maintenance'' 
Perform maintenance on organizational systems.
* NIST SP 800-171 Rev 2 3.7.1
|
|-
|
|'''[[Practice_MA.L2-3.7.2_Details|MA.L2-3.7.2]]'''
''System Maintenance Control'' 
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
* NIST SP 800-171 Rev 2 3.7.2
|
|-
|
|'''[[Practice_MA.L2-3.7.3_Details|MA.L2-3.7.3]]'''
''Equipment Sanitization'' 
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
* NIST SP 800-171 Rev 2 3.7.3
|
|-
|
|'''[[Practice_MA.L2-3.7.4_Details|MA.L2-3.7.4]]'''
''Media Inspection'' 
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
* NIST SP 800-171 Rev 2 3.7.4
|
|-
|
|'''[[Practice_MA.L2-3.7.5_Details|MA.L2-3.7.5]]'''
''Nonlocal Maintenance'' 
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
* NIST SP 800-171 Rev 2 3.7.5
|
|-
|
|'''[[Practice_MA.L2-3.7.6_Details|MA.L2-3.7.6]]'''
''Maintenance Personnel'' 
Supervise the maintenance activities of maintenance personnel without required access authorization.
* NIST SP 800-171 Rev 2 3.7.6
|
|}

=== Media Protection (MP) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_MP.L2-3.8.3_Details|MP.L1-b.1.vii]]'''
''Media Disposal [FCI Data]'' 
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
* FAR Clause 52.204-21 b.1.vii
* NIST SP 800-171 Rev 2 3.8.3
|'''[[Practice_MP.L2-3.8.1_Details|MP.L2-3.8.1]]'''
''Media Protection'' 
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
* NIST SP 800-171 Rev 2 3.8.1
|
|-
|
|'''[[Practice_MP.L2-3.8.2_Details|MP.L2-3.8.2]]'''
''Media Access'' 
Limit access to CUI on system media to authorized users.
* NIST SP 800-171 Rev 2 3.8.2
|
|-
|
|'''[[Practice_MP.L2-3.8.3_Details|MP.L2-3.8.3]]'''
''Media Disposal [CUI Data]'' 
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
* NIST SP 800-171 Rev 2 3.8.3
* FAR Clause 52.204-21 b.1.vii
|
|-
|
|'''[[Practice_MP.L2-3.8.4_Details|MP.L2-3.8.4]]'''
''Media Markings'' 
Mark media with necessary CUI markings and distribution limitations.
* NIST SP 800-171 Rev 2 3.8.4
|
|-
|
|'''[[Practice_MP.L2-3.8.5_Details|MP.L2-3.8.5]]'''
''Media Accountability'' 
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
* NIST SP 800-171 Rev 2 3.8.5
|
|-
|
|'''[[Practice_MP.L2-3.8.6_Details|MP.L2-3.8.6]]'''
''Portable Storage Encryption'' 
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
* NIST SP 800-171 Rev 2 3.8.6
|
|-
|
|'''[[Practice_MP.L2-3.8.7_Details|MP.L2-3.8.7]]'''
''Removable Media'' 
Control the use of removable media on system components.
* NIST SP 800-171 Rev 2 3.8.7
|
|-
|
|'''[[Practice_MP.L2-3.8.8_Details|MP.L2-3.8.8]]'''
''Shared Media'' 
Prohibit the use of portable storage devices when such devices have no identifiable owner.
* NIST SP 800-171 Rev 2 3.8.8
|
|-
|
|'''[[Practice_MP.L2-3.8.9_Details|MP.L2-3.8.9]]'''
''Protect Backups'' 
Protect the confidentiality of backup CUI at storage locations.
* NIST SP 800-171 Rev 2 3.8.9
|
|}

=== Personnel Security (PS) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_PS.L2-3.9.1_Details|PS.L2-3.9.1]]'''
''Screen Individuals'' 
Screen individuals prior to authorizing access to organizational systems containing CUI.
* NIST SP 800-171 Rev 2 3.9.1
|'''[[Practice_PS.L3-3.9.2e_Details|PS.L3-3.9.2e]]'''
''Adverse Information'' 
Protect organizational systems when adverse information develops or is obtained about individuals with access to CUI.
* NIST SP 800-172 3.9.2e
|-
|
|'''[[Practice_PS.L2-3.9.2_Details|PS.L2-3.9.2]]'''
''Personnel Actions'' 
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
* NIST SP 800-171 Rev 2 3.9.2
|
|}

=== Physical Protection (PE) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_PE.L2-3.10.1_Details|PE.L1-b.1.viii]]'''
''Limit Physical Access [FCI Data]'' 
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
* FAR Clause 52.204-21 b.1.viii
* NIST SP 800-171 Rev 2 3.10.1
|'''[[Practice_PE.L2-3.10.1_Details|PE.L2-3.10.1]]'''
''Limit Physical Access [CUI Data]'' 
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
* NIST SP 800-171 Rev 2 3.10.1
* FAR Clause 52.204-21 b.1.viii
|
|-
|'''PE.L1-b.1.ix'''
'''[[Practice_PE.L2-3.10.3_Details|First Phase]]''' 
'''[[Practice_PE.L2-3.10.4_Details|Second Phase]]''' 
'''[[Practice_PE.L2-3.10.5_Details|Third Phase]]''' 
''Manage Visitors & Physical Access [FCI Data]'' 
Escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices.
* FAR Clause 52.204-21 Partial b.1.ix
* NIST SP 800-171 Rev 2 3.10.3
* NIST SP 800-171 Rev 2 3.10.4
* NIST SP 800-171 Rev 2 3.10.5
|'''[[Practice_PE.L2-3.10.2_Details|PE.L2-3.10.2]]'''
''Monitor Facility'' 
Protect and monitor the physical facility and support infrastructure for organizational systems.
* NIST SP 800-171 Rev 2 3.10.2
|
|-
|
|'''[[Practice_PE.L2-3.10.3_Details|PE.L2-3.10.3]]'''
''Escort Visitors'' 
Escort visitors and monitor visitor activity.
* FAR Clause 52.204-21 Partial b.1.ix
* NIST SP 800-171 Rev 2 3.10.3
|
|-
|
|'''[[Practice_PE.L2-3.10.4_Details|PE.L2-3.10.4]]'''
''Physical Access Logs'' 
Maintain audit logs of physical access.
* FAR Clause 52.204-21 Partial b.1.ix
* NIST SP 800-171 Rev 2 3.10.4
|
|-
|
|'''[[Practice_PE.L2-3.10.5_Details|PE.L2-3.10.5]]'''
''Manage Physical Access'' 
Control and manage physical access devices.
* FAR Clause 52.204-21 Partial b.1.ix
* NIST SP 800-171 Rev 2 3.10.5
|
|-
|
|'''[[Practice_PE.L2-3.10.6_Details|PE.L2-3.10.6]]'''
''Alternative Work Sites'' 
Enforce safeguarding measures for CUI at alternate work sites.
* NIST SP 800-171 Rev 2 3.10.6
|
|}

=== Risk Assessment (RA) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_RA.L2-3.11.1_Details|RA.L2-3.11.1]]'''
''Risk Assessments'' 
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
* NIST SP 800-171 Rev 2 3.11.1
|'''[[Practice_RA.L3-3.11.1e_Details|RA.L3-3.11.1e]]'''
''Threat-Informed Risk Assessment'' 
Employ threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, as part of a risk assessment to guide and inform the development of organizational systems, security architectures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
* NIST SP 800-172 3.11.1e
|-
|
|'''[[Practice_RA.L2-3.11.2_Details|RA.L2-3.11.2]]'''
''Vulnerability Scan'' 
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
* NIST SP 800-171 Rev 2 3.11.2
|'''[[Practice_RA.L3-3.11.2e_Details|RA.L3-3.11.2e]]'''
''Threat Hunting'' 
Conduct cyber threat hunting activities on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems and detect, track, and disrupt threats that evade existing controls.
* NIST SP 800-172 3.11.2e
|-
|
|'''[[Practice_RA.L2-3.11.3_Details|RA.L2-3.11.3]]'''
''Vulnerability Remediation'' 
Remediate vulnerabilities in accordance with risk assessments.
* NIST SP 800-171 Rev 2 3.11.3
|'''[[Practice_RA.L3-3.11.3e_Details|RA.L3-3.11.3e]]'''
''Advanced Risk Identification'' 
Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
* NIST SP 800-172 3.11.3e
|-
|
|
|'''[[Practice_RA.L3-3.11.4e_Details|RA.L3-3.11.4e]]'''
''Security Solution Rationale'' 
Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
* NIST SP 800-172 3.11.4e
|-
|
|
|'''[[Practice_RA.L3-3.11.5e_Details|RA.L3-3.11.5e]]'''
''Security Solution Effectiveness'' 
Assess the effectiveness of security solutions at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
* NIST SP 800-172 3.11.5e
|-
|
|
|'''[[Practice_RA.L3-3.11.6e_Details|RA.L3-3.11.6e]]'''
''Supply Chain Risk Response'' 
Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
* NIST SP 800-172 3.11.6e
|-
|
|
|'''[[Practice_RA.L3-3.11.7e_Details|RA.L3-3.11.7e]]'''
''Supply Chain Risk Plan'' 
Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.
* NIST SP 800-172 3.11.7e
|}

=== Security Assessment (CA) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|
|'''[[Practice_CA.L2-3.12.1_Details|CA.L2-3.12.1]]'''
''Security Control Assessment'' 
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
* NIST SP 800-171 Rev 2 3.12.1
|'''[[Practice_CA.L3-3.12.1e_Details|CA.L3-3.12.1e]]'''
''Penetration Testing'' 
Conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.
* NIST SP 800-172 3.12.1e
|-
|
|'''[[Practice_CA.L2-3.12.2_Details|CA.L2-3.12.2]]'''
''Plan of Action'' 
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
* NIST SP 800-171 Rev 2 3.12.2
|
|-
|
|'''[[Practice_CA.L2-3.12.3_Details|CA.L2-3.12.3]]'''
''Security Control Monitoring'' 
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
* NIST SP 800-171 Rev 2 3.12.3
|
|-
|
|'''[[Practice_CA.L2-3.12.4_Details|CA.L2-3.12.4]]'''
''System Security Plan'' 
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
* NIST SP 800-171 Rev 2 3.12.4
|
|}

=== System and Communications Protection (SC) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_SC.L2-3.13.1_Details|SC.L1-b.1.x]]'''
''Boundary Protection [FCI Data]'' 
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
* FAR Clause 52.204-21 b.1.x
* NIST SP 800-171 Rev 2 3.13.1
|'''[[Practice_SC.L2-3.13.1_Details|SC.L2-3.13.1]]'''
''Boundary Protection [CUI Data]'' 
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
* NIST SP 800-171 Rev 2 3.13.1
* FAR Clause 52.204-21 b.1.x
|'''[[Practice_SC.L3-3.13.4e_Details|SC.L3-3.13.4e]]'''
''Isolation'' 
Employ physical isolation techniques or logical isolation techniques or both in organizational systems and system components.
* NIST SP 800-172 3.13.4e
|-
|'''[[Practice_SC.L2-3.13.5_Details|SC.L1-b.1.xi]]'''
''Public-Access System Separation [FCI Data]'' 
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
* FAR Clause 52.204-21 b.1.xi
* NIST SP 800-171 Rev 2 3.13.5
|'''[[Practice_SC.L2-3.13.2_Details|SC.L2-3.13.2]]'''
''Security Engineering'' 
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
* NIST SP 800-171 Rev 2 3.13.2
|
|-
|
|'''[[Practice_SC.L2-3.13.3_Details|SC.L2-3.13.3]]'''
''Role Separation'' 
Separate user functionality from system management functionality.
* NIST SP 800-171 Rev 2 3.13.3
|
|-
|
|'''[[Practice_SC.L2-3.13.4_Details|SC.L2-3.13.4]]'''
''Shared Resource Control'' 
Prevent unauthorized and unintended information transfer via shared system resources.
* NIST SP 800-171 Rev 2 3.13.4
|
|-
|
|'''[[Practice_SC.L2-3.13.5_Details|SC.L2-3.13.5]]'''
''Public-Access System Separation [CUI Data]'' 
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
* NIST SP 800-171 Rev 2 3.13.5
* FAR Clause 52.204-21 b.1.xi
|
|-
|
|'''[[Practice_SC.L2-3.13.6_Details|SC.L2-3.13.6]]'''
''Network Communication by Exception'' 
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
* NIST SP 800-171 Rev 2 3.13.6
|
|-
|
|'''[[Practice_SC.L2-3.13.7_Details|SC.L2-3.13.7]]'''
''Split Tunneling'' 
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
* NIST SP 800-171 Rev 2 3.13.7
|
|-
|
|'''[[Practice_SC.L2-3.13.8_Details|SC.L2-3.13.8]]'''
''Data in Transit'' 
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
* NIST SP 800-171 Rev 2 3.13.8
|
|-
|
|'''[[Practice_SC.L2-3.13.9_Details|SC.L2-3.13.9]]'''
''Connections Termination'' 
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
* NIST SP 800-171 Rev 2 3.13.9
|
|-
|
|'''[[Practice_SC.L2-3.13.10_Details|SC.L2-3.13.10]]'''
''Key Management'' 
Establish and manage cryptographic keys for cryptography employed in organizational systems.
* NIST SP 800-171 Rev 2 3.13.10
|
|-
|
|'''[[Practice_SC.L2-3.13.11_Details|SC.L2-3.13.11]]'''
''CUI Encryption'' 
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
* NIST SP 800-171 Rev 2 3.13.11
|
|-
|
|'''[[Practice_SC.L2-3.13.12_Details|SC.L2-3.13.12]]'''
''Collaborative Device Control'' 
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
* NIST SP 800-171 Rev 2 3.13.12
|
|-
|
|'''[[Practice_SC.L2-3.13.13_Details|SC.L2-3.13.13]]'''
''Mobile Code'' 
Control and monitor the use of mobile code.
* NIST SP 800-171 Rev 2 3.13.13
|
|-
|
|'''[[Practice_SC.L2-3.13.14_Details|SC.L2-3.13.14]]'''
''Voice over Internet Protocol'' 
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
* NIST SP 800-171 Rev 2 3.13.14
|
|-
|
|'''[[Practice_SC.L2-3.13.15_Details|SC.L2-3.13.15]]'''
''Communications Authenticity'' 
Protect the authenticity of communications sessions.
* NIST SP 800-171 Rev 2 3.13.15
|
|-
|
|'''[[Practice_SC.L2-3.13.16_Details|SC.L2-3.13.16]]'''
''Data at Rest'' 
Protect the confidentiality of CUI at rest.
* NIST SP 800-171 Rev 2 3.13.16
|
|}

=== System and Information Integrity (SI) ===
{|class="wikitable" style="margin:auto;"
! style="width: 33%"| Level 1
! style="width: 33%"| Level 2
! style="width: 33%"| Level 3
|-
|'''[[Practice_SI.L2-3.14.1_Details|SI.L1-b.1.xii]]'''
''Flaw Remediation [FCI Data]'' 
Identify, report, and correct information and information system flaws in a timely manner.
* FAR Clause 52.204-21 b.1.xii
* NIST SP 800-171 Rev 2 3.14.1
|'''[[Practice_SI.L2-3.14.1_Details|SI.L2-3.14.1]]'''
''Flaw Remediation [CUI Data]'' 
Identify, report, and correct information and information system flaws in a timely manner.
* NIST SP 800-171 Rev 2 3.14.1
* FAR Clause 52.204-21 b.1.xii
|'''[[Practice_SI.L3-3.14.1e_Details|SI.L3-3.14.1e]]'''
''Integrity Verification'' 
Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.
* NIST SP 800-172 3.14.1e
|-
|'''[[Practice_SI.L2-3.14.2_Details|SI.L1-b.1.xiii]]'''
''Malicious Code Protection [FCI Data]'' 
Provide protection from malicious code at appropriate locations within organizational information systems.
* FAR Clause 52.204-21 b.1.xiii
* NIST SP 800-171 Rev 2 3.14.2
|'''[[Practice_SI.L2-3.14.2_Details|SI.L2-3.14.2]]'''
''Malicious Code Protection [CUI Data]'' 
Provide protection from malicious code at appropriate locations within organizational information systems.
* NIST SP 800-171 Rev 2 3.14.2
* FAR Clause 52.204-21 b.1.xiii
|'''[[Practice_SI.L3-3.14.3e_Details|SI.L3-3.14.3e]]'''
''Specialized Asset Security'' 
Include specialized assets such as IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment in the scope of the specified enhanced security requirements or are segregated in purpose-specific networks.
* NIST SP 800-172 3.14.3e
|-
|'''[[Practice_SI.L2-3.14.4_Details|SI.L1-b.1.xiv]]'''
''Update Malicious Code Protection [FCI Data]'' 
Update malicious code protection mechanisms when new releases are available.
* FAR Clause 52.204-21 b.1.xiv
* NIST SP 800-171 Rev 2 3.14.4
|'''[[Practice_SI.L2-3.14.3_Details|SI.L2-3.14.3]]'''
''Security Alerts & Advisories'' 
Monitor system security alerts and advisories and take action in response.
* NIST SP 800-171 Rev 2 3.14.3
|'''[[Practice_SI.L3-3.14.6e_Details|SI.L3-3.14.6e]]'''
''Threat-Guided Intrusion Detection'' 
Use threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources, and any DoD-provided sources, to guide and inform intrusion detection and threat hunting.
* NIST SP 800-172 3.14.6e
|-
|'''[[Practice_SI.L2-3.14.5_Details|SI.L1-b.1.xv]]'''
''System & File Scanning [FCI Data]'' 
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
* FAR Clause 52.204-21 b.1.xv
* NIST SP 800-171 Rev 2 3.14.5
|'''[[Practice_SI.L2-3.14.4_Details|SI.L2-3.14.4]]'''
''Update Malicious Code Protection [CUI Data]'' 
Update malicious code protection mechanisms when new releases are available.
* NIST SP 800-171 Rev 2 3.14.4
* FAR Clause 52.204-21 b.1.xiv
|
|-
|
|'''[[Practice_SI.L2-3.14.5_Details|SI.L2-3.14.5]]'''
''System & File Scanning [CUI Data]'' 
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
* FAR Clause 52.204-21 b.1.xv
* NIST SP 800-171 Rev 2 3.14.5
|
|-
|
|'''[[Practice_SI.L2-3.14.6_Details|SI.L2-3.14.6]]'''
''Monitor Communications for Attacks'' 
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
* NIST SP 800-171 Rev 2 3.14.6
|
|-
|
|'''[[Practice_SI.L2-3.14.7_Details|SI.L2-3.14.7]]'''
''Identify Unauthorized Use'' 
Identify unauthorized use of organizational systems.
* NIST SP 800-171 Rev 2 3.14.7
|
|}

== Appendix B. Abbreviations and Acronyms ==
The following is a list of acronyms used in the CMMC model.
{| class="wikitable" style="margin:auto"
|-
|| AC || Access Control
|-
|| APT || Advanced Persistent Threat
|-
|| AT || Awareness and Training
|-
|| AU || Audit and Accountability
|-
|| CA || Security Assessment
|-
|| CFR || Code of Federal Regulations
|-
|| CM || Configuration Management
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DIB || Defense Industrial Base
|-
|| DoD || Department of Defense FAR Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| FFRDC || Federally Funded Research and Development Center
|-
|| FIPS || Federal Information Processing Standard
|-
|| IA || Identification and Authentication
|-
|| IR || Incident Response
|-
|| L# || Level Number
|-
|| MA || Maintenance
|-
|| MP || Media Protection
|-
|| N/A || Not Applicable (NA)
|-
|| NIST || National Institute of Standards and Technology
|-
|| OUSD A&S || Office of the Under Secretary of Defense for Acquisition and Sustainment
|-
|| PE || Physical Protection
|-
|| PS || Personnel Security
|-
|| PUB || Publication
|-
|| Rev || Revision
|-
|| RA || Risk Assessment
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| UARC || University Affiliated Research Center
|}

== Appendix C. References ==
# U.S. Executive Office of the President, Council of Economic Advisers (CEA), ''The Cost of Malicious Cyber Activity to the U.S. Economy'', available online at https://www.whitehouse.gov/wp-content/uploads/2018/02/The-Cost-of-Malicious-Cyber-Activity-to-the-U.S.-Economy.pdf, February 2018
# Center for Strategic and International Studies (CSIS) and McAfee, ''Economic Impact of Cybercrime - No Slowing Down'', February 2018
# 48 Code of Federal Regulations (CFR) 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems'', Federal Acquisition Regulation (FAR), 1 Oct 2016
# NIST Special Publication (SP) 800-171 Revision (Rev) 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'', U.S. Department of Commerce National Institute of Standards and Technology (NIST), December 2016 (updated June 2018)
# NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'', U.S. Department of Commerce National Institute of Standards and Technology (NIST), February 2021

== Notes ==
<references />

Main Page

2026-03-02T01:32:59Z

David:

'''This website contains information about the Cybersecurity Maturity Model Certification (CMMC) program of the U.S. Department of Defense (DoD).

The wiki aims to provide educational references for those who are interested in learning more about the framework.'''

Primary Source of Reference: The official [https://dodcio.defense.gov/CMMC/ CMMC Home Page] from the Department of Defense Chief Information Officer (DoD CIO).

Additional References: The [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Resources & Documentation] page contains a variety of links to CMMC resources throughout the DoD.

Basic information on FedRAMP and Cybersecurity Framework are also available on this website. Select one of the menu items on the Sidebar.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Site Update Notices ==
The CMMCWiki site is currently undergoing a comprehensive update to align with the latest content on the official CMMC website. For the most up-to-date information on our progress and recent changes, please refer to the following table.

{| class="wikitable" style="margin:auto"
|+ Update Status as of March 27, 2025
|-
! Page Name !! Status
|-
| Model Overview || Update completed on March 16, 2025
|-
| 32 CFR Part 170 Rule || Update completed on March 3, 2025
|-
| Level 1 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 1 Self-Assessment Guide || Update completed on March 16, 2025
|-
| Level 2 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 2 Assessment Guide || Update completed on March 20, 2025
|-
| Level 3 Scoping Guidance || Update completed on February 24, 2025
|-
| Level 3 Assessment Guide || Update completed on March 27, 2025
|-
| CMMC Hashing Guide || Update completed on March 16, 2025
|-
| CMMC Assessment Process (CAP) by CyberAB || Update completed on February 24, 2025
|-
| DoD Assessment Methodology || Update completed on March 18, 2025
|-
| 110 L1 & L2 Security Requirements || Update completed on March 16, 2025
|-
| 24 L3 Security Requirements || Update completed on March 27, 2025
|-
| FedRAMP Information || Update Pending
|-
| Cybersecurity Framework Information || Update Pending
|}

CCA Blueprint

2026-03-02T01:32:32Z

David:

'''Source of Reference: The CCA blueprint document from [https://cyberab.org/CMMC-Ecosystem/Ecosystem-roles/Assessing-and-Certification Cybersecurity Maturity Model Certification Accreditation Body, Inc.]'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Domains ==
Upon successful completion of this exam, the candidate will be able to apply skills and knowledge to the below domains:
{|class="wikitable"
|'''Domain'''
|'''Exam Weight'''
|-
|1. Evaluating Organizations Seeking Certification (OSC) against CMMC Level 2 requirement
|15%
|-
|2. CMMC Level 2 Assessment Scoping
|20%
|-
|3. CMMC Assessment Process (CAP)
|25%
|-
|4. Assessing CMMC Level 2 Practices
|40%
|}

== Domain 1: Evaluating Organizations Seeking Certification (OSC) against CMMC Level 2 requirements ==
=== Task 1. Assess the various environmental considerations of Organizations Seeking Certification (OSCs) against CMMC L2 practices. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|4C
|1.1.1
|# The difference between logical (virtual) and physical locations
|-
|4C
|1.1.2
|# The difference between professional and industrial environments
|-
|4C
|1.1.3
|# Single and multi-site environmental constraints and Evidence requirements
|-
|4C
|1.1.4
|# Cloud and hybrid environment constraints and Evidence requirements
|-
|4C
|1.1.5
|# On-premises environmental constraints
|-
|4C
|1.1.6
|# Environmental exclusions for a level 2 CMMC assessment
|}

== Domain 2: Scoping ==
=== Task 1. Analyze the CMMC Assessment Scope of Controlled Unclassified Information (CUI) Assets as they pertain to a CMMC assessment using the five categories of CUI assets as defined in the CMMC Level 2 Assessment Scoping Guide. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|4B
|2.1.1
|1. Categorization of CUI data in the form of Assets that are in scope:
|-
|4B
|2.1.1.A
|
:A. #1: Controlled Unclassified Information (CUI) Assets
|-
|4B
|2.1.1.A(1)
|
::(1) Process, store, or transmit CUI
|-
|4B
|2.1.1.B
|
:B. #2: Security Protection Assets
|-
|4B
|2.1.1.B(1)
|
::(1) Assets that provide security functions and capabilities to contractor’s CMMC Assessment Scope
|-
|4B
|2.1.1.C
|
:C. #3: Contractor Risked Managed Assets
|-
|4B
|2.1.1.C(1)
|
::(1) Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
|-
|4B
|2.1.1.D
|
:D. #4: Specialized Assets
|-
|4B
|2.1.1.D(1)
|
::(1) Assets that may/may not process, store, or transmit CUI
|-
|4B
|2.1.1.D(2)
|
::(2) Assets include government property, Internet of Things (IoT) devices, Operational Technology (OT), Restricted Information Systems, and Test Equipment
|-
|4B
|2.1.1.E
|
:E. #5: Out-of-Scope Assets
|-
|4B
|2.1.1.E(1)
|
::(1) Assets that cannot process, store, or transmit CUI
|}

=== Task 2. Given a scenario, analyze the CMMC Assessment Scope based on the predetermined CUI categories within the CMMC Level 2 Assessment Scoping Guide. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|4B
|2.2.1
|1. CMMC assessment asset categories (In-scope)
|-
|4B
|2.2.1.A
|
:A. CUI Assets
|-
|4B
|2.2.1.B
|
:B. Security Protection Assets
|-
|4B
|2.2.1.C
|
:C. Contractor Risked Managed Assets
|-
|4B
|2.2.1.D
|
:D. Specialized Assets
|-
|4B
|2.2.2
|2. CMMC assessment asset categories (Out-of-scope)
|-
|4A
|2.2.3
|3. Separation Techniques
|-
|4A
|2.2.3.A
|
:A. Logical separation
|-
|4A
|2.2.3.A(1)
|
::(1) Firewalls; and
|-
|4A
|2.2.3.A(2)
|
::(2) Virtual Local Area Network (VLANs)
|-
|4A
|2.2.3.B
|
:B. Physical separation
|-
|4A
|2.2.3.B(1)
|
::(1) Gates;
|-
|4A
|2.2.3.B(2)
|
::(2) Locks;
|-
|4A
|2.2.3.B(3)
|
::(3) Badge access; and
|-
|4A
|2.2.3.B(4)
|
::(4) Guards
|}

=== Task 3. Evaluate CMMC assessment scope considerations based on the CMMC Level 2 Assessment Scoping Guide. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|4E
|2.3.1
|1. FCI and CUI within the same Assessment Scope:
|-
|4E
|2.3.1.A
|
:A. Contractor defines FCI/CUI assets (In-scope)
|-
|4E
|2.3.1.B
|
:B. CMMC Assessor certifies implementation of Level 1 & 2 practices
|-
|4E
|2.3.2
|2. FCI and CUI NOT within the same Assessment Scope:
|-
|4E
|2.3.2.A
|
:A. Contractor defines Self-Assessment of FCI assets (In-scope)
|-
|4E
|2.3.2.B
|
:B. Contractor defines CUI assets (In-scope), CMMC Assessor certifies implementation of Level 1 & 2 practices
|-
|-
|4C, 4D
|2.3.3
|3. External Services Providers
|-
|4D
|2.3.3.A
|
:A. Evaluation of responsibility matrix
|-
|2C, 4E
|2.3.3.B
|
:B. Non-Duplication
|-
|4D
|2.3.3.C
|
:C. Agreements, Service-Level Agreements (SLAs)
|}

== Domain 3: CMMC Assessment Process (CAP) v5.X ==
=== Task 1. Given a scenario, apply the appropriate phases and steps to plan, prepare, conduct, and report on a CMMC Level 2 Assessment. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3A, 3B, 3C
|3.1.1
|1. Phase 1 - Plan and Prepare Assessments:
|-
|3B
|3.1.1.A
|
:A. Analyze requirements
|-
|3C
|3.1.1.B
|
:B. Develop Assessment plan
|-
|3B
|3.1.1.C
|
:C. Verify readiness to conduct assessment
|-
|3A, 3D
|3.1.2
|2. Phase 2 - Conduct assessment:
|-
|3D
|3.1.2.A
|
:a. Collect and examine Evidence
|-
|3D
|3.1.2.B
|
:b. Score practices and validate preliminary results
|-
|3D
|3.1.2.C
|
:c. Generate final recommended Assessment Results
|-
|3A
|3.1.3
|3. Phase 3 - Report Recommended Assessment Results:
|-
|3F
|3.1.3.A
|
:a. Deliver Recommended Assessment Results
|}

== Domain 4: CMMC Levels 2 Practices ==
=== Task 1. Identify evidence verification/validation methods and objects for Practices based on the CMMC Level 2 Assessment Guide and CMMC Assessment Process (CAP) documentation. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3D
|4.1.1
|1. Methods and objects for determining evidence
|-
|3D
|4.1.1.A
|
:A. Examine
|-
|3D
|4.1.1.B
|
:B. Interview
|-
|3D
|4.1.1.C
|
:C. Test
|-
|3D
|4.1.2
|2. Adequacy and sufficiency related to Evidence around all below practices
|-
|3D
|4.1.2.A
|
:A. Characteristics of acceptable Evidence
|-
|3D
|4.1.2.B
|
:B. Evidence of enabling persistent and habitual application of practices
|-
|3D
|4.1.2.B(1)
|
::(1) Policy
|-
|3D
|4.1.2.B(2)
|
::(2) Plan
|-
|3D
|4.1.2.B(3)
|
::(3) Resourcing
|-
|3D
|4.1.2.B(4)
|
::(4) Communication
|-
|3D
|4.1.2.B(5)
|
::(5) Training
|-
|3D
|4.1.2.C
|
:C. Characterization of evidence
|-
|2C, 3D
|4.1.2.C(1)
|
::(1) Validate that evidence effectively meets intent of standard
|-
|3D
|4.1.2.C(2)
|
::(2) An objective and systematic examination of evidence for the purpose of providing an independent assessment of the performance of CMMC
|-
|5A, 6A, 7A, 8A, 9A, 10A, 11A, 12A, 13A, 14A, 15A, 16, 17A, 18A
|4.1.3
|3. CMMC Level 2 Assessment Practice objectives including potential methods, objects, and assessment considerations (by domain):
(at a minimum the practices listed below must be evaluated for CCA candidates)
|-
|5A, 5B
|4.1.3.A
|A. Access Control (AC)
|-
|5A
|4.1.3.A(1)
|
:(1) AC.L2-3.1.3 – Control CUI Flow
|-
|5A
|4.1.3.A(2)
|
:(2) AC.L2-3.1.4 – Separation of Duties
|-
|5A
|4.1.3.A(3)
|
:(3) AC.L2-3.1.5 – Least Privilege
|-
|5A
|4.1.3.A(4)
|
:(4) AC.L2-3.1.6 – Non-Privileged Account Use
|-
|5A
|4.1.3.A(5)
|
:(5) AC.L2-3.1.7 – Privileged Functions
|-
|5A
|4.1.3.A(6)
|
:(6) AC.L2-3.1.8 – Unsuccessful Logon Attempts
|-
|5A
|4.1.3.A(7)
|
:(7) AC.L2-3.1.9 – Privacy & Security Notices
|-
|5A
|4.1.3.A(8)
|
:(8) AC.L2-3.1.10 – Session Lock
|-
|5A
|4.1.3.A(9)
|
:(9) AC.L2-3.1.11 – Session Termination
|-
|5A
|4.1.3.A(10)
|
:(10) AC.L2-3.1.12 – Control Remote Access
|-
|5A
|4.1.3.A(11)
|
:(11) AC.L2-3.1.13 – Remote Access Confidentiality
|-
|5A
|4.1.3.A(12)
|
:(12) AC.L2-3.1.14 – Remote Access Routing
|-
|5A
|4.1.3.A(13)
|
:(13) AC.L2-3.1.15 – Privileged Remote Access
|-
|5A
|4.1.3.A(14)
|
:(14) AC.L2-3.1.16 – Wireless Access Authorization
|-
|5A
|4.1.3.A(15)
|
:(15) AC.L2-3.1.17 – Wireless Access Protection
|-
|5A
|4.1.3.A(16)
|
:(16) AC.L2-3.1.18 – Mobile Device Connection
|-
|5A
|4.1.3.A(17)
|
:(17) AC.L2-3.1.19 – Encrypt CUI on Mobile
|-
|5A
|4.1.3.A(18)
|
:(18) AC.L2-3.1.21 – Portable Storage Use
|-
|6A, 6B
|4.1.3.B
|B. Awareness & Training (AT)
|-
|6A
|4.1.3.B(1)
|
:(1) AT.L2-3.2.1 – Role-Based Risk Awareness
|-
|6A
|4.1.3.B(2)
|
:(2) AT.L2-3.2.2 – Role-Based Training
|-
|6A
|4.1.3.B(3)
|
:(3) AT.L2-3.2.3 – Insider Threat Awareness
|-
|7A, 7B
|4.1.3.C
|C. Audit & Accountability (AU)
|-
|7A
|4.1.3.C(1)
|
:(1) AU.L2-3.3.1 – System Auditing
|-
|7A
|4.1.3.C(2)
|
:(2) AU.L2-3.3.2 – User Accountability
|-
|7A
|4.1.3.C(3)
|
:(3) AU.L2-3.3.3 – Event Review
|-
|7A
|4.1.3.C(4)
|
:(4) AU.L2-3.3.4 – Audit Failure Alerting
|-
|7A
|4.1.3.C(5)
|
:(5) AU.L2-3.3.5 – Audit Correlation
|-
|7A
|4.1.3.C(6)
|
:(6) AU.L2-3.3.6 – Reduction & Reporting
|-
|7A
|4.1.3.C(7)
|
:(7) AU.L2-3.3.7 – Authoritative Time Source
|-
|7A
|4.1.3.C(8)
|
:(8) AU.L2-3.3.8 – Audit Protection
|-
|7A
|4.1.3.C(9)
|
:(9) AU.L2-3.3.9 – Audit Management
|-
|9A, 9B
|4.1.3.D
|D. Configuration Management (CM)
|-
|9A
|4.1.3.D(1)
|
:(1) CM.L2-3.4.1 – System Baselining
|-
|9A
|4.1.3.D(2)
|
:(2) CM.L2-3.4.2 – Security Configuration Enforcement
|-
|9A
|4.1.3.D(3)
|
:(3) CM.L2-3.4.3 – System Change Management
|-
|9A
|4.1.3.D(4)
|
:(4) CM.L2-3.4.4 – Security Impact Analysis
|-
|9A
|4.1.3.D(5)
|
:(5) CM.L2-3.4.5 – Access Restrictions for Change
|-
|9A
|4.1.3.D(6)
|
:(6) CM.L2-3.4.6 – Least Functionality
|-
|9A
|4.1.3.D(7)
|
:(7) CM.L2-3.4.7 – Nonessential Functionality
|-
|9A
|4.1.3.D(8)
|
:(8) CM.L2-3.4.8 – Application Execution Policy
|-
|9A
|4.1.3.D(9)
|
:(9) CM.L2-3.4.9 – User-Installed Software
|-
|10A, 10B
|4.1.3.E
|E. Identification & Authentication (IA)
|-
|10A
|4.1.3.E(1)
|
:(1) IA.L2-3.5.3 – Multifactor Authentication
|-
|10A
|4.1.3.E(2)
|
:(2) IA.L2-3.5.4 – Replay-Resistant Authentication
|-
|10A
|4.1.3.E(3)
|
:(3) IA.L2-3.5.5 – Identifier Reuse
|-
|10A
|4.1.3.E(4)
|
:(4) IA.L2-3.5.6 – Identifier Handling
|-
|10A
|4.1.3.E(5)
|
:(5) IA.L2-3.5.7 – Password Complexity
|-
|10A
|4.1.3.E(6)
|
:(6) IA.L2-3.5.8 – Password Reuse
|-
|10A
|4.1.3.E(7)
|
:(7) IA.L2-3.5.9 – Temporary Passwords
|-
|10A
|4.1.3.E(8)
|
:(8) IA.L2-3.5.10 – Cryptographically-Protected Passwords
|-
|10A
|4.1.3.E(9)
|
:(9) IA.L2-3.5.11 – Obscure Feedback
|-
|11A, 11B
|4.1.3.F
|F. Incident Response (IR)
|-
|11A
|4.1.3.F(1)
|
:(1) IR.L2-3.6.1 – Incident Handling
|-
|11A
|4.1.3.F(2)
|
:(2) IR.L2-3.6.2 – Incident Reporting
|-
|11A
|4.1.3.F(3)
|
:(3) IR.L2-3.6.3 – Incident Response Testing
|-
|12A, 12B
|4.1.3.G
|G. Maintenance (MA)
|-
|12A
|4.1.3.G(1)
|
:(1) MA.L2-3.7.1 – Perform Maintenance
|-
|12A
|4.1.3.G(2)
|
:(2) MA.L2-3.7.2 – System Maintenance Control
|-
|12A
|4.1.3.G(3)
|
:(3) MA.L2-3.7.3 – Equipment Sanitization
|-
|12A
|4.1.3.G(4)
|
:(4) MA.L2-3.7.4 – Media Inspection
|-
|12A
|4.1.3.G(5)
|
:(5) MA.L2-3.7.5 – Nonlocal Maintenance
|-
|12A
|4.1.3.G(6)
|
:(6) MA.L2-3.7.6 – Maintenance Personnel
|-
|13A, 13B
|4.1.3.H
|H. Media Protection (MP)
|-
|13A
|4.1.3.H(1)
|
:(1) MP.L2-3.8.1 – Media Protection
|-
|13A
|4.1.3.H(2)
|
:(2) MP.L2-3.8.2 – Media Access
|-
|13A
|4.1.3.H(3)
|
:(3) MP.L2-3.8.4 – Media Markings
|-
|13A
|4.1.3.H(4)
|
:(4) MP.L2-3.8.5 – Media Accountability
|-
|13A
|4.1.3.H(5)
|
:(5) MP.L2-3.8.6 – Portable Storage Encryption
|-
|13A
|4.1.3.H(6)
|
:(6) MP.L2-3.8.7 – Removeable Media
|-
|13A
|4.1.3.H(7)
|
:(7) MP.L2-3.8.8 – Shared Media
|-
|13A
|4.1.3.H(8)
|
:(8) MP.L2-3.8.9 – Protect Backups
|-
|15A, 15B
|4.1.3.I
|I. Personnel Security (PS)
|-
|15A
|4.1.3.I(1)
|
:(1) PS.L2-3.9.1 – Screen Individuals
|-
|15A
|4.1.3.I(2)
|
:(2) PS.L2-3.9.2 – Personnel Actions
|-
|14A, 14B
|4.1.3.J
|J. Physical Protection (PE)
|-
|14A
|4.1.3.J(1)
|
:(1) PE.L2-3.10.2 – Monitor Facility
|-
|14A
|4.1.3.J(2)
|
:(2) PE.L2-3.10.6 – Alternative Work Sites
|-
|16A, 16B
|4.1.3.K
|K. Risk Assessment (RA)
|-
|16A
|4.1.3.K(1)
|
:(1) RA.L2-3.11.1 – Risk Assessments
|-
|16A
|4.1.3.K(2)
|
:(2) RA.L2-3.11.2 – Vulnerability Scan
|-
|16A
|4.1.3.K(3)
|
:(3) RA.L2-3.11.3 – Vulnerability Remediation
|-
|8A, 8B
|4.1.3.L
|L. Security Assessment (CA)
|-
|8A
|4.1.3.L(1)
|
:(1) CA.L2-3.12.1 – Security Control Assessment
|-
|8A
|4.1.3.L(2)
|
:(2) CA.L2-3.12.2 – Plan of Action
|-
|8A
|4.1.3.L(3)
|
:(3) CA.L2-3.12.3 – Security Control Monitoring
|-
|8A
|4.1.3.L(4)
|
:(4) CA.L2-3.12.4 – System Security Plan
|-
|17A, 17B
|4.1.3.M
|M. System & Communications Protection (SC)
|-
|17A
|4.1.3.M(1)
|
:(1) SC.L2-3.13.2 – Security Engineering
|-
|17A
|4.1.3.M(2)
|
:(2) SC.L2-3.13.3 – Role Separation
|-
|17A
|4.1.3.M(3)
|
:(3) SC.L2-3.13.4 – Shared Resource Control
|-
|17A
|4.1.3.M(4)
|
:(4) SC.L2-3.13.6 – Network Communication by Exception
|-
|17A
|4.1.3.M(5)
|
:(5) SC.L2-3.13.7 – Split Tunneling
|-
|17A
|4.1.3.M(6)
|
:(6) SC.L2-3.13.8 – Data in Transit
|-
|17A
|4.1.3.M(7)
|
:(7) SC.L2-3.13.9 – Connections Termination
|-
|17A
|4.1.3.M(8)
|
:(8) SC.L2-3.13.10 – Key Management
|-
|17A
|4.1.3.M(9)
|
:(9) SC.L2-3.13.11 – CUI Encryption
|-
|17A
|4.1.3.M(10)
|
:(10) SC.L2-3.13.12 – Collaborative Device Control
|-
|17A
|4.1.3.M(11)
|
:(11) SC.L2-3.13.13 – Mobile Code
|-
|17A
|4.1.3.M(12)
|
:(12) SC.L2-3.13.14 – Voice over Internet Protocol
|-
|17A
|4.1.3.M(13)
|
:(13) SC.L2-3.13.15 – Communications Authenticity
|-
|17A
|4.1.3.M(14)
|
:(14) SC.L2-3.13.16 – Data at Rest
|-
|18A, 18B
|4.1.3.N
|N. System & Information Integrity (SI)
|-
|18A
|4.1.3.N(1)
|
:(1) SI.L2-3.14.3 – Security Alerts & Advisories
|-
|18A
|4.1.3.N(2)
|
:(2) SI.L2-3.14.6 – Monitor Communications for Attacks
|-
|18A
|4.1.3.N(3)
|
:(3) SI.L2-3.14.7 – Identify Unauthorized Use
|}

CCP Blueprint

2026-03-02T01:32:18Z

David:

'''Source of Reference: The CCP blueprint document from [https://cyberab.org/CMMC-Ecosystem/Ecosystem-roles/Assessing-and-Certification Cybersecurity Maturity Model Certification Accreditation Body, Inc.]'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Domains ==
Upon successful completion of this exam, the candidate will be able to apply skills and knowledge to the below domains:
{|class="wikitable"
|-
! Objective !! '''Domain''' !! '''Exam Weight'''
|-
|-
|1.0
|1. CMMC Ecosystem
|5%
|-
|2.0
|2. CMMC-AB Code of Professional Conduct (Ethics)
|5%
|-
|3.0
|3. CMMC Governance and Sources Documents
|15%
|-
|4.0
|4. CMMC Model Construct and Implementation Evaluation
|35%
|-
|5.0
|5. CMMC Assessment Process (CAP)
|25%
|-
|6.0
|6. Scoping
|15%
|}

== Domain 1: CMMC Ecosystem ==
=== Task 1. Identify and compare roles/responsibilities/requirements of authorities across the CMMC Ecosystem. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3B
|1.1.1
|1. Authorities:
|-
|3B
|1.1.1.A
|A. Office of the Undersecretary of Defense (OUSD)
|-
|1B, 3A, 7A, 8A
|1.1.1.A.1
|
:(1) Cybersecurity standards and best practices and knowledge of how to map these controls and processes across several levels that range from basic to advanced cyber hygiene
|-
|1B, 3B, 3C
|1.1.1.A.2
|
:(2) Regulation (DFARS 252.204-7012) that is based on trust by adding a verification component with respect to cybersecurity requirements
|-
|3B
|1.1.1.B
|B. CMMC Ecosystem and the different types of entities participating in it
|-
|3B
|1.1.1.B.1
|
:(1) Cybersecurity Maturity Model Certification Accreditation Body (CMMC-AB)
|-
|3B
|1.1.1.B.1.a
|
::(a) Organizations:
|-
|3B
|1.1.1.B.1.a.1
|
:::1. Organizations Seeking Certification (OSC)
|-
|3B
|1.1.1.B.1.a.1.1
|
::::(1) Purpose, Requirements, and benefits of OSC involvement in the ecosystem
|-
|3B
|1.1.1.B.1.a.2
|
:::2. CMMC Third-Party Assessment Organizations (C3PAO)
|-
|3B
|1.1.1.B.1.a.3
|
:::3. Registered Provider Organizations (RPO)
|-
|3B
|1.1.1.B.1.a.3.1
|
::::(1) Requirements and Benefits of RPO
|-
|3B
|1.1.1.B.1.b
|
::(b) Individuals:
|-
|3B
|1.1.1.B.1.b.1
|
:::1. Registered Practitioner (RP)
|-
|3B
|1.1.1.B.1.b.1.1
|
::::(1) RPs in the CMMC ecosystem provide advice, consulting, and recommendations to their clients. They are the “implementers” and consultants, but do not participate in Certified CMMC Assessments.
|-
|3B
|1.1.1.B.2
|
:(2) CMMC Assessors and Instructors Certification Organization (CAICO)
|-
|3B
|1.1.1.B.2.a
|
::(a) Organizations:
|-
|3B
|1.1.1.B.2.a.1
|
:::1. Licensed Partner Publishers (LPP)
|-
|3B
|1.1.1.B.2.a.1.1
|
::::(1) Purpose, requirements, and benefits of LPPs
|-
|3B
|1.1.1.B.2.a.2
|
:::2. Licensed Training Providers (LTP)
|-
|3B
|1.1.1.B.2.a.2.1
|
::::(1) Purpose, requirements, and benefits of LTPs
|-
|3B
|1.1.1.B.2.b
|
::(b) Individuals:
|-
|3B
|1.1.1.B.2.b.1
|
:::1. Provisional Assessors (PA)
|-
|3B
|1.1.1.B.2.b.1.1
|
::::(1) Purpose, requirements, and benefits of PAs
|-
|3B
|1.1.1.B.2.b.1.2
|
::::(2) Timeline for sunsetting
|-
|3B
|1.1.1.B.2.b.2
|
:::2. Provisional Instructors (PI)
|-
|3B
|1.1.1.B.2.b.2.1
|
::::(1) Purpose, requirements, and benefits of PIs
|-
|3B
|1.1.1.B.2.b.2.2
|
::::(2) Timeline for sunsetting
|-
|3B
|1.1.1.B.2.b.3
|
:::3. Certified CMMC Professional (CCP)
|-
|3B
|1.1.1.B.2.b.3.1
|
::::(1) Purpose, requirements, and benefits of CCPs’ active involvement in the ecosystem
|-
|3B
|1.1.1.B.2.b.3.2
|
::::(2) Timeline for CCP certification and assessments
|-
|3B
|1.1.1.B.2.b.4
|
:::4. Certified CMMC Assessor (CCA)
|-
|3B
|1.1.1.B.2.b.4.1
|
::::(1) Purpose, requirements, and benefits of CCAs’ active involvement in the ecosystem
|-
|3B
|1.1.1.B.2.b.4.2
|
::::(2) Timeline for CCA certification and assessments
|-
|3B
|1.1.1.B.2.b.5
|
:::5. Certified CMMC Instructor (CCI)
|-
|3B
|1.1.1.B.2.b.5.1
|
::::(1) Purpose, requirements, and benefits of CCIs’ active involvement in the ecosystem
|-
|3B
|1.1.1.B.2.b.5.2
|
::::(2) Timeline for CCI certification and assessments
|-
|3B, 10A
|1.1.1.B.2.b.6
|
:::6. Assessment Team Member
|-
|3B, 10A
|1.1.1.B.2.b.6.1
|
::::(1) CCP and CCA roles on the Assessment Team
|-
|3B, 10A
|1.1.1.B.2.b.7
|
:::7. CMMC Lead Assessor
|-
|3B, 10A
|1.1.1.B.2.b.7.1
|
::::(1) Lead Assessor role on the Assessment Team
|-
|3B
|1.1.1.B.2.b.7.2
|
::::(2) Timeline for Lead Assessor certification
|}

== Domain 2: CMMC-AB Code of Professional Conduct (Ethics) ==
=== Task 1. Identify and apply knowledge of the Guiding Principles and Practices of the CMMC-AB Code of Professional Conduct (CoPC)/ISO/IEC/DOD requirements. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|4B
|2.1.1
|1. General ethics topics
|-
|-
|4B
|2.1.2
|2. CMMC-AB Code of Professional Conduct (CoPC)
|-
|3B, 4A
|2.1.3
|3. ISO/IEC
|-
|4B
|2.1.4
|4. Department of Defense (DoD) requirements
|-
|4B
|2.1.5
|5. Professionalism
|-
|4B
|2.1.6
|6. Objectivity
|-
|4B
|2.1.7
|7. Confidentiality
|-
|4B
|2.1.8
|8. Proper use of methods
|-
|4B
|2.1.9
|9. Information integrity
|-
|4B
|2.1.10
|10. Conflicts of interest
|-
|4B
|2.1.11
|11. Respect for intellectual property
|-
|4B
|2.1.12
|12. Lawful and ethical practices
|-
|4A, 4B, 7A, 10B
|2.1.13
|13. Contracts and non-disclosure agreements
|}

== Domain 3. CMMC Governance and Source Documents ==
=== Task 1. Demonstrate understanding of Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) in non-federal unclassified networks. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|1B
|3.1.1
|1. Current Department of Defense (DoD) Defense Industrial Base (DIB) Cybersecurity Efforts, Regulations, and Executive Orders pertaining to the CMMC program:
|-
|1B, 2B
|3.1.1.A
|
:A. Part 32 of the Code of Federal Regulations (C.F.R.)
|-
|1B
|3.1.1.B
|
:B. Defense Federal Acquisition Regulation Supplement (DFARS) in Part 48 of the C.F.R
|-
|1B, 3B
|3.1.1.C
|
:C. DFARS Clause 252.204-7012
|-
|1B, 7B
|3.1.1.C.1
|
::(1) National Institute of Standards and Technology (NIST) SP 800-171
|-
|2A
|3.1.1.C.2
|
::(2) Technical Data (DFARS 252.227-7013)
|-
|1B
|3.1.1.C.3
|
::(3) FedRAMP
|-
|3B
|3.1.2
|2. CMMC Framework Tenets:
|-
|3B
|3.1.2.A
|
:A. Key aspects of CMMC v.20 program requirements
|-
|3B
|3.1.2.A.1
|
::(1) Streamlined Model
|-
|3B, 7B
|3.1.2.A.1.a
|
:::(a) Focused on the most critical requirements
|-
|3B, 7B
|3.1.2.A.1.b
|
:::(b) Aligned with widely accepted standards
|-
|3B
|3.1.2.A.2
|
::(2) Reliable Assessments
|-
|3B
|3.1.2.A.2.a
|
:::(a) Reduced assessment costs
|-
|3B
|3.1.2.A.2.b
|
:::(b) Higher accountability
|-
|3B
|3.1.2.A.3
|
::(3) Flexible Implementation
|-
|3B
|3.1.2.A.3.a
|
:::(a) Spirit of collaboration
|-
|3B
|3.1.2.A.3.b
|
:::(b) Added flexibility and speed
|-
|3B
|3.1.2.B
|
:B. Rulemaking and timeline for CMMC v2.0
|-
|3B
|3.1.2.B.1
|
::(1) Incentives, Assessments, and 9–24-month rule making
|-
|3B
|3.1.2.C
|
:C. Levels of CMMC assessments and requirements
|-
|3B
|3.1.2.C.1
|
::(1) Foundational/Level 1 (same as previous CMMC v1.0 level 1)
|-
|8A
|3.1.2.C.1.a
|
:::(a) FAR Clause 52.204-21
|-
|3A, 8A
|3.1.2.C.1.a.i
|
::::i. Provide overview of the 17 basic safeguarding requirements and how procedures are applied within the CMMC L1/L2 practices/assessment framework
|-
|3A, 3B, 9A
|3.1.2.C.2
|
::(2) Advanced/Level 2 (previous level 3)
|-
|3A, 7B
|3.1.2.C.2.a
|
:::(a) NIST SP 800-171 (Requirements)
|-
|3A, 7B, 9A
|3.1.2.C.2.a.i
|
::::i. Provide overview of the 110 NIST SP 800-171 requirements and how they are applied within the CMMC Level 2 practices/assessment framework
|-
|3B, 3C
|3.1.2.D
|
:D. Self-Assessments vs. Third-Party Assessments
|-
|3B, 3C
|3.1.2.D.1
|
::(1) Define different criteria for various assessment type under CMMC v2.0 framework
|-
|3C
|3.1.3
|3. Consequences of non-compliance:
|-
|3C
|3.1.3.A
|
:A. Failure to receive an award of contract
|-
|3C
|3.1.3.B
|
:B. Contractual liability
|-
|3C
|3.1.3.C
|
:C. False Claims Act
|-
|3C
|3.1.3.C.1
|
::(1) US Department of Justice,
|-
|3C
|3.1.3.C.1.a
|
:::(a) Civil Cyber-Fraud Initiative
|}

=== Task 2. Determine the appropriate roles/responsibilities/authority for Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|2A
|3.2.1
|1. Importance of data classification, collection, and analysis
|-
|2A
|3.2.1.A
|
:A. CUI Basic versus Specified
|-
|2A
|3.2.2
|2. Contractor sensitive data categories
|-
|2A
|3.2.2.A
|
:A. Federal Contract Information (FCI)
|-
|2A
|3.2.2.A.1
|
::(1) Section 4.1901 of the Federal Acquisition Regulation (FAR)
|-
|2A
|3.2.2.B
|
:B. Controlled Unclassified Information (CUI)
|-
|2A, 2B
|3.2.2.B.1
|
::(1) Part 2002 of Title 32 CFR, 2002.4(h)
|-
|2A, 2B
|3.2.3
|3. Government authority for identifying and marking CUI
|-
|2A, 2B
|3.2.3.A
|
:A. Executive Order 13556
|-
|2A, 2B
|3.2.3.B
|
:B. 32 Code of Federal Regulations, Part 2002 (Implementing Directive)
|-
|2A, 2B
|3.2.3.C
|
:C. DoD Instruction 5200.48, Controlled Unclassified Information (CUI)
|-
|2B
|3.2.4
|4. Contractor/Authorized holders’ responsibilities in handling CUI
|-
|2B
|3.2.4.A
|
:A. DoDI 5200.48
|-
|1B, 2B
|3.2.4.B
|
:B. Part 2002 of Title 32 CFR
|}

=== Task 3. Demonstrate understanding of the CMMC Source and Supplementary documents. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3A
|3.3.1
|1. CMMC Source Documents
|-
|3A, 7B
|3.3.1.A
|
:A. CMMC Model Overview
|-
|7A, 7B
|3.3.1.B
|
:B. CMMC Level 1 Assessment Guide
|-
|7A, 7B
|3.3.1.C
|
:C. CMMC Level 2 Assessment Guide
|-
|5A
|3.3.1.D
|
:D. CMMC Level 1 Scoping Guidance
|-
|5A
|3.3.1.E
|
:E. CMMC Level 2 Scoping Guidance
|-
|3A, 7A, 10B, 10C, 10D, 10E
|3.3.1.F
|
:F. CMMC Assessment Process (CAP)
|-
|3A
|3.3.1.G
|
:G. CMMC Glossary
|-
|3A, 10D
|3.3.1.H
|
:H. CMMC Artifact Hashing Tool User Guide
|-
|2A
|3.3.2
|2. ISOO CUI Registry
|-
|2A
|3.3.2.A
|
:A. NARA administers the CUI Registry
|-
|2A
|3.3.2.A.1
|
::(1) Types of labeled information on documents such as:
|-
|2A
|3.3.2.A.1.a
|
:::(a) Export Controlled (SP-EXPT)
|-
|2B
|3.3.2.A.1.b
|
:::(b) Specified marking/labeling using NARA CUI Marking Handbook
|-
|2A
|3.3.3
|3. DoD CUI Registry
|-
|2A, 2B
|3.3.3.A
|
:A. Types of labeled information on documents such as:
|-
|2A, 2B
|3.3.3.A.1
|
::(1) Naval Nuclear Propulsion Information (NNPI)
|-
|2A, 2B
|3.3.3.A.2
|
::(2) NNPI marking/labeling using DoD CUI Marking Aid
|}

== Domain 4 - CMMC Model Construct and Implementation Evaluation ==
=== Task 1. Given a scenario, apply the appropriate CMMC Source Documents as an aid to evaluate the implementation/review of CMMC practices. ===
(At a minimum CCP candidate must be evaluated on CMMC L1 Practices during CCP exam)
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3A
|4.1.1
|1. Model Architecture
|-
|3A
|4.1.2
|2. Model Levels:
|-
|3A, 7B
|4.1.2.A
|
:A. Cumulative Nature
|-
|3A
|4.1.2.B
|
:B. Characteristics
|-
|3B
|4.1.2.C
|
:C. Levels required for specific contracts
|-
|3B
|4.1.2.C.1
|
::(1) Level 1
|-
|3B
|4.1.2.C.2
|
::(2) Level 2
|-
|3A
|4.1.3
|3. Practices:
|-
|7B
|4.1.3.A
|
:A. Practices Descriptions
|-
|3A
|4.1.3.A.1
|
::(1) Practice Numbering Scheme
|-
|3A
|4.1.3.A.2
|
::(2) Objectives
|-
|7B
|4.1.3.A.3
|
::(3) Assessment Methods and Objects
|-
|8A
|4.1.4
|4. Domains:
|-
|3A
|4.1.4.A
|
:A. Access Control (AC)
|-
|8A
|4.1.4.A.1
|
::(1) AC.L1-3.1.1 – Authorized Access Control
|-
|8A
|4.1.4.A.2
|
::(2) AC.L1-3.1.2 – Transaction & Function Control
|-
|8A
|4.1.4.A.3
|
::(3) AC.L1-3.1.20 – External Connections
|-
|8A
|4.1.4.A.4
|
::(4) AC.L1-3.1.22 – Control Public Information
|-
|3A
|4.1.4.B
|
:B. Audit & Accountability (AU)
|-
|3A
|4.1.4.C
|
:C. Awareness & Training (AT)
|-
|3A
|4.1.4.D
|
:D. Configuration Management (CM)
|-
|3A
|4.1.4.E
|
:E. Identification & Authentication (IA)
|-
|8A
|4.1.4.E.1
|
::(1) IA.L1-3.5.1 – Identification
|-
|8A
|4.1.4.E.2
|
::(2) IA.L1-3.5.2 – Authentication
|-
|3A
|4.1.4.F
|
:F. Incident Response (IR)
|-
|3A
|4.1.4.G
|
:G. Maintenance (MA)
|-
|3A
|4.1.4.H
|
:H. Media Protection (MP)
|-
|8A
|4.1.4.H.1
|
::(1) MP.L1-3.8.3 – Media Disposal
|-
|3A
|4.1.4.I
|
:I. Personnel Security (PS)
|-
|3A
|4.1.4.J
|
:J. Physical Protection (PE)
|-
|8A
|4.1.4.J.1
|
::(1) PE.L1-3.10.1 – Limit Physical Access
|-
|8A
|4.1.4.J.2
|
::(2) PE.L1-3.10.3 – Escort Visitors
|-
|8A
|4.1.4.J.3
|
::(3) PE.L1-3.10.4 – Physical Access Logs
|-
|8A
|4.1.4.J.4
|
::(4) PE.L1-3.10.5 – Manage Physical Access
|-
|3A
|4.1.4.K
|
:K. Risk Assessment (RA)
|-
|3A
|4.1.4.L
|
:L. Security Assessment (CA)
|-
|3A
|4.1.4.M
|
:M. System & Communications Protection (SC)
|-
|8A
|4.1.4.M.1
|
::(1) SC.L1-3.13.1 – Boundary Protection
|-
|8A
|4.1.4.M.2
|
::(2) SC.L1-3.13.5 – Public-Access System Separation
|-
|3A
|4.1.4.N
|
:N. System & Information Integrity (SI)
|-
|8A
|4.1.4.N.1
|
::(1) SI.L1-3.14.1 – Flaw Remediation
|-
|8A
|4.1.4.N.1
|
::(2) SI.L1-3.14.2 – Malicious Code Protection
|-
|8A
|4.1.4.N.1
|
::(3) SI.L1-3.14.4 – Update Malicious Code Protection
|-
|8A
|4.1.4.N.1
|
::(4) SI.L1-3.14.5 – System & File Scanning
|}

=== Task 2. Apply knowledge of the CMMC Assessment Criteria and Methodology to the appropriate CMMC practices. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|3A, 7B
|4.2.1
|1. The definition of each practice
|-
|3A, 7B
|4.2.2
|2. The Assessment Objectives
|-
|7A, 7B, 8A
|4.2.3
|3. The Assessment Methods (Examine, Interview, and Test) to use for the practices
|-
|7B
|4.2.4
|4. What information to look for in practice discussion
|-
|7B
|4.2.5
|5. The Key References and their applicability to the practices:
|-
|7B
|4.2.5.A
|
::A. Navigating and using the CMMC Assessment Guide(s) content
|-
|7A, 7B
|4.2.5.B
|
::B. Determining the assessment method(s) that would be best for gathering sufficient and accurate evidence
|}

=== Task 3. Analyze the adequacy/sufficiency around the location/collection/quality/usage of Evidence. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|7A
|4.3.1
|1. Appraised Evidence is adequate
|-
|7A
|4.3.2
|2. Measure if the Evidence is sufficient
|}

== Domain 5: CMMC Assessment Process ==
=== Task 1. Choose the appropriate roles of the CCP in the CMMC Assessment Process when developing the assessment plan (Phase 1– Plan and Prepare Assessment). ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|10B
|5.1.1
|1. Validation criteria of OSC’s assessment evidence
|-
|7B
|5.1.2
|2. Analyzing the CMMC practice requirements
|-
|10B
|5.1.3
|3. What needs to be included in a CMMC Assessment Plan
|-
|10B
|5.1.4
|4. The CMMC Readiness Review Process
|}

=== Task 2. Apply CMMC Assessment Process requirements pertaining to the role of the CCP as an assessment team member while conducting a CMMC assessment (Phase 2 – Conduct Assessment). ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|7B, 10C
|5.2.1
|1. How to assist/support the Assessment Team during an assessment
|-
|7A, 7B, 10C
|5.2.2
|2. The three possible assessment methods (Examine, Interview, and Test) and scoring evidence successfully for each practice
|-
|10A, 10C
|5.2.3
|3. Communication skills to interview or observe tests/demonstrations for assessment practices
|-
|7B, 8C, 10C
|5.2.4
|4. How Assessment Team Members rate practices and validate preliminary results
|-
|10C
|5.2.5
|5. How Assessment Team Members assist in the preparation of final findings
|-
|10C
|5.2.6
|6. How to score practices that are on a Plan of Action and Milestone (POA&M)
|}

=== Task 3. Demonstrate comprehension of the CCP role in the preparation of assessment report (Phase 3 – Report Assessment Results). ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|10D
|5.3.1
|1. The evidence presented for each practice
|-
|7B, 10C
|5.3.2
|2. How Assessment Team Members score practices, validate, and deliver assessment preliminary results
|-
|10C
|5.3.3
|3. How the Assessment Lead drafts and scores the final findings
|-
|10D
|5.3.4
|4.# How the final findings and associated information are incorporated into the Assessment Report
|-
|10D
|5.3.5
|5. How the Lead Assessor submits the assessment report, including the review process, submitting to the C3PAO and the OSC
|-
|10D
|5.3.6
|6. How to package and archive the assessment results for a record to support any future questions that may be asked
|}

=== Task 4. Demonstrate comprehension of the CCP role in the process of evaluating outstanding assessment issues on Plan of Action and Milestones (POA&M) (Phase 4 – Evaluation of Outstanding Assessment POA&M Items). ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|10C
|5.4.1
|1. The evaluation of assessment POA&M items
|-
|10C
|5.4.1.A
|
:A. DoD Assessment Methodology, POA&M scoring criteria
|-
|10C
|5.4.1.A.1
|
::(1) Minimum assessment score
|-
|10C
|5.4.1.A.2
|
::(2) Qualifying POA&M items
|-
|10C
|5.4.1.B
|
:B. CMMC AG CA.L2-3.12.2, Plan of Action objectives and requirements
|}

=== Task 5. Given a scenario, determine the appropriate phases/steps to assist in the preparation/conducting/ reporting on a CMMC Level 2 Assessment. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|10B
|5.5.1
|1. Plan and Prepare Assessments:
|-
|10A
|5.5.1.A
|
:A. CMMC CCP must be able to assist in analyzing requirements.
|-
|10A
|5.5.1.B
|
:B. CMMC CCP must be able to assist in developing assessment plan.
|-
|10A
|5.5.1.C
|
:C. CMMC CCP must be able to assist in verifying readiness to conduct assessment.
|-
|10C
|5.5.2
|2. Conduct Assessment:
|-
|10A
|5.5.2.A
|
:A. CMMC CCP must be able to assist in collecting and examining Evidence.
|-
|10A
|5.5.2.B
|
:B. CMMC CCP must be able to assist in scoring practices and validating preliminary results.
|-
|10A
|5.5.2.C
|
:C. CMMC CCP must be able to assist in generating final assessment results.
|-
|10D
|5.5.3
|3. Report Recommended Assessment Results:
|-
|10A
|5.5.3.A
|
:A. CMMC CCP must be able to assist in delivering recommended assessment results.
|-
|10E
|5.5.4
|4. Remediate Outstanding Assessment Issues:
|-
|10A
|5.5.4.A
|
:A. Awareness of the CCP’s Role in the POA&M Process
|}

== Domain 6: Scoping ==
=== Task 1. Understand CMMC High-Level Scoping as described in the CMMC Assessment Process. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|5A
|6.1.1
|1. Defining organizational scoping
|-
|5A
|6.1.1.A
|
:A. Organization
|-
|5A
|6.1.1.B
|
:B. Host Unit
|-
|5A
|6.1.1.C
|
:C. Supporting Units
|}

=== Task 2. Given a Scenario, analyze the organization environment to generate an appropriate scope for FCI Assets. ===
{|class="wikitable" style="width: 85%;"
|-
! style="width: 10%"|Lesson Topic
! style="width: 10%"|Objective
! style="width: 80%"|Objective Description
|-
|5A
|6.2.1
|1. Defining FCI data in the form of Assets that:
|-
|5A
|6.2.1.A
|
:A. Process
|-
|5A
|6.2.1.B
|
:B. Store
|-
|5A
|6.2.1.C
|
:C. Transmit
|-
|5A
|6.2.2
|2. Out-of-Scope Assets
|-
|5A
|6.2.3
|3. Specialized Assets
|-
|5A
|6.2.3.A
|
:A. Government Property
|-
|5A
|6.2.3.B
|
:B. Internet of Things (IoT)/ Industrial Internet of Things (IIoT)
|-
|5A
|6.2.3.C
|
:C. Operational Technology (OT)
|-
|5A
|6.2.3.D
|
:D. Restricted Information Systems
|-
|5A
|6.2.3.E
|
:E. Test Equipment
|-
|5A
|6.2.4
|4. Scoping Activities
|-
|5A
|6.2.4.A
|
:A. People
|-
|5A
|6.2.4.B
|
:B. Technology
|-
|5A
|6.2.4.C
|
:C. Facilities
|-
|5A
|6.2.4.D
|
:D. External Service Providers (ESP)
|}

External References

2026-03-02T01:32:02Z

David:

Additional References: The [https://dodcio.defense.gov/CMMC/Resources/ CMMC Resources] page contains a variety of external links to CMMC resources throughout the DoD.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== B ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Blue Cyber Education Series for Small Business
|
* [https://www.safcn.af.mil/CISO/Small-Business-Cybersecurity-Information/ Home Page]
|}

== C ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''CISA Cyber Security Evaluation Tool (CSET®)'''
|
* [https://www.cisa.gov/stopransomware/cyber-security-evaluation-tool-csetr Home Page]
* [https://github.com/cisagov/cset/releases CSET Download]
|-
|'''CMMC Program Final Rule'''
|
* [https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program 32 CFR Part 170 rule]
|-
|'''Cyber AB, The'''
|
* [https://cyberab.org/ Home Page]
|-
|'''Cybersecurity and Privacy Reference Tool (CPRT)'''
|
* [https://csrc.nist.gov/projects/cprt/catalog#/cprt/home/ CPRT Catalog]
|}

== D ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) Contractor Resources
|
* [https://www.dcma.mil/DIBCAC/ Home Page]
|}

== M ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''MITRE ATT&CK Knowledge Base
|
* [https://attack.mitre.org/ Home Page]
|}

== N ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''NIST Cybersecurity Framework'''
|
* [https://www.nist.gov/cyberframework Home Page]
* [https://www.nist.gov/cyberframework/framework Framework Documents]
* [https://www.nist.gov/cyberframework/online-learning Online Learning]
|-
|'''NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf PDF Download]
|-
|'''NIST SP 800-171 Rev. 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf PDF Download]
|-
|'''NIST SP 800-171A Assessing Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/a/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171a.pdf PDF Download]
|-
|'''NIST SP 800-171 Rev. 3 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/r3/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf PDF Download]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171r3/NIST.SP.800-171r3.html HTML Version]
|-
|'''NIST SP 800-171A Rev.3 Assessing Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/a/r3/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171Ar3.pdf PDF Download]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171Ar3/NIST.SP.800-171Ar3.html HTML Version]
|-
|'''NIST SP 800-172 Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-172/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-172.pdf PDF Download]
|-
|'''NIST SP 800-172A Assessing Enhanced Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-172a/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-172A.pdf PDF Download]
|-
|'''NSA Cybersecurity Products and Services'''
|
* [https://www.nsa.gov/Cybersecurity/Cybersecurity-Products-Services/ Home Page]
* [https://github.com/nsacyber Cybersecurity Directorate GitHub]
|}

== O ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''OSCAL: the Open Security Controls Assessment Language
|
* [https://pages.nist.gov/OSCAL/ Home Page]
|}

== P ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Project Spectrum'''
|
* [https://www.projectspectrum.io/ Home Page]
|}

Commonly Accepted and Practiced CMMC Operation Matrix

2026-03-02T01:31:47Z

David:

The Commonly Accepted and Practiced CMMC Operation Matrix (CAPCOM) serves as an experimental repository for all CMMC Level 2 security requirements, assessment objectives, and AI-enhanced methodologies for evidence collection and evaluation.

Powered by advanced Large Language Model (LLM) technology, CAPCOM provides guidance for evaluating information system compliance with the CMMC program. Security professionals and IT leaders can leverage this AI-enhanced model to systematically identify gaps between their organizational infrastructure and CMMC requirements, enabling strategic remediation planning and implementation.

DISCLAIMER: The LLM-based AI is pretty cool, but it can also create erroneous responses. '''Always double-check a response before using it.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.1_Details | '''AC.L2-3.1.1''' ]] Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). || [[ LLMPrompt_AC.L2-3.1.1 | Sample Prompt Template ]] || N/A
|-
| [a] authorized users are identified. || [[ LLMPrompt_AC.L2-3.1.1.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.a | Sample Response ]]
|-
| [b] processes acting on behalf of authorized users are identified. || [[ LLMPrompt_AC.L2-3.1.1.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.b | Sample Response ]]
|-
| [c] devices (and other systems) authorized to connect to the system are identified. || [[ LLMPrompt_AC.L2-3.1.1.c | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.c | Sample Response ]]
|-
| [d] system access is limited to authorized users. || [[ LLMPrompt_AC.L2-3.1.1.d | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.d | Sample Response ]]
|-
| [e] system access is limited to processes acting on behalf of authorized users. || [[ LLMPrompt_AC.L2-3.1.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.e | Sample Response ]]
|-
| [f] system access is limited to authorized devices (including other systems). || [[ LLMPrompt_AC.L2-3.1.1.f | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.1.f | Sample Response ]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.2_Details | '''AC.L2-3.1.2''' ]] Limit information system access to the types of transactions and functions that authorized users are permitted to execute. || [[ LLMPrompt_AC.L2-3.1.2 | Sample Prompt Template ]] || N/A
|-
| [a] the types of transactions and functions that authorized users are permitted to execute are defined. || [[ LLMPrompt_AC.L2-3.1.2.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.2.a | Sample Response ]]
|-
| [b] system access is limited to the defined types of transactions and functions for authorized users. || [[ LLMPrompt_AC.L2-3.1.2.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.2.b | Sample Response ]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.3_Details | '''AC.L2-3.1.3''' ]] Control the flow of CUI in accordance with approved authorizations. || [[ LLMPrompt_AC.L2-3.1.3 | Sample Prompt Template ]] || N/A
|-
| [a] information flow control policies are defined. || [[ LLMPrompt_AC.L2-3.1.3.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.3.a | Sample Response ]]
|-
| [b] methods and enforcement mechanisms for controlling the flow of CUI are defined. || [[ LLMPrompt_AC.L2-3.1.3.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.3.b | Sample Response ]]
|-
| [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified. || [[ LLMPrompt_AC.L2-3.1.3.c | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.3.c | Sample Response ]]
|-
| [d] authorizations for controlling the flow of CUI are defined. || [[ LLMPrompt_AC.L2-3.1.3.d | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.3.d | Sample Response ]]
|-
| [e] approved authorizations for controlling the flow of CUI are enforced. || [[ LLMPrompt_AC.L2-3.1.3.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.3.e | Sample Response ]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.4_Details | '''AC.L2-3.1.4''' ]] Separate the duties of individuals to reduce the risk of malevolent activity without collusion. || [[ LLMPrompt_AC.L2-3.1.4 | Sample Prompt Template ]] || N/A
|-
| [a] the duties of individuals requiring separation are defined. || [[ LLMPrompt_AC.L2-3.1.4.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.4.a | Sample Response ]]
|-
| [b] responsibilities for duties that require separation are assigned to separate individuals. || [[ LLMPrompt_AC.L2-3.1.4.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.4.b | Sample Response ]]
|-
| [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. || [[ LLMPrompt_AC.L2-3.1.4.c | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.4.c | Sample Response ]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.5_Details | '''AC.L2-3.1.5''' ]] Employ the principle of least privilege, including for specific security functions and privileged accounts. || [[ LLMPrompt_AC.L2-3.1.5 | Sample Prompt Template ]] || N/A
|-
| [a] privileged accounts are identified. || [[ LLMPrompt_AC.L2-3.1.5.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.5.a | Sample Response ]]
|-
| [b] access to privileged accounts is authorized in accordance with the principle of least privilege. || [[ LLMPrompt_AC.L2-3.1.5.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.5.b | Sample Response ]]
|-
| [c] security functions are identified. || [[ LLMPrompt_AC.L2-3.1.5.c | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.5.c | Sample Response ]]
|-
| [d] access to security functions is authorized in accordance with the principle of least privilege. || [[ LLMPrompt_AC.L2-3.1.5.d | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.5.d | Sample Response ]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.6_Details | '''AC.L2-3.1.6''' ]] Use non-privileged accounts or roles when accessing nonsecurity functions. || [[ LLMPrompt_AC.L2-3.1.6 | Sample Prompt Template ]] || N/A
|-
| [a] nonsecurity functions are identified. || [[ LLMPrompt_AC.L2-3.1.6.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.6.a | Sample Response ]]
|-
| [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions. || [[ LLMPrompt_AC.L2-3.1.6.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.6.b | Sample Response ]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.1.7_Details | '''AC.L2-3.1.7''' ]] Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. || [[ LLMPrompt_AC.L2-3.1.7 | Sample Prompt Template ]] || N/A
|-
| [a] privileged functions are defined. || [[ LLMPrompt_AC.L2-3.1.7.a | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.7.a | Sample Response ]]
|-
| [b] non-privileged users are defined. || [[ LLMPrompt_AC.L2-3.1.7.b | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.7.b | Sample Response ]]
|-
| [c] non-privileged users are prevented from executing privileged functions. || [[ LLMPrompt_AC.L2-3.1.7.c | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.7.c | Sample Response ]]
|-
| [d] the execution of privileged functions is captured in audit logs. || [[ LLMPrompt_AC.L2-3.1.7.d | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.1.7.d | Sample Response ]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Limit unsuccessful logon attempts. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the means of limiting unsuccessful logon attempts is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the defined means of limiting unsuccessful logon attempts is implemented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Provide privacy and security notices consistent with applicable CUI rules. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] privacy and security notices are displayed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the period of inactivity after which the system initiates a session lock is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Terminate (automatically) a user session after a defined condition. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] conditions requiring a user session to terminate are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Monitor and control remote access sessions. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] remote access sessions are permitted. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the types of permitted remote access are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] remote access sessions are controlled. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] remote access sessions are monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Route remote access via managed access control points. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] managed access control points are identified and implemented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] remote access is routed through managed network access control points. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Authorize remote execution of privileged commands and remote access to security-relevant information. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] privileged commands authorized for remote execution are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] security-relevant information authorized to be accessed remotely is identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the execution of the identified privileged commands via remote access is authorized. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] access to the identified security-relevant information via remote access is authorized. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Authorize wireless access prior to allowing such connections. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] wireless access points are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] wireless access is authorized prior to allowing such connections. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Protect wireless access using authentication and encryption. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] wireless access to the system is protected using authentication. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] wireless access to the system is protected using encryption. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Control connection of mobile devices. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] mobile devices that process, store, or transmit CUI are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] mobile device connections are authorized. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] mobile device connections are monitored and logged. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Encrypt CUI on mobile devices and mobile computing platforms. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Verify and control/limit connections to and use of external information systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] connections to external systems are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the use of external systems is identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] connections to external systems are verified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] the use of external systems is verified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] connections to external systems are controlled/limited. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] the use of external systems is controlled/limited. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Limit use of portable storage devices on external systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the use of portable storage devices containing CUI on external systems is identified and documented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] limits on the use of portable storage devices containing CUI on external systems are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the use of portable storage devices containing CUI on external systems is limited as defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Control information posted or processed on publicly accessible information systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] individuals authorized to post or process information on publicly accessible systems are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] a review process is in place prior to posting of any content to publicly accessible systems. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] mechanisms are in place to remove and address improper posting of CUI. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] security risks associated with organizational activities involving CUI are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] policies, standards, and procedures related to the security of the system are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] information security-related duties, roles, and responsibilities are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] information security-related duties, roles, and responsibilities are assigned to designated personnel. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Provide security awareness training on recognizing and reporting potential indicators of insider threat. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] potential indicators associated with insider threats are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] audit records are created (generated). || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] audit records, once created, contain the defined content. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] retention requirements for audit records are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] audit records are retained as defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] audit records, once created, contain the defined content. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Review and update logged events. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a process for determining when to review logged events is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] event types being logged are reviewed in accordance with the defined review process. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] event types being logged are updated based on the review. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Alert in the event of an audit logging process failure. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] personnel or roles to be alerted in the event of an audit logging process failure are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] types of audit logging process failures for which alert will be generated are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] identified personnel or roles are alerted in the event of an audit logging process failure. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] defined audit record review, analysis, and reporting processes are correlated. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Provide audit record reduction and report generation to support on-demand analysis and reporting. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] an audit record reduction capability that supports on-demand analysis is provided. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] a report generation capability that supports on-demand reporting is provided. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] internal system clocks are used to generate time stamps for audit records. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] an authoritative source with which to compare and synchronize internal system clocks is specified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Protect audit information and audit logging tools from unauthorized access, modification, and deletion. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] audit information is protected from unauthorized access. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] audit information is protected from unauthorized modification. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] audit information is protected from unauthorized deletion. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] audit logging tools are protected from unauthorized access. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] audit logging tools are protected from unauthorized modification. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] audit logging tools are protected from unauthorized deletion. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Limit management of audit logging functionality to a subset of privileged users. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a subset of privileged users granted access to manage audit logging functionality is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] management of audit logging functionality is limited to the defined subset of privileged users. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.1_Details | '''CM.L2-3.4.1''' ]] Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. || [[ LLMPrompt_CM.L2-3.4.1 | Sample Prompt Template ]] || N/A
|-
| [a] a baseline configuration is established. || [[ LLMPrompt_CM.L2-3.4.1.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.a | Sample Response ]]
|-
| [b] the baseline configuration includes hardware, software, firmware, and documentation. || [[ LLMPrompt_CM.L2-3.4.1.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.b | Sample Response ]]
|-
| [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle. || [[ LLMPrompt_CM.L2-3.4.1.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.c | Sample Response ]]
|-
| [d] a system inventory is established. || [[ LLMPrompt_CM.L2-3.4.1.d | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.d | Sample Response ]]
|-
| [e] the system inventory includes hardware, software, firmware, and documentation. || [[ LLMPrompt_CM.L2-3.4.1.e | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.e | Sample Response ]]
|-
| [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle. || [[ LLMPrompt_CM.L2-3.4.1.f | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.1.f | Sample Response ]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.2_Details | '''CM.L2-3.4.2''' ]] Establish and enforce security configuration settings for information technology products employed in organizational systems. || [[ LLMPrompt_CM.L2-3.4.2 | Sample Prompt Template ]] || N/A
|-
| [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration. || [[ LLMPrompt_CM.L2-3.4.2.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.2.a | Sample Response ]]
|-
| [b] security configuration settings for information technology products employed in the system are enforced. || [[ LLMPrompt_CM.L2-3.4.2.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.2.b | Sample Response ]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.3_Details | '''CM.L2-3.4.3''' ]] Track, review, approve or disapprove, and log changes to organizational systems. || [[ LLMPrompt_CM.L2-3.4.3 | Sample Prompt Template ]] || N/A
|-
| [a] changes to the system are tracked. || [[ LLMPrompt_CM.L2-3.4.3.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.3.a | Sample Response ]]
|-
| [b] changes to the system are reviewed. || [[ LLMPrompt_CM.L2-3.4.3.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.3.b | Sample Response ]]
|-
| [c] changes to the system are approved or disapproved. || [[ LLMPrompt_CM.L2-3.4.3.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.3.c | Sample Response ]]
|-
| [d] changes to the system are logged. || [[ LLMPrompt_CM.L2-3.4.3.d | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.3.d | Sample Response ]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.4_Details | '''CM.L2-3.4.4''' ]] Analyze the security impact of changes prior to implementation. || [[ LLMPrompt_CM.L2-3.4.4 | Sample Prompt Template ]] || N/A
|-
| [a] the security impact of changes to the system is analyzed prior to implementation. || [[ LLMPrompt_CM.L2-3.4.4.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.4.a | Sample Response ]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.5_Details | '''CM.L2-3.4.5''' ]] Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. || [[ LLMPrompt_CM.L2-3.4.5 | Sample Prompt Template ]] || N/A
|-
| [a] physical access restrictions associated with changes to the system are defined. || [[ LLMPrompt_CM.L2-3.4.5.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.a | Sample Response ]]
|-
| [b] physical access restrictions associated with changes to the system are documented. || [[ LLMPrompt_CM.L2-3.4.5.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.b | Sample Response ]]
|-
| [c] physical access restrictions associated with changes to the system are approved. || [[ LLMPrompt_CM.L2-3.4.5.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.c | Sample Response ]]
|-
| [d] physical access restrictions associated with changes to the system are enforced. || [[ LLMPrompt_CM.L2-3.4.5.d | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.d | Sample Response ]]
|-
| [e] logical access restrictions associated with changes to the system are defined. || [[ LLMPrompt_CM.L2-3.4.5.e | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.e | Sample Response ]]
|-
| [f] logical access restrictions associated with changes to the system are documented. || [[ LLMPrompt_CM.L2-3.4.5.f | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.f | Sample Response ]]
|-
| [g] logical access restrictions associated with changes to the system are approved. || [[ LLMPrompt_CM.L2-3.4.5.g | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.g | Sample Response ]]
|-
| [h] logical access restrictions associated with changes to the system are enforced. || [[ LLMPrompt_CM.L2-3.4.5.h | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.5.h | Sample Response ]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.6_Details | '''CM.L2-3.4.6''' ]] Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. || [[ LLMPrompt_CM.L2-3.4.6 | Sample Prompt Template ]] || N/A
|-
| [a] essential system capabilities are defined based on the principle of least functionality. || [[ LLMPrompt_CM.L2-3.4.6.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.6.a | Sample Response ]]
|-
| [b] the system is configured to provide only the defined essential capabilities. || [[ LLMPrompt_CM.L2-3.4.6.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.6.b | Sample Response ]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.7_Details | '''CM.L2-3.4.7''' ]] Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. || [[ LLMPrompt_CM.L2-3.4.7 | Sample Prompt Template ]] || N/A
|-
| [a] essential programs are defined. || [[ LLMPrompt_CM.L2-3.4.7.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.a | Sample Response ]]
|-
| [b] the use of nonessential programs is defined. || [[ LLMPrompt_CM.L2-3.4.7.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.b | Sample Response ]]
|-
| [c] the use of nonessential programs is restricted, disabled, or prevented as defined. || [[ LLMPrompt_CM.L2-3.4.7.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.c | Sample Response ]]
|-
| [d] essential functions are defined. || [[ LLMPrompt_CM.L2-3.4.7.d | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.d | Sample Response ]]
|-
| [e] the use of nonessential functions is defined. || [[ LLMPrompt_CM.L2-3.4.7.e | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.e | Sample Response ]]
|-
| [f] the use of nonessential functions is restricted, disabled, or prevented as defined. || [[ LLMPrompt_CM.L2-3.4.7.f | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.f | Sample Response ]]
|-
| [g] essential ports are defined. || [[ LLMPrompt_CM.L2-3.4.7.g | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.g | Sample Response ]]
|-
| [h] the use of nonessential ports is defined. || [[ LLMPrompt_CM.L2-3.4.7.h | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.h | Sample Response ]]
|-
| [i] the use of nonessential ports is restricted, disabled, or prevented as defined. || [[ LLMPrompt_CM.L2-3.4.7.i | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.i | Sample Response ]]
|-
| [j] essential protocols are defined. || [[ LLMPrompt_CM.L2-3.4.7.j | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.j | Sample Response ]]
|-
| [k] the use of nonessential protocols is defined. || [[ LLMPrompt_CM.L2-3.4.7.k | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.k | Sample Response ]]
|-
| [l] the use of nonessential protocols is restricted, disabled, or prevented as defined. || [[ LLMPrompt_CM.L2-3.4.7.l | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.l | Sample Response ]]
|-
| [m] essential services are defined. || [[ LLMPrompt_CM.L2-3.4.7.m | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.m | Sample Response ]]
|-
| [n] the use of nonessential services is defined. || [[ LLMPrompt_CM.L2-3.4.7.n | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.n | Sample Response ]]
|-
| [o] the use of nonessential services is restricted, disabled, or prevented as defined. || [[ LLMPrompt_CM.L2-3.4.7.o | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.7.o | Sample Response ]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.8_Details | '''CM.L2-3.4.8''' ]] Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. || [[ LLMPrompt_CM.L2-3.4.8 | Sample Prompt Template ]] || N/A
|-
| [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified. || [[ LLMPrompt_CM.L2-3.4.8.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.8.a | Sample Response ]]
|-
| [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified. || [[ LLMPrompt_CM.L2-3.4.8.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.8.b | Sample Response ]]
|-
| [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified. || [[ LLMPrompt_CM.L2-3.4.8.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.8.c | Sample Response ]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_CM.L2-3.4.9_Details | '''CM.L2-3.4.9''' ]] Control and monitor user-installed software. || [[ LLMPrompt_CM.L2-3.4.9 | Sample Prompt Template ]] || N/A
|-
| [a] a policy for controlling the installation of software by users is established. || [[ LLMPrompt_CM.L2-3.4.9.a | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.9.a | Sample Response ]]
|-
| [b] installation of software by users is controlled based on the established policy. || [[ LLMPrompt_CM.L2-3.4.9.b | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.9.b | Sample Response ]]
|-
| [c] installation of software by users is monitored. || [[ LLMPrompt_CM.L2-3.4.9.c | Sample Prompt ]] || [[ LLMResponse_CM.L2-3.4.9.c | Sample Response ]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Identify information system users, processes acting on behalf of users, or devices. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] system users are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] processes acting on behalf of users are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] devices accessing the system are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the identity of each user is authenticated or verified as a prerequisite to system access. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] privileged accounts are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] multifactor authentication is implemented for local access to privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] multifactor authentication is implemented for network access to privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] multifactor authentication is implemented for network access to non-privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Prevent reuse of identifiers for a defined period. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a period within which identifiers cannot be reused is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] reuse of identifiers is prevented within the defined period. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Disable identifiers after a defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a period of inactivity after which an identifier is disabled is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] identifiers are disabled after the defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Enforce a minimum password complexity and change of characters when new passwords are created. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] password complexity requirements are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] password change of character requirements are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] minimum password complexity requirements as defined are enforced when new passwords are created. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] minimum password change of character requirements as defined are enforced when new passwords are created. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Prohibit password reuse for a specified number of generations. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the number of generations during which a password cannot be reused is specified and [b] reuse of passwords is prohibited during the specified number of generations. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Allow temporary password use for system logons with an immediate change to a permanent password. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] an immediate change to a permanent password is required when a temporary password is used for system logon. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Store and transmit only cryptographically-protected passwords. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] passwords are cryptographically protected in storage. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] passwords are cryptographically protected in transit. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Obscure feedback of authentication information. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] authentication information is obscured during the authentication process. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] an operational incident-handling capability is established. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the operational incident-handling capability includes preparation. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the operational incident-handling capability includes detection. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] the operational incident-handling capability includes analysis. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] the operational incident-handling capability includes containment. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] the operational incident-handling capability includes recovery. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] incidents are tracked. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] incidents are documented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] authorities to whom incidents are to be reported are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] organizational officials to whom incidents are to be reported are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] identified authorities are notified of incidents. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] identified organizational officials are notified of incidents. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Test the organizational incident response capability. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the incident response capability is tested. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.1_Details | '''MA.L2-3.7.1''' ]] Perform maintenance on organizational systems. || [[ LLMPrompt_MA.L2-3.7.1 | Sample Prompt Template ]] || N/A
|-
| [a] system maintenance is performed. || [[ LLMPrompt_MA.L2-3.7.1.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.1.a | Sample Response ]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.2_Details | '''MA.L2-3.7.2''' ]] Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. || [[ LLMPrompt_MA.L2-3.7.2 | Sample Prompt Template ]] || N/A
|-
| [a] tools used to conduct system maintenance are controlled. || [[ LLMPrompt_MA.L2-3.7.2.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.2.a | Sample Response ]]
|-
| [b] techniques used to conduct system maintenance are controlled. || [[ LLMPrompt_MA.L2-3.7.2.b | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.2.b | Sample Response ]]
|-
| [c] mechanisms used to conduct system maintenance are controlled. || [[ LLMPrompt_MA.L2-3.7.2.c | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.2.c | Sample Response ]]
|-
| [d] personnel used to conduct system maintenance are controlled. || [[ LLMPrompt_MA.L2-3.7.2.d | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.2.d | Sample Response ]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.3_Details | '''MA.L2-3.7.3''' ]] Ensure equipment removed for off-site maintenance is sanitized of any CUI. || [[ LLMPrompt_MA.L2-3.7.3 | Sample Prompt Template ]] || N/A
|-
| [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI. || [[ LLMPrompt_MA.L2-3.7.3.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.3.a | Sample Response ]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.4_Details | '''MA.L2-3.7.4''' ]] Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. || [[ LLMPrompt_MA.L2-3.7.4 | Sample Prompt Template ]] || N/A
|-
| [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI. || [[ LLMPrompt_MA.L2-3.7.4.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.4.a | Sample Response ]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.5_Details | '''MA.L2-3.7.5''' ]] Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. || [[ LLMPrompt_MA.L2-3.7.5 | Sample Prompt Template ]] || N/A
|-
| [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections. || [[ LLMPrompt_MA.L2-3.7.5.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.5.a | Sample Response ]]
|-
| [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete. || [[ LLMPrompt_MA.L2-3.7.5.b | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.5.b | Sample Response ]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MA.L2-3.7.6_Details | '''MA.L2-3.7.6''' ]] Supervise the maintenance activities of maintenance personnel without required access authorization. || [[ LLMPrompt_MA.L2-3.7.6 | Sample Prompt Template ]] || N/A
|-
| [a] maintenance personnel without required access authorization are supervised during maintenance activities. || [[ LLMPrompt_MA.L2-3.7.6.a | Sample Prompt ]] || [[ LLMResponse_MA.L2-3.7.6.a | Sample Response ]]
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.1_Details | '''MP.L2-3.8.1''' ]] Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. || [[ LLMPrompt_MP.L2-3.8.1 | Sample Prompt Template ]] || N/A
|-
| [a] paper media containing CUI is physically controlled. || [[ LLMPrompt_MP.L2-3.8.1.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.1.a | Sample Response ]]
|-
| [b] digital media containing CUI is physically controlled. || [[ LLMPrompt_MP.L2-3.8.1.b | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.1.b | Sample Response ]]
|-
| [c] paper media containing CUI is securely stored. || [[ LLMPrompt_MP.L2-3.8.1.c | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.1.c | Sample Response ]]
|-
| [d] digital media containing CUI is securely stored. || [[ LLMPrompt_MP.L2-3.8.1.d | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.1.d | Sample Response ]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.2_Details | '''MP.L2-3.8.2''' ]] Limit access to CUI on system media to authorized users. || [[ LLMPrompt_MP.L2-3.8.2 | Sample Prompt Template ]] || N/A
|-
| [a] access to CUI on system media is limited to authorized users. || [[ LLMPrompt_MP.L2-3.8.2.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.2.a | Sample Response ]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.3_Details | '''MP.L2-3.8.3''' ]] Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse. || [[ LLMPrompt_MP.L2-3.8.3 | Sample Prompt Template ]] || N/A
|-
| [a] system media containing CUI is sanitized or destroyed before disposal. || [[ LLMPrompt_MP.L2-3.8.3.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.3.a | Sample Response ]]
|-
| [b] system media containing CUI is sanitized before it is released for reuse. || [[ LLMPrompt_MP.L2-3.8.3.b | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.3.b | Sample Response ]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.4_Details | '''MP.L2-3.8.4''' ]] Mark media with necessary CUI markings and distribution limitations. || [[ LLMPrompt_MP.L2-3.8.4 | Sample Prompt Template ]] || N/A
|-
| [a] media containing CUI is marked with applicable CUI markings. || [[ LLMPrompt_MP.L2-3.8.4.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.4.a | Sample Response ]]
|-
| [b] media containing CUI is marked with distribution limitations. || [[ LLMPrompt_MP.L2-3.8.4.b | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.4.b | Sample Response ]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.5_Details | '''MP.L2-3.8.5''' ]] Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. || [[ LLMPrompt_MP.L2-3.8.5 | Sample Prompt Template ]] || N/A
|-
| [a] access to media containing CUI is controlled. || [[ LLMPrompt_MP.L2-3.8.5.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.5.a | Sample Response ]]
|-
| [b] accountability for media containing CUI is maintained during transport outside of controlled areas. || [[ LLMPrompt_MP.L2-3.8.5.b | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.5.b | Sample Response ]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.6_Details | '''MP.L2-3.8.6''' ]] Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. || [[ LLMPrompt_MP.L2-3.8.6 | Sample Prompt Template ]] || N/A
|-
| [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards. || [[ LLMPrompt_MP.L2-3.8.6.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.6.a | Sample Response ]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.7_Details | '''MP.L2-3.8.7''' ]] Control the use of removable media on system components. || [[ LLMPrompt_MP.L2-3.8.7 | Sample Prompt Template ]] || N/A
|-
| [a] the use of removable media on system components is controlled. || [[ LLMPrompt_MP.L2-3.8.7.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.7.a | Sample Response ]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.8_Details | '''MP.L2-3.8.8''' ]] Prohibit the use of portable storage devices when such devices have no identifiable owner. || [[ LLMPrompt_MP.L2-3.8.8 | Sample Prompt Template ]] || N/A
|-
| [a] the use of portable storage devices is prohibited when such devices have no identifiable owner. || [[ LLMPrompt_MP.L2-3.8.8.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.8.a | Sample Response ]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_MP.L2-3.8.9_Details | '''MP.L2-3.8.9''' ]] Protect the confidentiality of backup CUI at storage locations. || [[ LLMPrompt_MP.L2-3.8.9 | Sample Prompt Template ]] || N/A
|-
| [a] the confidentiality of backup CUI is protected at storage locations. || [[ LLMPrompt_MP.L2-3.8.9.a | Sample Prompt ]] || [[ LLMResponse_MP.L2-3.8.9.a | Sample Response ]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_PS.L2-3.9.1_Details | '''PS.L2-3.9.1''' ]] Screen individuals prior to authorizing access to organizational systems containing CUI. || [[ LLMPrompt_PS.L2-3.9.1 | Sample Prompt Template ]] || N/A
|-
| [a] individuals are screened prior to authorizing access to organizational systems containing CUI. || [[ LLMPrompt_PS.L2-3.9.1.a | Sample Prompt ]] || [[ LLMResponse_PS.L2-3.9.1.a | Sample Response ]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_PS.L2-3.9.2_Details | '''PS.L2-3.9.2''' ]] Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. || [[ LLMPrompt_PS.L2-3.9.2 | Sample Prompt Template ]] || N/A
|-
| [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established. || [[ LLMPrompt_PS.L2-3.9.2.a | Sample Prompt ]] || [[ LLMResponse_PS.L2-3.9.2.a | Sample Response ]]
|-
| [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer. || [[ LLMPrompt_PS.L2-3.9.2.b | Sample Prompt ]] || [[ LLMResponse_PS.L2-3.9.2.b | Sample Response ]]
|-
| [c] the system is protected during and after personnel transfer actions. || [[ LLMPrompt_PS.L2-3.9.2.c | Sample Prompt ]] || [[ LLMResponse_PS.L2-3.9.2.c | Sample Response ]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] authorized individuals allowed physical access are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] physical access to organizational systems is limited to authorized individuals. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] physical access to equipment is limited to authorized individuals. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] physical access to operating environments is limited to authorized. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Protect and monitor the physical facility and support infrastructure for organizational systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the physical facility where organizational systems reside is protected. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the support infrastructure for organizational systems is protected. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the physical facility where organizational systems reside is monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] the support infrastructure for organizational systems is monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Escort visitors and monitor visitor activity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] visitors are escorted. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] visitor activity is monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Maintain audit logs of physical access. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] audit logs of physical access are maintained. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Control and manage physical access devices. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] physical access devices are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] physical access devices are controlled. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] physical access devices are managed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Enforce safeguarding measures for CUI at alternate work sites. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] safeguarding measures for CUI are defined for alternate work sites. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] safeguarding measures for CUI are enforced for alternate work sites. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] vulnerability scans are performed on organizational systems with the defined frequency. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] vulnerability scans are performed on applications with the defined frequency. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] vulnerability scans are performed on applications when new vulnerabilities are
identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Remediate vulnerabilities in accordance with risk assessments. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] vulnerabilities are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] vulnerabilities are remediated in accordance with risk assessments. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the frequency of security control assessments is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ====
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a system security plan is developed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] the system boundary is described and documented in the system security plan. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the system environment of operation is described and documented in the system security plan. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] the security requirements identified and approved by the designated authority as non-applicable are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] the method of security requirement implementation is described and documented in the system security plan. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] the relationship with or connection to other systems is described and documented in the system security plan. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [g] the frequency to update the system security plan is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [h] system security plan is updated with the defined frequency. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the external system boundary is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] key internal system boundaries are defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] communications are monitored at the external system boundary. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] communications are monitored at key internal boundaries. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] communications are controlled at the external system boundary. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] communications are controlled at key internal boundaries. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [g] communications are protected at the external system boundary. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [h] communications are protected at key internal boundaries. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] architectural designs that promote effective information security are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] software development techniques that promote effective information security are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] systems engineering principles that promote effective information security are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] identified architectural designs that promote effective information security are employed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] identified software development techniques that promote effective information security are employed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] identified systems engineering principles that promote effective information security are employed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Separate user functionality from system management functionality. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] user functionality is identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] system management functionality is identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] user functionality is separated from system management functionality. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Prevent unauthorized and unintended information transfer via shared system resources. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] unauthorized and unintended information transfer via shared system resources is prevented. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] publicly accessible system components are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] network communications traffic is denied by default. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] network communications traffic is allowed by exception. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling). || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] a period of inactivity to terminate network connections associated with communications sessions is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] network connections associated with communications sessions are terminated at the end of the sessions. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] network connections associated with communications sessions are terminated after the defined period of inactivity. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Establish and manage cryptographic keys for cryptography employed in organizational systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] cryptographic keys are established whenever cryptography is employed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] cryptographic keys are managed whenever cryptography is employed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] collaborative computing devices are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] collaborative computing devices provide indication to users of devices in use. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] remote activation of collaborative computing devices is prohibited. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Control and monitor the use of mobile code. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] use of mobile code is controlled. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] use of mobile code is monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] use of Voice over Internet Protocol (VoIP) technologies is controlled. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] use of Voice over Internet Protocol (VoIP) technologies is monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Protect the authenticity of communications sessions. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the authenticity of communications sessions is protected. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Protect the confidentiality of CUI at rest. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the confidentiality of CUI at rest is protected. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Identify, report, and correct information and information system flaws in a timely manner. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the time within which to identify system flaws is specified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] system flaws are identified within the specified time frame. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] the time within which to report system flaws is specified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [d] system flaws are reported within the specified time frame. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [e] the time within which to correct system flaws is specified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [f] system flaws are corrected within the specified time frame. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Provide protection from malicious code at appropriate locations within organizational information systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] designated locations for malicious code protection are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] protection from malicious code at designated locations is provided. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Monitor system security alerts and advisories and take action in response. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] response actions to system security alerts and advisories are identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] system security alerts and advisories are monitored. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] actions in response to system security alerts and advisories are taken. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Update malicious code protection mechanisms when new releases are available. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] malicious code protection mechanisms are updated when new releases are available. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the frequency for malicious code scans is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] malicious code scans are performed with the defined frequency. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] the system is monitored to detect attacks and indicators of potential attacks. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
! style="width: 70%"| '''Practice and Assessment Objectives'''
! style="width: 15%"| '''LLM Prompt'''
! style="width: 15%"| '''LLM Response'''
|-
| [[ Practice_AC.L2-3.x.1_Details | '''AC.L2-3.x.1''' ]] Identify unauthorized use of organizational systems. || [[ LLMPrompt_AC.L2-3.x.1 | Sample Prompt Template ]] || N/A
|-
| [a] authorized use of the system is defined. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
| [b] unauthorized use of the system is identified. || [[ LLMPrompt_AC.L2-3.x.1.e | Sample Prompt ]] || [[ LLMResponse_AC.L2-3.x.1.e | Sample Response ]]
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

DoD Assessment Methodology

2026-03-02T01:31:29Z

David:

'''Source of Reference: The [https://www.acq.osd.mil/asda/dpc/cp/cyber/docs/safeguarding/NIST-SP-800-171-Assessment-Methodology-Version-1.2.1-6.24.2020.pdf NIST SP 800-171 DoD Assessment Methodology Version 1.2.1, June 2020] from the [https://www.acq.osd.mil/asda/dpc/cp/cyber/safeguarding.html#nistSP800171 U.S. Department of Defense Website]'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== Section 5. NIST SP 800-171 DoD Assessment Scoring Methodology ==

[a] This scoring methodology is designed to provide an objective assessment of a contractor’s NIST SP 800-171 implementation status. With the exception of requirements for which the scoring of partial implementation is built-in (e.g., multifactor authentication, security requirement 3.5.3) the methodology is not designed to credit partial implementation.

[b] Conduct of the ''NIST SP 800-171 DoD Assessment'' will result in a score reflecting the net effect of security requirements not yet implemented. If all security requirements are implemented, a contractor is awarded a score of 110, consistent with the total number of NIST SP 800-171 security requirements. For each security requirement not met, the associated value is subtracted from 110. The score of 110 is reduced by each requirement not implemented, which may result in a negative score.

[c] While NIST SP 800-171 does not prioritize security requirements, certain requirements have more impact on the security of the network and its data than others. This scoring methodology incorporates this concept by weighting each security requirement based on the impact to the information system and the DoD CUI created on or transiting through that system, when that requirement is not implemented.

[d] Weighted requirements include all of the fundamental NIST SP 800-171 ‘Basic Security Requirements’ - high-level requirements which, if not implemented, render ineffective the more numerous ‘Derived Security Requirements’; and a subset of the ‘Derived Security Requirements’- requirements that supplement the Basic Security
Requirements - which, if not implemented, would allow for exploitation of the network and its information.
# For security requirements that, if not implemented, could lead to significant exploitation of the network, or exfiltration of DoD CUI, 5 points are subtracted from the score of 110. For example, failure to limit system access to authorized users (Basic Security Requirement 3.1.1) renders all the other Access Control requirements ineffective, allowing easy exploitation of the network; failure to control the use of removable media on system components (Derived Security Requirement 3.8.7) could result in massive exfiltration of CUI and introduction of malware.
## Basic Security Requirements with a value of 5 points include 3.1.1, 3.1.2, 3.2.1, 3.2.2, 3.3.1, 3.4.1, 3.4.2, 3.5.1, 3.5.2, 3.6.1, 3.6.2, 3.7.2, 3.8.3, 3.9.2, 3.10.1, 3.10.2, 3.12.1, 3.12.3, 3.13.1, 3.13.2, 3.14.1, 3.14.2, and 3.14.3.
## Derived Security Requirements with a value of 5 points include 3.1.12, 3.1.13, 3.1.16, 3.1.17, 3.1.18, 3.3.5, 3.4.5, 3.4.6, 3.4.7, 3.4.8, 3.5.10, 3.7.5, 3.8.7, 3.11.2, 3.13.5, 3.13.6, 3.13.15, 3.14.4, and 3.14.6.
# For Basic and Derived Security Requirements that, if not implemented, have a specific and confined effect on the security of the network and its data, 3 points are subtracted from the score of 110. For example, failure to limit access to CUI on system media to authorized users (Security Requirement 3.8.2) or failure to encrypt CUI stored on a mobile device (Security Requirement 3.1.19), put the CUI stored on the system media or mobile device at risk, but not the CUI stored on the network itself.
## Basic Security Requirements with a value of 3 points include 3.3.2, 3.7.1, 3.8.1, 3.8.2, 3.9.1, 3.11.1, and 3.12.2.
## Derived Security Requirements with a value of 3 points include 3.1.5, 3.1.19, 3.7.4, 3.8.8, 3.13.8, 3.14.5, and 3.14.7.
# All remaining Derived Security Requirements, if not implemented, have a limited or indirect effect on the security of the network and its data. For these, 1 point is subtracted from the score of 110. For example, failing to prevent reuse of identifiers for a defined period (Security Requirement 3.5.5) could allow a user access to CUI to which they were not approved.

[e] Two Derived Security Requirements can be partially effective even if not completely or properly implemented, and the points deducted should be adjusted depending on how the security requirement is implemented.
# Multi-factor authentication (MFA) (Security Requirement 3.5.3) is typically implemented first for remote and privileged users (since these users are both limited in number and more critical) and then for the general user, so 3 points are subtracted from the score of 110 if MFA is implemented only for remote and privileged users; 5 points are subtracted from the score of 110 if MFA is not implemented for any users.
# FIPS validated encryption (Security Requirement 3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS validated, 3 points are subtracted from the score of 110; if encryption is not employed, 5 points are subtracted from the score of 110.

[f] Although not common, future revisions of NIST SP 800-171 may add, delete or substantively revise security requirements. When this occurs, a value will be assigned to any new or modified requirements in accordance with this scoring methodology.

[g] The contractor must have a system security plan (Basic Security Requirement 3.12.4) in place to describe each covered contractor information system, and a plan of action (Basic Security Requirement 3.12.2) in place for each unimplemented security requirement to describe how and when the security requirement will be met.
# Since the NIST SP 800-171 DoD Assessment scoring methodology is based on the review of a system security plan describing how the security requirements are met, it is not possible to conduct the assessment if the information is not available. The absence of a system security plan would result in a finding that ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.’
# Plans of action addressing unimplemented security requirements are not a substitute for a completed requirement. Security requirements not implemented, whether a plan of action is in place or not, will be assessed as ‘not implemented.’ For example, if the initial roll-out of 3.5.3, multifactor authentication, is only 75% complete, and there is a plan of action still being implemented, 3.5.3 will be considered ‘not implemented’, as the requirement has not been fully implemented.
# A lack of plan of action for unimplemented security requirements will result in Security Requirement 3.12.2 being assessed as ‘not implemented.’

[h] Temporary deficiencies and/or isolated enduring exceptions which occur during initial implementation, or arise after implementation, are to be expected in most complex
environments.
# Temporary deficiencies that are appropriately addressed in plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) should be assessed as ‘implemented.’ For example, when a plan of action addresses a ‘temporary deficiency’ that arises after implementation (e.g., 3.13.11, employ FIPS validated cryptography, had been implemented, but subsequently a patch invalidated the FIPS validation of a particular cryptographic module), the requirement will be scored ‘as implemented.’ A ‘temporary deficiency’ may also arise during initial implementation of a NIST SP 800-171 requirement if, during roll-out, specific issues with certain equipment is discovered that has to be separately addressed (e.g., certain specific hardware or software unexpectedly needs to be changed for the requirement to be successfully applied). If the implementation roll-out has otherwise been completed, this ‘temporary deficiency’ plan of action would be considered, and the requirement scored ‘as implemented.’ There is no standard duration for which a ‘temporary deficiency’ may be active. It is what is reasonable, which would take into consideration the availability of the solution, the cost and time to implement, the overall risk and whether any mitigations are applied in the interim. Generally, deficiencies should be resolved as soon as is reasonably possible.
# Isolated enduring exceptions encountered during implementation, such as unique equipment or environments (e.g., specialized manufacturing equipment or a unique laboratory environment) may prevent the implementation of certain security requirements. Isolated enduring exceptions are typically not suitable to address in plans of action, but when described, along with any mitigations, in the system security plan such exceptions should be assessed as ‘implemented.’

[i] For certain requirements, questions often arise on whether or not they are actually implemented. These situations are addressed below:
# Security Requirements 3.1.12, 3.1.16, 3.1.18: Companies commonly do not allow remote access, wireless access or connection of mobile devices and may indicate these requirements as ‘Not Applicable’ or ‘Not Implemented’ in the system security plan. The evaluator should not deduct points in such cases. However, if the company disallows use of remote, wireless, or mobile access, they should also have a policy and procedure in place to insure these capabilities are not enabled inadvertently. This should be discussed as part of the Medium Level assessment, and if such policy and procedures are not in place a point should be assessed.
# Security Requirement 3.13.8: When implementing this requirement, encryption, though preferred, is not required if using common-carrier provided Multiprotocol Label Switching (MPLS), as the MPLS separation provides sufficient protection without encryption.
# Security Requirement 3.13.11: Cryptography used to protect the confidentiality of CUI must be FIPS-validated, which means the cryptographic module has to have been tested and validated to meet FIPS 140-1 or-2 requirements. Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient - the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140. Note however, that this is required when encryption is required for protection, which is typically external to the contractor's covered information system (assuming the system meets NIST SP 800-171). Cryptography used for other purposes within the protected information system need not be FIPS validated. When required, if encryption is not employed (FIPS validated or otherwise), 5 points are subtracted from the score of 110. If encryption is employed, but is not FIPS validated, 3 points are subtracted from the score of 110. Isolated use of non-FIPS validated cryptography, with an associated Plan of Action, should be treated as a temporary deficiency and assessed as ‘implemented.’

[j] If a contractor received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective in accordance with DFARS 252.204-7008 or 7012, the DoD CIO assessment should be included in the Contractor’s system security plan. Implemented security measures adjudicated by the DoD CIO as equally effective, and security requirements approved by the DoD CIO as ‘not applicable,’ will be assessed as ‘implemented.’ Once DOD CIO assessments approving “not applicable” requirements or “alternative security measures” are included in the Contractor's system security plan, the contractor does not need to submit that documentation for every current contract with the DFARS 252.204-7012 clause unless specifically requested to do so by the contracting officer. When completing the Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment Results Format, the contractor shall score any security requirements for which an assessment of “not applicable” or “alternative security measures” was previously approved by DoD CIO as ‘implemented’.

[k] A template illustrating the application of this scoring methodology is provided at Annex A of this document.

[l] DoD will provide medium and high assessment results to the Contractor and offer the opportunity for rebuttal and adjudication of assessment results. Upon completion of each assessment, the assessed contractor has 14 business days to provide additional information to the assessment team, to demonstrate that they meet any security requirements not observed by the assessment team or to rebut the findings that may be of question.

== Annex A - NIST SP 800-171 DoD Assessment Scoring Template ==
* The following template illustrates the scoring methodology described in Section 5. If all requirements are met, a score of 110 is awarded. For each requirement not met, the associated value is subtracted from 110. Consistency results from the fact that the assessments are based on what is not yet implemented, or document that all requirements have been met.
* It is important to note an assessment is about the extent to which the company has implemented the requirements. It is not a value judgement about the specific approach to implementing – in other words, all solutions that meet the requirements are acceptable. This is not an assessment of one solution compared to another.
* Scoring for Basic, Medium, and High NIST SP 800-171 DoD Assessments is the same.
* While NIST does not prioritize requirements in terms of impact, certain requirements do have more impact than others. In this scoring methodology security requirements are weighted based on their effect on the information system and DoD CUI created on or transiting that system.

{| class="wikitable" style="margin:auto"
|-
! style="width: 10%;" | Practice Number
! style="width: 60%;" | Practice Requirement
! style="width: 5%;" | Value
! style="width: 25%;" | Comment
|-
| [[Practice_AC.L2-3.1.1_Details | 3.1.1]]* || Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). || 5 ||
|-
| [[Practice_AC.L2-3.1.2_Details | 3.1.2]]* || Limit system access to the types of transactions and functions that authorized users are permitted to execute. || 5 ||
|-
| [[Practice_AC.L2-3.1.3_Details | 3.1.3]] || Control the flow of CUI in accordance with approved authorizations. || 1 ||
|-
| [[ Practice_AC.L2-3.1.4_Details | 3.1.4]] || Separate the duties of individuals to reduce the risk of malevolent activity without collusion. || 1 ||
|-
| [[ Practice_AC.L2-3.1.5_Details | 3.1.5]] || Employ the principle of least privilege, including for specific security functions and privileged accounts. || 3 ||
|-
| [[Practice_AC.L2-3.1.6_Details | 3.1.6]] || Use non-privileged accounts or roles when accessing non-security functions. || 1 ||
|-
| [[Practice_AC.L2-3.1.7_Details | 3.1.7]] || Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. || 1 ||
|-
| [[Practice_AC.L2-3.1.8_Details | 3.1.8]] || Limit unsuccessful logon attempts. || 1 ||
|-
| [[Practice_AC.L2-3.1.9_Details | 3.1.9]] || Provide privacy and security notices consistent with applicable CUI rules. || 1 ||
|-
| [[Practice_AC.L2-3.1.10_Details | 3.1.10]] || Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. || 1 ||
|-
| [[Practice_AC.L2-3.1.11_Details | 3.1.11]] || Terminate (automatically) a user session after a defined condition. || 1 ||
|-
| [[Practice_AC.L2-3.1.12_Details | 3.1.12]] || Monitor and control remote access sessions. || 5 || Do not subtract points if remote access not permitted
|-
| [[Practice_AC.L2-3.1.13_Details | 3.1.13]] || Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. || 5 || Do not subtract points if remote access not permitted
|-
| [[Practice_AC.L2-3.1.14_Details | 3.1.14]] || Route remote access via managed access control points. || 1 ||
|-
| [[Practice_AC.L2-3.1.15_Details | 3.1.15]] || Authorize remote execution of privileged commands and remote access to security-relevant information. || 1 ||
|-
| [[Practice_AC.L2-3.1.16_Details | 3.1.16]] || Authorize wireless access prior to allowing such connections. || 5 || Do not subtract points if wireless access not permitted
|-
| [[Practice_AC.L2-3.1.17_Details | 3.1.17]] || Protect wireless access using authentication and encryption. || 5 || Do not subtract points if wireless access not permitted
|-
| [[Practice_AC.L2-3.1.18_Details | 3.1.18]] || Control connection of mobile devices. || 5 || Do not subtract points if connection of mobile devices is not permitted
|-
| [[Practice_AC.L2-3.1.19_Details | 3.1.19]] || Encrypt CUI on mobile devices and mobile computing platforms || 3 || Exposure limited to CUI on mobile platform
|-
| [[Practice_AC.L2-3.1.20_Details | 3.1.20]]* || Verify and control/limit connections to and use of external systems. || 1 ||
|-
| [[Practice_AC.L2-3.1.21_Details | 3.1.21]] || Limit use of portable storage devices on external systems. || 1 ||
|-
| [[Practice_AC.L2-3.1.22_Details | 3.1.22]]* || Control CUI posted or processed on publicly accessible systems. || 1 ||
|-
| [[Practice_AT.L2-3.2.1_Details | 3.2.1]] || Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems. || 5 ||
|-
| [[Practice_AT.L2-3.2.2_Details | 3.2.2]] || Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. || 5 ||
|-
| [[Practice_AT.L2-3.2.3_Details | 3.2.3]] || Provide security awareness training on recognizing and reporting potential indicators of insider threat. || 1 ||
|-
| [[Practice_AU.L2-3.3.1_Details | 3.3.1]] || Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. || 5 ||
|-
| [[Practice_AU.L2-3.3.2_Details | 3.3.2]] || Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. || 3 ||
|-
| [[Practice_AU.L2-3.3.3_Details | 3.3.3]] || Review and update logged events. || 1 ||
|-
| [[Practice_AU.L2-3.3.4_Details | 3.3.4]] || Alert in the event of an audit logging process failure. || 1 ||
|-
| [[Practice_AU.L2-3.3.5_Details | 3.3.5]] || Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. || 5 ||
|-
| [[Practice_AU.L2-3.3.6_Details | 3.3.6]] || Provide audit record reduction and report generation to support on-demand analysis and reporting. || 1 ||
|-
| [[Practice_AU.L2-3.3.7_Details | 3.3.7]] || Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. || 1 ||
|-
| [[Practice_AU.L2-3.3.8_Details | 3.3.8]] || Protect audit information and audit logging tools from unauthorized access, modification, and deletion. || 1 ||
|-
| [[Practice_AU.L2-3.3.9_Details | 3.3.9]] || Limit management of audit logging functionality to a subset of privileged users. || 1 ||
|-
| [[Practice_CM.L2-3.4.1_Details | 3.4.1]] || Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. || 5 ||
|-
| [[Practice_CM.L2-3.4.2_Details | 3.4.2]] || Establish and enforce security configuration settings for information technology products employed in organizational systems. || 5 ||
|-
| [[Practice_CM.L2-3.4.3_Details | 3.4.3]] || Track, review, approve or disapprove, and log changes to organizational systems. || 1 ||
|-
| [[Practice_CM.L2-3.4.4_Details | 3.4.4]] || Analyze the security impact of changes prior to implementation. || 1 ||
|-
| [[Practice_CM.L2-3.4.5_Details | 3.4.5]] || Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. || 5 ||
|-
| [[Practice_CM.L2-3.4.6_Details | 3.4.6]] || Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. || 5 ||
|-
| [[Practice_CM.L2-3.4.7_Details | 3.4.7]] || Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. || 5 ||
|-
| [[Practice_CM.L2-3.4.8_Details | 3.4.8]] || Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. || 5 ||
|-
| [[Practice_CM.L2-3.4.9_Details | 3.4.9]] || Control and monitor user-installed software. || 1 ||
|-
| [[Practice_IA.L1-3.5.1_Details | 3.5.1]]* || Identify system users, processes acting on behalf of users, and devices. || 5 ||
|-
| [[Practice_IA.L1-3.5.2_Details | 3.5.2]]* || Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. || 5 ||
|-
| [[Practice_IA.L2-3.5.3_Details | 3.5.3]] || Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts. || 5/3 || Subtract 5 points if MFA not implemented. Subtract 3 points if implemented for remote and privileged users, but not the general user
|-
| [[Practice_IA.L2-3.5.4_Details | 3.5.4]] || Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. || 1 ||
|-
| [[Practice_IA.L2-3.5.5_Details | 3.5.5]] || Prevent reuse of identifiers for a defined period. || 1 ||
|-
| [[Practice_IA.L2-3.5.6_Details | 3.5.6]] || Disable identifiers after a defined period of inactivity. || 1 ||
|-
| [[Practice_IA.L2-3.5.7_Details | 3.5.7]] || Enforce a minimum password complexity and change of characters when new passwords are created. || 1 ||
|-
| [[Practice_IA.L2-3.5.8_Details | 3.5.8]] || Prohibit password reuse for a specified number of generations. || 1 ||
|-
| [[Practice_IA.L2-3.5.9_Details | 3.5.9]] || Allow temporary password use for system logons with an immediate change to a permanent password. || 1 ||
|-
| [[Practice_IA.L2-3.5.10_Details | 3.5.10]] || Store and transmit only cryptographically-protected passwords. || 5 || Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords
|-
| [[Practice_IA.L2-3.5.11_Details | 3.5.11]] || Obscure feedback of authentication information. || 1 ||
|-
| [[Practice_IR.L2-3.6.1_Details | 3.6.1]] || Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. || 5 ||
|-
| [[Practice_IR.L2-3.6.2_Details | 3.6.2]] || Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. || 5 ||
|-
| [[Practice_IR.L2-3.6.3_Details | 3.6.3]] || Test the organizational incident response capability. || 1 ||
|-
| [[Practice_MA.L2-3.7.1_Details | 3.7.1]] || Perform maintenance on organizational systems. || 3 ||
|-
| [[Practice_MA.L2-3.7.2_Details | 3.7.2]] || Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. || 5 ||
|-
| [[Practice_MA.L2-3.7.3_Details | 3.7.3]] || Ensure equipment removed for off-site maintenance is sanitized of any CUI. || 1 ||
|-
| [[Practice_MA.L2-3.7.4_Details | 3.7.4]] || Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. || 3 ||
|-
| [[Practice_MA.L2-3.7.5_Details | 3.7.5]] || Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. || 5 ||
|-
| [[Practice_MA.L2-3.7.6_Details | 3.7.6]] || Supervise the maintenance activities of maintenance personnel without required access authorization. || 1 ||
|-
| [[Practice_MP.L2-3.8.1_Details | 3.8.1]] || Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. || 3 || Exposure limited to CUI on media
|-
| [[Practice_MP.L2-3.8.2_Details | 3.8.2]] || Limit access to CUI on system media to authorized users. || 3 || Exposure limited to CUI on media
|-
| [[Practice_MP.L1-3.8.3_Details | 3.8.3]]* || Sanitize or destroy system media containing CUI before disposal or release for reuse. || 5 || While exposure limited to CUI on media, failure to sanitize can result in continual exposure of CUI
|-
| [[Practice_MP.L2-3.8.4_Details | 3.8.4]] || Mark media with necessary CUI markings and distribution limitations. || 1 ||
|-
| [[Practice_MP.L2-3.8.5_Details | 3.8.5]] || Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. || 1 ||
|-
| [[Practice_MP.L2-3.8.6_Details | 3.8.6]] || Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. || 1 ||
|-
| [[Practice_MP.L2-3.8.7_Details | 3.8.7]] || Control the use of removable media on system components. || 5 ||
|-
| [[Practice_MP.L2-3.8.8_Details | 3.8.8]] || Prohibit the use of portable storage devices when such devices have no identifiable owner. || 3 ||
|-
| [[Practice_MP.L2-3.8.9_Details | 3.8.9]] || Protect the confidentiality of backup CUI at storage locations. || 1 ||
|-
| [[Practice_PS.L2-3.9.1_Details | 3.9.1]] || Screen individuals prior to authorizing access to organizational systems containing CUI. || 3 ||
|-
| [[Practice_PS.L2-3.9.2_Details | 3.9.2]] || Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. || 5 ||
|-
| [[Practice_PE.L1-3.10.1_Details | 3.10.1]]* || Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals. || 5 ||
|-
| [[Practice_PE.L2-3.10.2_Details | 3.10.2]] || Protect and monitor the physical facility and support infrastructure for organizational systems. || 5 ||
|-
| [[Practice_PE.L1-3.10.3_Details | 3.10.3]]* || Escort visitors and monitor visitor activity. || 1 ||
|-
| [[Practice_PE.L1-3.10.4_Details | 3.10.4]]* || Maintain audit logs of physical access. || 1 ||
|-
| [[Practice_PE.L1-3.10.5_Details | 3.10.5]]* || Control and manage physical access devices. || 1 ||
|-
| [[Practice_PE.L2-3.10.6_Details | 3.10.6]] || Enforce safeguarding measures for CUI at alternate work sites. || 1 ||
|-
| [[Practice_RA.L2-3.11.1_Details | 3.11.1]] || Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. || 3 ||
|-
| [[Practice_RA.L2-3.11.2_Details | 3.11.2]] || Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. || 5 ||
|-
| [[Practice_RA.L2-3.11.3_Details | 3.11.3]] || Remediate vulnerabilities in accordance with risk assessments. || 1 ||
|-
| [[Practice_CA.L2-3.12.1_Details | 3.12.1]] || Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. || 5 ||
|-
| [[Practice_CA.L2-3.12.2_Details | 3.12.2]] || Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. || 3 ||
|-
| [[Practice_CA.L2-3.12.3_Details | 3.12.3]] || Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. || 5 ||
|-
| [[Practice_CA.L2-3.12.4_Details | 3.12.4]] || Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. || NA || The absence of a system security plan would result in a finding that ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.’
|-
| [[Practice_SC.L1-3.13.1_Details | 3.13.1]]* || Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems. || 5 ||
|-
| [[Practice_SC.L2-3.13.2_Details | 3.13.2]] || Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. || 5 ||
|-
| [[Practice_SC.L2-3.13.3_Details | 3.13.3]] || Separate user functionality from system management functionality. || 1 ||
|-
| [[Practice_SC.L2-3.13.4_Details | 3.13.4]] || Prevent unauthorized and unintended information transfer via shared system resources. || 1 ||
|-
| [[Practice_SC.L1-3.13.5_Details | 3.13.5]]* || Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. || 5 ||
|-
| [[Practice_SC.L2-3.13.6_Details | 3.13.6]] || Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). || 5 ||
|-
| [[Practice_SC.L2-3.13.7_Details | 3.13.7]] || Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). || 1 ||
|-
| [[Practice_SC.L2-3.13.8_Details | 3.13.8]] || Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. || 3 ||
|-
| [[Practice_SC.L2-3.13.9_Details | 3.13.9]] || Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. || 1 ||
|-
| [[Practice_SC.L2-3.13.10_Details | 3.13.10]] || Establish and manage cryptographic keys for cryptography employed in organizational systems. || 1 ||
|-
| [[Practice_SC.L2-3.13.11_Details | 3.13.11]] || Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. || 5/3 || Subtract 5 points if no cryptography is employed; 3 points if mostly not FIPS validated
|-
| [[Practice_SC.L2-3.13.12_Details | 3.13.12]] || Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. || 1 ||
|-
| [[Practice_SC.L2-3.13.13_Details | 3.13.13]] || Control and monitor the use of mobile code. || 1 ||
|-
| [[Practice_SC.L2-3.13.14_Details | 3.13.14]] || Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. || 1 ||
|-
| [[Practice_SC.L2-3.13.15_Details | 3.13.15]] || Protect the authenticity of communications sessions. || 5 ||
|-
| [[Practice_SC.L2-3.13.16_Details | 3.13.16]] || Protect the confidentiality of CUI at rest. || 1 ||
|-
| [[Practice_SI.L1-3.14.1_Details | 3.14.1]]* || Identify, report, and correct system flaws in a timely manner. || 5 ||
|-
| [[Practice_SI.L1-3.14.2_Details | 3.14.2]]* || Provide protection from malicious code at designated locations within organizational systems. || 5 ||
|-
| [[Practice_SI.L2-3.14.3_Details | 3.14.3]] || Monitor system security alerts and advisories and take action in response. || 5 ||
|-
| [[Practice_SI.L1-3.14.4_Details | 3.14.4]]* || Update malicious code protection mechanisms when new releases are available. || 5 ||
|-
| [[Practice_SI.L1-3.14.5_Details | 3.14.5]]* || Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed. || 3 ||
|-
| [[Practice_SI.L2-3.14.6_Details | 3.14.6]] || Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. || 5 ||
|-
| [[Practice_SI.L2-3.14.7_Details | 3.14.7]] || Identify unauthorized use of organizational systems. || 3 ||
|}

''* Basic safeguarding requirements and procedures to protect covered contractor information systems per Federal Acquisition Regulation (FAR) clause 52.204-21, Basic Safeguarding of Covered Contractor Information Systems.''

== DoD Assessment Scoring (Value 5) ==
{| class="wikitable" style="margin:auto"
|-
! style="width: 10%;" | Practice Number
! style="width: 60%;" | Practice Requirement
! style="width: 5%;" | Value
! style="width: 25%;" | Comment
|-
| [[Practice_AC.L2-3.1.1_Details | 3.1.1]] || Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). || 5 ||
|-
| [[Practice_AC.L2-3.1.2_Details | 3.1.2]] || Limit system access to the types of transactions and functions that authorized users are permitted to execute. || 5 ||
|-
| [[Practice_AC.L2-3.1.12_Details | 3.1.12]] || Monitor and control remote access sessions. || 5 || Do not subtract points if remote access not permitted
|-
| [[Practice_AC.L2-3.1.13_Details | 3.1.13]] || Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. || 5 || Do not subtract points if remote access not permitted
|-
| [[Practice_AC.L2-3.1.16_Details | 3.1.16]] || Authorize wireless access prior to allowing such connections. || 5 || Do not subtract points if wireless access not permitted
|-
| [[Practice_AC.L2-3.1.17_Details | 3.1.17]] || Protect wireless access using authentication and encryption. || 5 || Do not subtract points if wireless access not permitted
|-
| [[Practice_AC.L2-3.1.18_Details | 3.1.18]] || Control connection of mobile devices. || 5 || Do not subtract points if connection of mobile devices is not permitted
|-
| [[Practice_AT.L2-3.2.1_Details | 3.2.1]] || Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems. || 5 ||
|-
| [[Practice_AT.L2-3.2.2_Details | 3.2.2]] || Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. || 5 ||
|-
| [[Practice_AU.L2-3.3.1_Details | 3.3.1]] || Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. || 5 ||
|-
| [[Practice_AU.L2-3.3.5_Details | 3.3.5]] || Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. || 5 ||
|-
| [[Practice_CM.L2-3.4.1_Details | 3.4.1]] || Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. || 5 ||
|-
| [[Practice_CM.L2-3.4.2_Details | 3.4.2]] || Establish and enforce security configuration settings for information technology products employed in organizational systems. || 5 ||
|-
| [[Practice_CM.L2-3.4.5_Details | 3.4.5]] || Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. || 5 ||
|-
| [[Practice_CM.L2-3.4.6_Details | 3.4.6]] || Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. || 5 ||
|-
| [[Practice_CM.L2-3.4.7_Details | 3.4.7]] || Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. || 5 ||
|-
| [[Practice_CM.L2-3.4.8_Details | 3.4.8]] || Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. || 5 ||
|-
| [[Practice_IA.L1-3.5.1_Details | 3.5.1]] || Identify system users, processes acting on behalf of users, and devices. || 5 ||
|-
| [[Practice_IA.L1-3.5.2_Details | 3.5.2]] || Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. || 5 ||
|-
| [[Practice_IA.L2-3.5.3_Details | 3.5.3]] || Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to non-privileged accounts. || 5/3 || Subtract 5 points if MFA not implemented. Subtract 3 points if implemented for remote and privileged users, but not the general user
|-
| [[Practice_IA.L2-3.5.10_Details | 3.5.10]] || Store and transmit only cryptographically-protected passwords. || 5 || Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords
|-
| [[Practice_IR.L2-3.6.1_Details | 3.6.1]] || Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. || 5 ||
|-
| [[Practice_IR.L2-3.6.2_Details | 3.6.2]] || Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. || 5 ||
|-
| [[Practice_MA.L2-3.7.2_Details | 3.7.2]] || Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. || 5 ||
|-
| [[Practice_MA.L2-3.7.5_Details | 3.7.5]] || Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. || 5 ||
|-
| [[Practice_MP.L1-3.8.3_Details | 3.8.3]] || Sanitize or destroy system media containing CUI before disposal or release for reuse. || 5 || While exposure limited to CUI on media, failure to sanitize can result in continual exposure of CUI
|-
| [[Practice_MP.L2-3.8.7_Details | 3.8.7]] || Control the use of removable media on system components. || 5 ||
|-
| [[Practice_PS.L2-3.9.2_Details | 3.9.2]] || Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. || 5 ||
|-
| [[Practice_PE.L1-3.10.1_Details | 3.10.1]] || Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals. || 5 ||
|-
| [[Practice_PE.L2-3.10.2_Details | 3.10.2]] || Protect and monitor the physical facility and support infrastructure for organizational systems. || 5 ||
|-
| [[Practice_RA.L2-3.11.2_Details | 3.11.2]] || Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. || 5 ||
|-
| [[Practice_CA.L2-3.12.1_Details | 3.12.1]] || Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. || 5 ||
|-
| [[Practice_CA.L2-3.12.3_Details | 3.12.3]] || Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. || 5 ||
|-
| [[Practice_SC.L1-3.13.1_Details | 3.13.1]] || Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems. || 5 ||
|-
| [[Practice_SC.L2-3.13.2_Details | 3.13.2]] || Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. || 5 ||
|-
| [[Practice_SC.L1-3.13.5_Details | 3.13.5]] || Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. || 5 ||
|-
| [[Practice_SC.L2-3.13.6_Details | 3.13.6]] || Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). || 5 ||
|-
| [[Practice_SC.L2-3.13.11_Details | 3.13.11]] || Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. || 5/3 || Subtract 5 points if no cryptography is employed; 3 points if mostly not FIPS validated
|-
| [[Practice_SC.L2-3.13.15_Details | 3.13.15]] || Protect the authenticity of communications sessions. || 5 ||
|-
| [[Practice_SI.L1-3.14.1_Details | 3.14.1]] || Identify, report, and correct system flaws in a timely manner. || 5 ||
|-
| [[Practice_SI.L1-3.14.2_Details | 3.14.2]] || Provide protection from malicious code at designated locations within organizational systems. || 5 ||
|-
| [[Practice_SI.L2-3.14.3_Details | 3.14.3]] || Monitor system security alerts and advisories and take action in response. || 5 ||
|-
| [[Practice_SI.L1-3.14.4_Details | 3.14.4]] || Update malicious code protection mechanisms when new releases are available. || 5 ||
|-
| [[Practice_SI.L2-3.14.6_Details | 3.14.6]] || Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. || 5 ||
|}

== DoD Assessment Scoring (Value 3) ==
{| class="wikitable" style="margin:auto"
|-
! style="width: 10%;" | Practice Number
! style="width: 60%;" | Practice Requirement
! style="width: 5%;" | Value
! style="width: 25%;" | Comment
|-
| [[Practice_AC.L2-3.1.5_Details | 3.1.5]] || Employ the principle of least privilege, including for specific security functions and privileged accounts. || 3 ||
|-
| [[Practice_AC.L2-3.1.19_Details | 3.1.19]] || Encrypt CUI on mobile devices and mobile computing platforms || 3 || Exposure limited to CUI on mobile platform
|-
| [[Practice_AU.L2-3.3.2_Details | 3.3.2]] || Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. || 3 ||
|-
| [[Practice_MA.L2-3.7.1_Details | 3.7.1]] || Perform maintenance on organizational systems. || 3 ||
|-
| [[Practice_MA.L2-3.7.4_Details | 3.7.4]] || Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. || 3 ||
|-
| [[Practice_MP.L2-3.8.1_Details | 3.8.1]] || Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. || 3 || Exposure limited to CUI on media
|-
| [[Practice_MP.L2-3.8.2_Details | 3.8.2]] || Limit access to CUI on system media to authorized users. || 3 || Exposure limited to CUI on media
|-
| [[Practice_MP.L2-3.8.8_Details | 3.8.8]] || Prohibit the use of portable storage devices when such devices have no identifiable owner. || 3 ||
|-
| [[Practice_PS.L2-3.9.1_Details | 3.9.1]] || Screen individuals prior to authorizing access to organizational systems containing CUI. || 3 ||
|-
| [[Practice_RA.L2-3.11.1_Details | 3.11.1]] || Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. || 3 ||
|-
| [[Practice_CA.L2-3.12.2_Details | 3.12.2]] || Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. || 3 ||
|-
| [[Practice_SC.L2-3.13.8_Details | 3.13.8]] || Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. || 3 ||
|-
| [[Practice_SI.L1-3.14.5_Details | 3.14.5]] || Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed. || 3 ||
|-
| [[Practice_SI.L2-3.14.7_Details | 3.14.7]] || Identify unauthorized use of organizational systems. || 3 ||
|}

== DoD Assessment Scoring (Value 1) ==
{| class="wikitable" style="margin:auto"
|-
! style="width: 10%;" | Practice Number
! style="width: 60%;" | Practice Requirement
! style="width: 5%;" | Value
! style="width: 25%;" | Comment
|-
| [[Practice_AC.L2-3.1.3_Details | 3.1.3]] || Control the flow of CUI in accordance with approved authorizations. || 1 ||
|-
| [[Practice_AC.L2-3.1.4_Details | 3.1.4]] || Separate the duties of individuals to reduce the risk of malevolent activity without collusion. || 1 ||
|-
| [[Practice_AC.L2-3.1.6_Details | 3.1.6]] || Use non-privileged accounts or roles when accessing non-security functions. || 1 ||
|-
| [[Practice_AC.L2-3.1.7_Details | 3.1.7]] || Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. || 1 ||
|-
| [[Practice_AC.L2-3.1.8_Details | 3.1.8]] || Limit unsuccessful logon attempts. || 1 ||
|-
| [[Practice_AC.L2-3.1.9_Details | 3.1.9]] || Provide privacy and security notices consistent with applicable CUI rules. || 1 ||
|-
| [[Practice_AC.L2-3.1.10_Details | 3.1.10]] || Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. || 1 ||
|-
| [[Practice_AC.L2-3.1.11_Details | 3.1.11]] || Terminate (automatically) a user session after a defined condition. || 1 ||
|-
| [[Practice_AC.L2-3.1.14_Details | 3.1.14]] || Route remote access via managed access control points. || 1 ||
|-
| [[Practice_AC.L2-3.1.15_Details | 3.1.15]] || Authorize remote execution of privileged commands and remote access to security-relevant information. || 1 ||
|-
| [[Practice_AC.L1-3.1.20_Details | 3.1.20]] || Verify and control/limit connections to and use of external systems. || 1 ||
|-
| [[Practice_AC.L2-3.1.21_Details | 3.1.21]] || Limit use of portable storage devices on external systems. || 1 ||
|-
| [[Practice_AC.L1-3.1.22_Details | 3.1.22]] || Control CUI posted or processed on publicly accessible systems. || 1 ||
|-
| [[Practice_AT.L2-3.2.3_Details | 3.2.3]] || Provide security awareness training on recognizing and reporting potential indicators of insider threat. || 1 ||
|-
| [[Practice_AU.L2-3.3.3_Details | 3.3.3]] || Review and update logged events. || 1 ||
|-
| [[Practice_AU.L2-3.3.4_Details | 3.3.4]] || Alert in the event of an audit logging process failure. || 1 ||
|-
| [[Practice_AU.L2-3.3.6_Details | 3.3.6]] || Provide audit record reduction and report generation to support on-demand analysis and reporting. || 1 ||
|-
| [[Practice_AU.L2-3.3.7_Details | 3.3.7]] || Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. || 1 ||
|-
| [[Practice_AU.L2-3.3.8_Details | 3.3.8]] || Protect audit information and audit logging tools from unauthorized access, modification, and deletion. || 1 ||
|-
| [[Practice_AU.L2-3.3.9_Details | 3.3.9]] || Limit management of audit logging functionality to a subset of privileged users. || 1 ||
|-
| [[Practice_CM.L2-3.4.3_Details | 3.4.3]] || Track, review, approve or disapprove, and log changes to organizational systems. || 1 ||
|-
| [[Practice_CM.L2-3.4.4_Details | 3.4.4]] || Analyze the security impact of changes prior to implementation. || 1 ||
|-
| [[Practice_CM.L2-3.4.9_Details | 3.4.9]] || Control and monitor user-installed software. || 1 ||
|-
| [[Practice_IA.L2-3.5.4_Details | 3.5.4]] || Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. || 1 ||
|-
| [[Practice_IA.L2-3.5.5_Details | 3.5.5]] || Prevent reuse of identifiers for a defined period. || 1 ||
|-
| [[Practice_IA.L2-3.5.6_Details | 3.5.6]] || Disable identifiers after a defined period of inactivity. || 1 ||
|-
| [[Practice_IA.L2-3.5.7_Details | 3.5.7]] || Enforce a minimum password complexity and change of characters when new passwords are created. || 1 ||
|-
| [[Practice_IA.L2-3.5.8_Details | 3.5.8]] || Prohibit password reuse for a specified number of generations. || 1 ||
|-
| [[Practice_IA.L2-3.5.9_Details | 3.5.9]] || Allow temporary password use for system logons with an immediate change to a permanent password. || 1 ||
|-
| [[Practice_IA.L2-3.5.11_Details | 3.5.11]] || Obscure feedback of authentication information. || 1 ||
|-
| [[Practice_IR.L2-3.6.3_Details | 3.6.3]] || Test the organizational incident response capability. || 1 ||
|-
| [[Practice_MA.L2-3.7.3_Details | 3.7.3]] || Ensure equipment removed for off-site maintenance is sanitized of any CUI. || 1 ||
|-
| [[Practice_MA.L2-3.7.6_Details | 3.7.6]] || Supervise the maintenance activities of maintenance personnel without required access authorization. || 1 ||
|-
| [[Practice_MP.L2-3.8.4_Details | 3.8.4]] || Mark media with necessary CUI markings and distribution limitations. || 1 ||
|-
| [[Practice_MP.L2-3.8.5_Details | 3.8.5]] || Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. || 1 ||
|-
| [[Practice_MP.L2-3.8.6_Details | 3.8.6]] || Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. || 1 ||
|-
| [[Practice_MP.L2-3.8.9_Details | 3.8.9]] || Protect the confidentiality of backup CUI at storage locations. || 1 ||
|-
| [[Practice_PE.L1-3.10.3_Details | 3.10.3]] || Escort visitors and monitor visitor activity. || 1 ||
|-
| [[Practice_PE.L1-3.10.4_Details | 3.10.4]] || Maintain audit logs of physical access. || 1 ||
|-
| [[Practice_PE.L1-3.10.5_Details | 3.10.5]] || Control and manage physical access devices. || 1 ||
|-
| [[Practice_PE.L2-3.10.6_Details | 3.10.6]] || Enforce safeguarding measures for CUI at alternate work sites. || 1 ||
|-
| [[Practice_RA.L2-3.11.3_Details | 3.11.3]] || Remediate vulnerabilities in accordance with risk assessments. || 1 ||
|-
| [[Practice_CA.L2-3.12.4_Details | 3.12.4]] || Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. || NA || The absence of a system security plan would result in a finding that ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.’
|-
| [[Practice_SC.L2-3.13.3_Details | 3.13.3]] || Separate user functionality from system management functionality. || 1 ||
|-
| [[Practice_SC.L2-3.13.4_Details | 3.13.4]] || Prevent unauthorized and unintended information transfer via shared system resources. || 1 ||
|-
| [[Practice_SC.L2-3.13.7_Details | 3.13.7]] || Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). || 1 ||
|-
| [[Practice_SC.L2-3.13.9_Details | 3.13.9]] || Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. || 1 ||
|-
| [[Practice_SC.L2-3.13.10_Details | 3.13.10]] || Establish and manage cryptographic keys for cryptography employed in organizational systems. || 1 ||
|-
| [[Practice_SC.L2-3.13.12_Details | 3.13.12]] || Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. || 1 ||
|-
| [[Practice_SC.L2-3.13.13_Details | 3.13.13]] || Control and monitor the use of mobile code. || 1 ||
|-
| [[Practice_SC.L2-3.13.14_Details | 3.13.14]] || Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. || 1 ||
|-
| [[Practice_SC.L2-3.13.16_Details | 3.13.16]] || Protect the confidentiality of CUI at rest. || 1 ||
|}

CMMC Assessment Process

2026-03-02T01:31:14Z

David:

'''Source of Reference: The [https://cyberab.org/Portals/0/CMMC%20Assessment%20Process%20v2.0.pdf?ver=fEk1pUK1Fg26fVtopxv_DA%3d%3d CMMC Assessment Process Version 2.0 document] from [https://cyberab.org/ Cybersecurity Maturity Model Certification Accreditation Body, Inc.]'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== DISCLAIMER ==
Copyright 2024 © Cybersecurity Maturity Model Certification Accreditation Body, Inc. (d/b/a The Cyber AB)

The views, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an official U.S. Government position, policy, or decision, unless designated by other documentation.

Nothing contained in this document supersedes any standard, policy, direction, or official CMMC program information that has been promulgated by the United States Department of Defense (DoD) or the National Institute of Standards and Technology (NIST). In the event of a contradiction, real or perceived, the reader should adhere to the DoD and/or NIST documentation.

NO WARRANTIES ARE MADE HEREIN. THIS MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. THE CMMC ACCREDITATION BODY, INC. MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY OR RESULTS OBTAINED FROM USE OF THE MATERIAL, NOR ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, or COPYRIGHT INFRINGEMENT.

Comments on this DRAFT CAP v2.0 are welcomed from all members of the CMMC Ecosystem, the DIB, and the public. This feedback will be used to improve the document and may help inform the publication of future editions of the CAP. Feedback can be submitted via the email address CAPComments@cyberab.org.

== Introduction to the CMMC Assessment Process (CAP) ==
The Cybersecurity Maturity Model Certification (CMMC) Program is the U.S. Department of Defense’s (DoD) initiative for the assessment and certification of conformance to established security requirements by companies and organizations within the Defense Industrial Base (DIB).<ref>Specifically, CMMC assesses conformance to the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252-204-7021, “Assessing Contractor Implementation of Cybersecurity Requirements”.</ref> Specifically, CMMC is designed to safeguard Controlled Unclassified Information (CUI) and Federal Contract Information (FCI) that is processed, stored, and/or transmitted during the performance of DoD contracts.

The CMMC Program is overseen by the Office of the DoD Chief Information Officer (ODCIO) and administered by the CMMC Program Management Office (CMMC PMO). The Cyber AB is the designated sole Accreditation Body for the CMMC Program. The Cyber AB supports the CMMC Program through a no- cost contract with DoD’s Washington Headquarters Services (WHS).<ref>The Cyber AB is the “doing business as (d/b/a)” name for the Cybersecurity Maturity Model Certification Accreditation Body, Inc., an
independent, tax-exempt 501(c)(3) charitable organization that supports the Department of Defense’s CMMC Program via a no-cost contract (Department of Defense contract #HQ003420H0003)</ref>

Most of the official CMMC doctrine and documentation is provided within the Code of Federal Regulations (CFR) or by DoD and the National Institute of Standards and Technology (NIST) within the Department of Commerce. For example, the actual CMMC Level 2 security requirements themselves are codified within the NIST Special Publication 800-171, Revision 2 (NIST SP 800-171 R2), “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations”. The CMMC Scoping Guides and Assessment Guides that are developed, maintained, and published by DoD provide supplemental guidance and insight consistent with authoritative references for establishing the assessment boundaries as well as for evaluating the implementation of CMMC security requirements, respectively.

The CMMC Assessment Process (CAP), by comparison, is the official procedural guide for CMMC Third- Party Assessment Organizations (C3PAOs) conducting a CMMC Level 2 certification assessment (herein also referred to as an “assessment”) of an Organization Seeking Certification (OSC). The CAP is published and maintained by The Cyber AB and reviewed and approved by the CMMC PMO. It is intended as a resource for the entire CMMC Ecosystem, as well as for companies and organizations within the DIB.

The purpose of the CAP is to ensure the consistency and integrity of CMMC Level 2 certification assessments. Adherence to the CAP is required by C3PAOs and their CMMC Certified Assessors (CCAs) and is an element of the C3PAO Accreditation Scheme. The CAP is not to be confused with references to a generalized CMMC “assessment process” that appear in the Code of Federal Regulations (CFR), Title 32, part 170.

=== How to Use the CAP ===
The CAP applies only to the conduct of CMMC Level 2 certification assessments.

The CAP must be used in concert with the authoritative CMMC source material—32 CFR part 170 and those documents included by reference therein—as well as the supplemental CMMC guidance published by DoD. It neither replaces nor supersedes any requirements or directions contained in those documents. Moreover, the CAP does not reproduce nor reinterpret any of the rules, provisions, or procedures from either authoritative references or DoD supplemental guidance. Rather, it cites and references those documents throughout. Accordingly, C3PAOs and their CMMC Assessment Teams will need active access to the authoritative documents, along with the CAP, when conducting a CMMC Level 2 certification assessment.

The CAP addresses pre-assessment “preliminary proceedings” that are then followed by the actual assessment process, which is organized across four (4) phases and describes the required activities, roles, and responsibilities of CMMC assessment participants in each.

The four phases are:
* Phase 1: “Conduct the Pre-Assessment”;
* Phase 2: “Assess Conformity to Security Requirements”;
* Phase 3: “Complete and Report Assessment Results”; and
* Phase 4: “Issue Certificate and Closeout POA&M”.

These four phases have been designed to support each CMMC Level 2 certification assessment meeting the following objectives:
* Achieve the highest possible accuracy, fidelity, and quality of CMMC Level 2 certification assessments conducted by C3PAOs;
* Maximize consistency to ensure that CMMC Level 2 certification assessments conducted by C3PAOs and their CMMC Certified Assessors follow the same procedures, sequencing of activities, and production of verifiable results; and
* Instill trust and confidence in the CMMC Program by providing effective, transparent, and efficient CMMC Level 2 certification assessments that are well-planned, executed in consistent fashion, and accurately reported.

The CAP provides a logical and practical sequencing of activities and actions throughout the four phases of the assessment process to ensure procedural coherence for the parties. In certain sections of the process, a precise sequence of specific actions may be explicitly mandated in the document. In these instances, the text will make clear the necessity of following certain procedures in a manner of specific order. In all other aspects of the CAP, the C3PAO and the OSC have the latitude and flexibility to conduct the CMMC assessment with a reasonable approach of their own when applied to the general sequencing of actions throughout the preliminary proceedings and four phases.

== ROLES AND RESPONSIBILITIES ==
A CMMC Level 2 certification assessment requires the active engagement, communication, and attention of several key individuals or organizations, which may include:

As defined in 32 CRF §170.4:
* Organization Seeking Certification (OSC)
* Affirming Official
* CMMC Third-Party Assessment Organization (C3PAO)
*:- Assessment Team members
* Accreditation Body (The Cyber AB)
* CMMC Assessor and Instruction Certification Organization (The CAICO)

Other relevant individuals not directly defined in 32 CRF §170.4:
* Authorized Certifying Official: A designated official employed by the C3PAO and registered with The Cyber AB who is eligible to serve as the issuing authority and signatory for the CMMC Level 2 Certificate of CMMC Status provided to the OSC. C3PAOs may designate more than one Authorized Certifying Official.
* Lead CCA: The CMMC Certified Assessor (CCA) who satisfies the requirements of 32 CFR §170.4(b)(11) and who oversees and manages a dedicated Assessment Team on behalf of the C3PAO for the conduct of a CMMC Level 2 certification assessment. The Lead CCA serves as the counterpart to the Affirming Official. Lead CCA is a formal qualified designation issued by the CAICO. A Lead CCA may oversee multiple Assessment Teams across concurrent CMMC Level 2 certification assessments.
* OSC Point of Contact (OSC POC): The individual within or on behalf of the OSC who provides daily coordination and liaison support between the OSC and the Assessment Team. The OSC POC does not necessarily have to be an employee of the organization that is being assessed, but rather could be a contractor, consultant, or advisor, such as a CMMC Registered Practitioner (RP).
* Quality Assurance (QA) individual: An individual who manages the C3PAO’s quality assurance reviews for a CMMC Level 2 certification assessment, which includes observing the Assessment Team’s conduct and management of the assessment. A QA individual also manages a CMMC appeals process that might be initiated by an OSC.<ref>32 CFR §170.9(b)(13)</ref> A QA individual must be a CCA and cannot be a member of an Assessment Team for which they are performing a quality assurance role. A QA individual is also responsible for the uploading of assessment information into the CMMC instantiation of eMASS.

== PRELIMINARY PROCEEDINGS ==
'''A CMMC Level 2 certification assessment compels a few preliminary administrative, framing, and contractual activities that should be addressed prior to the formal commencement of Phase 1 of the assessment. These interactions between the C3PAO and the OSC concern important aspects of the prospective assessment, and their successful and mutually agreeable resolution will help enable a proper, viable, and transparent CMMC Level 2 certification assessment.'''

=== Receive CMMC Assessment Request from OSC ===
'''P.1''' An OSC generally initiates the engagement concerning a prospective CMMC Level 2 certification assessment by contacting an authorized or accredited C3PAO.

'''P.2''' The updated registry of authorized or accredited C3PAOs in good standing is maintained on the CMMC Marketplace website administered by The Cyber AB. Unless otherwise notified by The Cyber AB, any C3PAO listed as “authorized” or “accredited” within the Marketplace may be considered a C3PAO in good standing and eligible to conduct a CMMC Level 2 certification assessment.<ref>In no circumstances will individuals from The Cyber AB, the CAICO, or DoD provide recommendations or facilitate introductions to any C3PAO.</ref>

=== Confirm the Entity/Entities to be Assessed ===
'''P.3''' The C3PAO shall confirm the specific corporate legal entity that will be assessed, i.e., the precise identity of the actual “Organization Seeking Certification.”

'''P.4''' The C3PAO shall solicit from the OSC the Commercial and Government Entity (CAGE) code, or multiple CAGE codes, that are affiliated with the CMMC Level 2 certification assessment. Technically, a Level 2 CMMC Certificate of Status is issued upon a discrete and identified information system, as defined within a System Security Plan (SSP), that is owned and operated by an OSC. The identity of the OSC is determined by the CAGE code(s), which are issued by DoD.

'''P.5''' The C3PAO should also request the OSC’s assessment unique identifier (UID) if a previous self-assessment had generated one. The DoD Supplier Performance Risk System (SPRS) generates a UID for a Level 1 and Level 2 self-assessment. The Pre-Assessment Form should include this SPRS UID if it exists, but it is not required for a Level 2 certification assessment, as the CMMC instantiation of eMASS will generate a new UID upon successful attainment of a Level 2 Certificate of CMMC Status. The CMMC eMASS UID and the SPRS UID share the same format, serve the same purpose, and are unique for each Level 2 certification assessment and self-assessment, respectively.

'''P.6''' All OSCs must possess a valid CAGE code and the CMMC Level 2 certification assessment cannot proceed without at least one CAGE code of record.<ref>For access to SPRS, the OSC will also need to obtain a Unique Entity ID that is generated from registration in SAM.gov.</ref> A single CMMC assessment may cover multiple entities in the event more than one CAGE code is associated with a singular CMMC Level 2 Assessment Scope.<ref>In addition, the HQ organization or the Host Unit, depending on the corporate structure, must also have registered with the General Services Administration’s (GSA) SAM.gov system and have been issued a Unique Entity Identifier (UEI).</ref>

'''P.7''' The C3PAO should ask the OSC whether any in-scope External Service Providers (ESPs), as defined by '''32 CFR §170.4(b)''', exist and whether the OSC considers the ESP a Cloud Service Provider (CSP) or a “non-CSP” ESP under '''32 CFR §170.19(c)(2)'''.

=== Frame the Assessment ===
'''P.8''' The C3PAO shall work with the Affirming Official and/or the OSC POC to determine the purview and planning details of the assessment. This shall include discussing schedule, the size of the organization and information system to be assessed, personnel, logistics, relevant contractual requirements, and the prospective CMMC Assessment Scope.

'''P.9''' The CMMC Assessment Scope is the set of all assets in the OSC’s environment that will be assessed against CMMC security requirements. It must be specified prior to the commencement of the Assessment.<ref>32 CFR §170.19(a)</ref> '''The determination of proper CMMC Assessment Scope is established in 32 CFR §170.19(c), “CMMC Level 2 Scoping”'''. Supplemental information on CMMC Assessment Scope is contained in the DoD manual, ''CMMC Assessment Scope – Level 2''.

'''P.10''' In framing the CMMC Level 2 certification assessment, the C3PAO and OSC should discuss and agree upon, at a minimum, the following aspects:
* Availability of personnel in support of the assessment;
* Availability of evidence in support of the assessment;
* OSC’s relevant documentation, including the System Security Plan (SSP); and
* An estimate for the approximate duration and timing for the assessment.

'''P.11''' Another consideration of framing the assessment involves determining assessment location(s), including what security requirement objectives of the assessment might be assessed virtually or in-person on the OSC premises. The Lead CCA and/or the C3PAO should consider the optimal logistical approach for implementation validation of the following 18 CMMC security requirement objectives to ensure adequate assessment scope and depth:
* CM.L2-3.4.5[d]: Physical access restrictions associated with changes to the system are enforced.
* MA.L2-3.7.2[d]: Personnel used to conduct system maintenance are controlled.
* MP.L2-3.8.1[c]: Paper media containing CUI is securely stored.
* MP.L2-3.8.1[d]: Digital media containing CUI is securely stored.
* MP.L2-3.8.4[a]: Media containing CUI is marked with applicable CUI markings.
* MP.L2-3.8.4[b]: Media containing CUI is marked with distribution limitations.
* PE.L2-3.10.1[b]: Physical access to organization systems is limited to authorized individuals.
* PE.L2-3.10.1[c]: Physical access to equipment is limited to authorized individuals.
* PE.L2-3.10.1[d]: Physical access to operating environments is limited to authorized individuals.
* PE.L2-3.10.2[a]: The physical facility where organizational systems reside is protected.
* PE.L2-3.10.2[b]: The support infrastructure for organizational systems is protected.
* PE.L2-3.10.2[c]: The physical facility where organizational systems reside is monitored.
* PE.L2-3.10.2[d]: The support infrastructure for organizational systems is monitored.
* PE.L2-3.10.3[a]: Visitors are escorted.
* PE.L2-3.10.3[b]: Visitor activity is monitored.
* PE.L2-3.10.5[b]: Physical access devices are controlled.
* PE.L2-3.10.5[c]: Physical access devices are managed.
* SC.L2-3.13.12[b]: Collaborative computing devices provide indication to users of devices in use.

NOTE: For OSC CMMC-scoped environments that DO NOT have physical and/or environmental controls due to a cloud environment or other factors that negate conducting an “on-site” portion of the assessment, the applicability of these requirements should be addressed between the OSC and the C3PAO in Phase 1.

=== Identify and Manage Initial Conflicts of Interest (COI) ===
'''P.12''' C3PAOs are ultimately responsible for managing impartiality and identifying conflicts of interest relating to a CMMC Level 2 certification assessment. This responsibility cannot be delegated to their CMMC Assessment Team or the OSC.

'''P.13''' C3PAOs shall adhere to the impartiality requirements of ISO/IEC 17020:2012 and the conflict-of- interest disclosure provisions and COI prohibitions within the CMMC Code of Professional Conduct (CoPC). The CoPC contains additional details on impartiality requirements, including CMMC-specific examples of potential COIs that are to be mitigated or avoided.

'''P.14''' The C3PAO shall propose to the OSC the name of the Lead CCA that it intends to assign to the OSC’s CMMC Level 2 certification assessment. The C3PAO shall coordinate with the OSC to ascertain if any conflicts of interest exist between the proposed Lead CCA and the OSC.

'''P.15''' If a conflict of interest is disclosed or identified, by either party, the C3PAO shall work with the OSC to develop a mitigation plan for the identified conflict in question.
:'''P.15.1''' Any mitigation measures to which the parties agree shall be documented.
:'''P.15.2''' In the event the conflict cannot be sufficiently mitigated due to the circumstances, the C3PAO shall not proceed with the assessment.

'''P.16''' The C3PAO should obtain concurrence of the OSC on the assignment of the Lead CCA prior to commencing with the CMMC Level 2 certification assessment.

=== Execute Contractual Agreement ===
'''P. 17''' The C3PAO shall execute a written contractual agreement for the CMMC Level 2 certification assessment with the OSC. Neither The Cyber AB nor DoD are parties to the CMMC Level 2 certification assessment contract between the C3PAO and the OSC.

'''P.18''' The format and structure of the contract is at the discretion and mutual agreement of the C3PAO and OSC.

'''P.19''' A mutual non-disclosure agreement (NDA) between the parties shall be incorporated into the contractual agreement or negotiated and executed in a separate document (e.g., stand-alone NDA, master services agreement, etc.).

'''P.20''' All contractual agreements for CMMC assessments must comport to the CMMC Code of Professional Conduct. Specifically, the C3PAO is prohibited from offering any “guarantees” or “promises” relating to the results of the CMMC Level 2 certification assessment, nor may the C3PAO include any incentives or bonus payments contingent on the issuance of a Certificate of CMMC Status to the OSC.

== PHASE 1 – CONDUCT THE PRE-ASSESSMENT ==
'''In Phase 1, the C3PAO will evaluate if the OSC has adequately prepared for the assessment of its implementation of CMMC Level 2 security requirements.'''

'''At the conclusion of Phase 1, the C3PAO will submit the Pre-Assessment Information Form into the CMMC instantiation of eMASS.'''

'''1.1.''' The Lead CCA shall supervise Phase 1 activities.

=== Review the System Security Plan (SSP) ===
'''1.2.''' C3PAO personnel shall review the OSC’s System Security Plan (SSP) and examine the document for completeness, accuracy, and consistency. By conducting this cursory review of the SSP in Phase 1, the C3PAO should be able to arrive at a reasonable expectation that the OSC has addressed the security requirements of NIST SP 800-171 R2, without regard to evaluating the adequacy or sufficiency of implementation.

Validate CMMC Assessment Scope
'''1.3.''' '''The Lead CCA shall validate the OSC’s CMMC Level 2 Assessment Scope in accordance with 32 CFR §170.19(c), “CMMC Level 2 Scoping”.''' The DoD publication, CMMC Assessment Scope – Level 2, contains additional CMMC scoping guidance.

'''1.4.''' Any disagreements or differences of opinion concerning the CMMC Assessment Scope must be resolved between the C3PAO and the OSC before the CMMC Level 2 certification assessment may proceed to Phase 2.

'''1.5.''' As part of the defined Assessment Scope requirements addressed in 32 CFR §170.19(c), the Lead CCA, Assessment Team members, and the OSC shall establish evaluation methods for CMMC Level 2 security requirement objectives, based on the OSC’s CUI Level 2 assets, and the degree of rigor to be applied to the assessment, which may include, but is not necessarily limited to, the assessment methods addressed in activity 1.10.

'''1.6.''' If the OSC has identified an ESP as being within their CMMC Assessment Scope, the Assessment Team shall confirm that a Customer Responsibility Matrix (CRM) will be available and that ESP personnel will be present and actively participating in the assessment.

'''1.7.''' If the ESP that has been identified as being within the OSC’s CMMC Assessment Scope stores, processes, or transmits CUI, the Assessment Team shall confirm that the OSC will be prepared to provide evidence of the ESP’s FedRAMP Moderate Authorization, FedRAMP Moderate equivalency, or a Level 2 Certificate of CMMC Status, as appropriate.

'''1.8.''' If the Lead CCA cannot confirm proper incorporation, documentation, and/or participation, as appropriate, of an ESP in the OSC’s CMMC Level 2 Assessment Scope, the C3PAO should confer with the OSC Affirming Official and discuss the merits of not proceeding with the CMMC Level 2 certification assessment.

=== Confirm Availability of Evidence ===
'''1.9.''' The Assessment Team will need access to various evidence and artifacts—as well as OSC personnel and ESP personnel (if applicable)—to conduct the evaluative activities in Phase 2 of the CMMC Level 2 certification assessment. The Lead CCA, in preparing for the assessment, should be confident that there will be ample evidence made accessible to the Assessment Team to render an accurate evaluation of the security requirements of NIST SP 800-171 R2 and determine if they have been properly implemented by the OSC.

=== Determine Readiness for Assessment ===
'''1.10.''' The Lead CCA shall make the determination as to the readiness of the OSC to proceed with the conduct of the CMMC Level 2 certification assessment. The determination should be based on the reviews and confirmations conducted in this Phase as well as a general confidence that the OSC is overall prepared for the conduct of the assessment. The Lead CCA should convey to the OSC that various assessment methods (e.g., reviewing, inspecting, observing, studying, analyzing, discussing, and exercising assessment objects) will be employed and may include assessment methods and associate attributes of depth and coverage as outlined in:
* NIST SP 800-171A, Appendix D, “Assessment Methods”;
* NIST SP 800-53A, 3.2.3.2 - “Depth- and Coverage-Related Considerations”;
* NIST SP 800-53A, Appendix C, “Assessment Method Descriptions”; and
* Any in-person observations of security requirement objectives as discussed in activity P.11.

'''1.11.''' The Assessment Team shall not speculate, intimate, nor make any preliminary determination of the OSC’s likelihood of a successful assessment outcome and subsequent issuance of a Certificate of CMMC Status. The sole purpose of this activity is to confirm that the OSC is sufficiently prepared to begin the evaluative portion of the assessment in Phase 2.

=== Compose the Assessment Team ===
'''1.12.''' '''The C3PAO shall compose the CMMC Assessment Team as established and defined in 32 CFR §170.11(b)(10).''' The C3PAO should propose to the OSC the names of the CMMC Certified Assessors (CCAs) and CMMC Certified Professionals (CCPs) that it intends to assign to the Assessment Team.

'''1.13.''' The C3PAO shall have implemented the personnel procedures established in Section 6.15 and 6.16 of ISO/IEC 17020:2012 in composing its Assessment Team.

'''1.14.''' The C3PAO is responsible for managing impartiality and identifying any conflicts of interest of the members of the Assessment Team prior to the commencement of Phase 2 activities. This responsibility cannot be delegated to the Lead CCA or the OSC. Any COI between a member of the Assessment Team and the OSC must be sufficiently mitigated or avoided.

=== Complete the Pre-Assessment Form ===
'''1.15.''' The C3PAO shall generate, collect, and document required pre-assessment and planning information and material via the Pre-Assessment Form pursuant to 32 CFR §170.9(b)(8). Examples of this material include the OSC CAGE code, SSP title, OSC contact information, Assessment Team information, dates of the assessment, the readiness determination for assessment, and other data. This pre-assessment information is required to be collected and uploaded into CMMC eMASS for DoD program management and oversight purposes.<ref>32 CFR § 170.9(b)(8)</ref>

'''1.16.''' The C3PAO may utilize the official CMMC Level 2 Pre-Assessment Form (CMMC_PreAssessment_Template.xlsx) that is available on the CMMC eMASS website. Alternatively, C3PAOs may develop or purchase any tool that is compliant with the CMMC eMASS data standard that can generate pre-assessment data in the required JSON file format.

'''1.17.''' The C3PAO shall follow the instructions and guidance for the pre-assessment and planning information and material as contained in “The DoD CMMC eMASS Concept of Operations for CMMC Third-Party Assessment Organizations”.

'''1.18.''' The C3PAO shall not share any OSC pre-assessment information with any person or organization not involved with that specific CMMC Level 2 certification assessment, except as otherwise required by law.<ref>32 CFR § 170.11(b)(9)</ref>

=== Conduct Quality Assurance Review of Pre-Assessment and Planning Information ===
'''1.19.''' A C3PAO quality assurance individual shall conduct a quality assurance review of the Pre- Assessment Form upon completion by the CMMC Assessment Team. '''For this quality assurance function, the C3PAO shall meet the requirements as outlined in 32 CFR §170.9(b)(13).'''

=== Upload Pre-Assessment Form into CMMC eMASS ===
'''1.20.''' Upon completion of a satisfactory quality assurance review, a quality assurance individual shall upload the pre-assessment form into the CMMC instantiation of eMASS. '''The C3PAO shall follow the CMMC eMASS data standard and upload procedures as set forth in “The Department of Defense CMMC eMASS Concept of Operations for CMMC Third-Party Assessment Organizations”.'''

'''1.21.''' Phase 1 of the CMMC Level 2 certification assessment concludes upon the successful upload of the Pre-Assessment Form into CMMC eMASS.

=== Adverse Determination of Assessment Readiness ===
'''1.22.''' In the event the Lead CCA determined that the OSC was not sufficiently prepared to undergo the CMMC Level 2 certification assessment, they should directly inform the Affirming Official of their decision and provide a full explanation in writing to the OSC as to why the recommendation to suspend the Assessment was made, without providing any remedial advice as to how the OSC could improve its documentation and preparation for the assessment.

'''1.23.''' '''Under no circumstances shall the C3PAO, its Assessment Team, or any other affiliated personnel offer any advice, implementation assistance, or recommendations as to how the OSC can improve or enhance their preparedness for a replanned or rescheduled CMMC Level 2 certification assessment and, pursuant to the CMMC Code of Professional Conduct (CoPC), doing so would conflict the C3PAO from eventually resuming the suspended CMMC certification assessment with that specific OSC.'''

'''1.24.''' In the event the OSC decides to cancel or postpone the assessment, both parties should settle all affairs, as appropriate to the terms of their agreement, including the return of any OSC proprietary information. The C3PAO and the OSC should discuss, in general terms, the option of revisiting the CMMC Level 2 certification assessment when the OSC is fully prepared, as well as the anticipated timelines for resuming the suspended assessment and returning to complete the Phase 1 pre-assessment.

'''1.25.''' In the event of an assessment postponement or cancellation, the C3PAO shall still complete, review, and upload the Pre-Assessment Form into the CMMC instantiation of eMASS as described in previous activities 1.13 through 1.19.

== PHASE 2 – ASSESS CONFORMITY TO SECURITY REQUIREMENTS ==
'''The purpose of Phase 2 is to assess the implementation of CMMC Level 2 security requirements— both in depth and coverage — by the OSC and determine if it has met the assessment objectives of NIST SP 800-171A.'''

'''The C3PAO shall conduct the CMMC Level 2 certification assessment in accordance with 32 CFR § 170.17, NIST SP 800-171A, this document (the “CAP”), and ISO/IEC 17020:2012, “Conformity Assessment—Requirements for the operation of various types of bodies performing inspection.”'''

=== Conduct In-Brief Meeting ===
'''2.1.''' The Lead CCA shall convene an In-Brief Meeting prior to the commencement of assessing the implementation of CMMC security requirements of the OSC. This In-Brief Meeting may be conducted in-person, virtually, or in a hybrid manner. The purpose of the In-Brief Meeting is to establish a common understanding of the assessment objectives, procedures, roles and responsibilities, and schedule.

'''2.2.''' The Lead CCA shall ensure that official minutes or a detailed meeting summary of the kickoff, including all questions and answers, shall be documented and retained by the C3PAO.

'''2.3.''' Attendees for the in-brief meeting shall include, but are not limited to, the Lead CCA, the Affirming Official, the OSC POC, and the Assessment Team members. If a member of the CMMC Assessment Team is unable to attend the In-Brief Meeting, the Lead CCA shall still inform the OSC of the identity of the absent member(s) and facilitate an introduction to the OSC at a subsequent juncture of the assessment.

'''2.4.''' The OSC may elect to have additional employees, consultants, ESP personnel, and any observers present at the In-Brief Meeting. If the C3PAO desires additional individuals external to the CMMC Assessment Team to be present or to observe the actual assessment, it must receive permission from the Affirming Official or OSC POC to do so.

'''2.5.''' The Lead CCA shall, at a minimum, address the following issues with the OSC during the In-Brief Meeting:
* Introduce the Assessment Team members and invite the introduction of key OSC personnel and support staff;
* Confirm the CMMC Assessment Scope;
* Explain CMMC Level 2 assessment procedures as established in 32 CFR §170.17(c);
* Review the assessment schedule;
* Reconfirm the absence of, or disclose, any organizational or individual conflicts of interest;
* Inform the OSC of its rights to appeal the assessment results and describe the C3PAO’s appeals process; and
* Invite any questions or issues for clarification from the OSC.

=== Assess Implementation of Security Requirements ===
'''2.6.''' The Assessment Team shall evaluate the OSC’s implementation of security requirements in accordance with NIST SP 800-171A (current applicable version) and 32 CFR §170.17(c). The three (3) assessment methods of examine, interview, and test, as outlined in NIST SP 800-171A, shall be adhered to by all Assessment Team CCAs assessing security requirements.

'''2.7.''' Upon mutual agreement, the parties may conduct much of the evidence collection and evaluation process virtually, using a stable and commercially secure video conference system or web-based collaboration platform. The C3PAO should make the final decision on whether to conduct some eligible evidence collection activities virtually or in person, based on internal procedures and risk evaluation. In a virtual assessment arrangement, the C3PAO and OSC shall ensure that CUI is not shared electronically as part of the evidence collection and evaluation process, unless the assessment is conducted within CMMC Level 2-conforming environments on both sides.

=== Apply Sampling Values for Depth and Coverage ===
'''2.8.''' The Assessment Team’s optimal sampling aims to balance ensuring sufficient evaluation of assets, people, policies, and procedures to achieve an accurate and proper determination of conformity with the need to conduct an efficient, manageable, and cost-effective assessment. Achieving that balance involves selecting representative samples of evidence to be tested or inspected, while minimizing the risk of overlooking non-conforming items.

'''2.9.''' '''For CMMC Level 2 certification assessments, the Assessment Team shall use a nonstatistical sampling approach in accordance with NIST SP 800-171 R2, Appendix D, “Assessment Method Descriptions”. The Assessment Teams shall employ the FOCUSED value for both depth and coverage in evaluating all Level 2 security requirements, as applicable.'''

'''2.10.''' The Assessment Team should increase the sample for evaluation once it encounters questionable, insufficient, or inadequate evidence for a CMMC security requirement.

'''2.11.''' When encountering multiple CAGE codes in a given assessment, the Assessment Team shall ensure that all CAGE codes have been accounted for in the sampling approach.

'''2.12.''' When encountering multiple physical locations, the Assessment Team should consider in its sampling approach whether different locations use different physical control methods, whether scan results cover systems at all locations, and whether defined system boundaries account for all physical locations.

=== Conduct Assessment Scoring ===
'''2.13.''' '''The Assessment Team shall employ the CMMC Level 2 Scoring Methodology as established in 32 CFR §170.24 that provides a measurement of the OSC’s implementation of the NIST SP 800-171 R2 security requirements.'''

'''2.14.''' The DoD CMMC Scoring Methodology should be referenced for the following:
: '''2.14.1.''' Assessment Findings: '''32 CFR §170.24(b)'''
::* Assessment requirements for '''Met''' findings, including enduring exceptions and temporary deficiencies;
::* Assessment requirements for '''Not Met''' findings; and
::* Assessment requirements for '''Not Applicable''' findings.
: '''2.14.2.''' Scoring: '''32 CFR §170.24(c)'''
::* Assessment requirements for '''Basic Security Requirements''' scoring; and
::* Assessment requirements for '''Derived Security Requirements''' scoring.

'''2.15.''' Assessors may re-evaluate NOT MET security requirements during the assessment and for ten (10) business days following the active assessment period (i.e., the conclusion of Phase 2 activities) '''in accordance with the requirements established in 32 CFR §170.17(c)(2).'''

=== Address External Service Providers ===
'''2.16.''' '''The Assessment Team shall determine the OSC’s utilization and disposition of an in-scope ESP as established in 32 CFR §170.16(a)(3) and 32 CFR §170.16(a)(2), respectively.''' In addition, the CMMC PMO has published Frequently Asked Questions (FAQ) on this issue that should be consulted for additional clarification on the use of ESPs.

'''2.17.''' The Assessment Team shall evaluate that the Customer Responsibility Matrix (CRM) of an ESP is up-to date, includes all relevant parties with security responsibilities, and addresses all in-scope CMMC security requirements performed wholly, partially, or jointly by the ESP.

'''2.18.''' When an Assessor employs the interview method to validate a security requirement on the CRM that is assigned to the ESP, the ESP respondent must demonstrate sufficient knowledge and credible “ownership” of that requirement—no different than that which is required for an OSC representing a security requirement under its own responsibility. The Assessment Team should also employ the examine and test methods when evaluating the inheritance claims made in the CRM by the OSC.

'''2.19.''' In the event the OSC is utilizing a “non-CSP” ESP that voluntarily attained a Level 2 or Level 3 Certificate of CMMC Status, the Assessment Team should anticipate and accept a lower level of effort on behalf of the ESP during the OSC’s assessment.<ref>32 CFR §179.19(c)(2)(ii)</ref> Specifically, if the Assessment Team confirms the ESP is in possession of a valid Certificate of CMMC Status, it may consider those security requirements under the responsibility of the ESP to be in a validated state. The Assessment Team shall still ensure that each inherited security requirement from the ESP is still implemented and currently being maintained in the state under which it was originally assessed and/or have the ESP attest to same. ESP personnel still need to participate during Phase 2 of the OSC’s assessment to answer questions of the Assessment Team.

=== Address Cloud Service Providers ===
'''2.20.''' If the OSC represents that the CSP cloud environment supporting them is currently Authorized at the Moderate baseline within FedRAMP, the Assessment Team shall verify said Authorization by referring to the FedRAMP Marketplace at https://marketplace.fedramp.gov/products and identifying the name of the CSP under the column heading “Provider”. The Assessment Team shall then ascertain if '''the specific cloud service offering that is documented in the OSC’s SSP''' is listed under the column heading “Service Offering”. The Assessment Team can then determine the current Authorization baseline and status of the cloud offering by checking both the “Impact Level” and “Status” column headings. If the above condition is satisfied, the FedRAMP Moderate (or higher) baseline of the CSP’s cloud service offering shall be accepted and noted as such in the assessment results.

'''2.21.''' If the OSC represents that the CSP cloud environment supporting them within their CMMC Assessment Scope is not FedRAMP Authorized '''but meets the security requirements of FedRAMP Moderate (or higher) equivalency,''' the Assessment Team shall determine if equivalency has been attained in accordance with '''current DoD CIO policy on equivalency at the time of the OSC’s Level 2 certification assessment.'''<ref>32 CFR §179.17(c)(5)(ii)</ref>
: '''2.21.1.''' During the OSC’s CMMC Level 2 certification assessment, the Assessment Team shall verify that the CSP’s FedRAMP Moderate Equivalency body of evidence (BOE), as presented by the OSC, is complete, intact, and within the established periodicity, as required. The Assessment Team shall employ the following definitions when reviewing the BoE:
::* Complete: all required elements of the BoE have been compiled and presented to the C3PAO for review;
::* Intact: each element of the BoE is presented in full and is not missing any critical sections, pages, or material information; and
::* Established Periodicity: any element that has a temporal requirement (e.g., must be completed annually) has been completed within the specified timeframe.
:: If the Assessment Team determines that all elements of the cloud service offering’s BoE are complete, intact, and within the established periodicity, then FedRAMP Moderate Equivalency of that cloud service offering has been verified for the CMMC Level 2 certification assessment and shall be denoted as such in the assessment results.
: '''2.21.2.''' In reviewing the BoE, the Assessment Team is not evaluating the CSP’s cloud service offering for conformance to the FedRAMP Moderate standard. Nor is the CMMC Assessment Team conducing a qualitative examination of any element of the BoE, including testing results. Rather, the CMMC Assessment Team is conducting a review of the BoE to verify that it is complete, intact, and within established periodicity.

=== Conduct Quality Assurance Reviews ===
'''2.22.''' '''The C3PAO shall conduct quality assurance reviews during the assessment pursuant to 32 CFR §170.19(b)(14).''' These reviews are in addition to the quality assurance requirements pertaining to the Pre-Assessment Form and the Final Assessment Report as discussed in Phases 1 and 3, respectively, and include conducting observations of the Assessment Team’s conduct and management of the CMMC assessment process. These reviews shall be performed by a quality assurance individual who is not a member of the Assessment Team.

=== Convene Daily Checkpoint Meetings ===
'''2.23.''' The Assessment Team shall host a Daily Checkpoint Meeting with the OSC POC and other OSC personnel at the end of each assessment day to summarize progress, identify any challenges, and discuss additional items for coordination.

== PHASE 3 – COMPLETE AND REPORT ASSESSMENT RESULTS ==
'''The purpose of Phase 3 is to complete, review, report, and submit the assessment results of the CMMC Level 2 certification assessment. By the time the assessment reaches Phase 3, all evaluative activity of the OSC’s implemented security requirements and examination of evidence shall have been completed by the Assessment Team. '''

=== Compile and Compose Assessment Results ===
'''3.1.''' Upon conclusion of the evaluative activity in Phase 2, the Assessment Team shall compile the assessment results and begin composing the results in the required format for eventual upload into the CMMC instantiation of eMASS.

'''3.2.''' '''The C3PAO shall follow the CMMC eMASS data standard as set forth in “The Department of Defense CMMC eMASS Concept of Operations for CMMC Third-Party Assessment Organizations”.'''

'''3.3.''' C3PAOs may utilize the CMMC Level 2 Assessment Results Template that is available on the CMMC eMASS website. Alternatively, C3PAOs may develop or purchase any tool that is compliance with the CMMC eMASS data standard that can generate assessment results data in the required JSON file format.

'''3.4.''' If the Lead CCA determines that all security requirements have been implemented and thus MET, the certification assessment results will reflect a recommendation for a CMMC Level 2 Final Certificate of CMMC Status for the OSC’s in-scope data environment.

'''3.5.''' If the Lead CCA determines that all security requirements have been implemented and thus MET, with the exception of those security requirements that are documented on an existing and valid POA&M '''that is in accordance with 32 CFR §170.21, “Plan of Action and Milestone requirements,”''' the certification assessment results will reflect a recommendation for a CMMC Level 2 '''Conditional''' Certificate of CMMC Status for the OSC’s in-scope data environment.

'''3.6.''' If the Lead CCA determines that all security requirements have not been implemented and thus NOT MET and/or a valid POA&M is not attainable, the certification assessment results will reflect a recommendation for no issuance of a Level 2 Certificate of CMMC Status.

=== Conduct Quality Assurance Review ===
'''3.7.''' The C3PAO shall conduct a formal quality assurance review of the certification assessment results. The C3PAO shall conduct the quality assurance review of the certification assessment results prior to the conduct of the Out-Brief Meeting with the OSC.

'''3.8.''' The C3PAO shall ensure that any individual(s) fulfilling this quality assurance function '''must be a CCA and cannot be a member of the CMMC Assessment Team conducting the CMMC Level 2 certification assessment for which they are performing the quality assurance function.''' The CCA conducting the quality assurance review shall also not have any interaction with the CMMC Assessment Team relating to the conduct of the CMMC Level 2 certification assessment while it is in progress prior to conduct of the quality assurance review itself.

'''3.9.''' The C3PAO quality assurance review of the CMMC Level 2 certification assessment results shall, at a minimum, incorporate quality checks on the accuracy and completeness of the evaluation of all security requirements as well as the conformance to the required reporting formats and incorporated data fields for each.

=== Convene Out-Brief Meeting ===
'''3.10.''' The Lead CCA will convene the Out-Brief Meeting upon the compilation, composition, and quality review of the assessment results. If the OSC has elected to request a re-evaluation of a security requirement pursuant to 32 CFR §170.17(c)(2), “Security requirement re-evaluation,” the Lead CCA will convene the Out-Brief Meeting no sooner than ten (10) business days upon conclusion of all evaluative activity in Phase 3. The Out-Brief Meeting may be conducted in- person, virtually, or in a hybrid manner. The purpose of the Out-Brief Meeting is to convey the results of the assessment to the OSC.

'''3.11.''' Attendees for the out-brief meeting shall include, but are not limited to, the Lead CCA, the OSC Official, the OSC POC, and all Assessment Team Members. If a member of the CMMC Assessment Team is unable to attend the Out-Brief Meeting, the Lead CCA shall inform the OSC of the identity of the absent member(s). The OSC retains the right to insist upon the presence of all CMMC Assessment Team members at the Out-Brief Meeting and, should they do so, the Out- Brief Meeting shall not be conducted until all CMMC Assessment Team members are available to participate or until which time the OSC agrees to proceed with the Out-Brief Meeting without full attendance by the CMMC Assessment Team.

'''3.12.''' The OSC may elect to have additional employees, consultants, ESP personnel, and any observers present at the Out-Brief Meeting. If the C3PAO desires additional individuals external to the Assessment Team to be present at the Out-Brief Meeting, it must receive permission from the Affirming Official or OSC POC to do so.

'''3.13.''' The Lead CCA shall ensure that official minutes or a detailed meeting summary of the Out-Brief Meeting, including all questions and answers, are documented and retained by the C3PAO.

'''3.14.''' The Assessment Team shall prepare and deliver an Assessment Results Briefing documenting the certification assessment results for presentation to the OSC during the Out-Brief Meeting.

The Assessment Results Briefing shall be developed within a common presentation application (e.g. Microsoft PowerPoint, Google Slides, Apple Pages) and can be provided in PDF file format as well.

The following information should be included in the Assessment Results Briefing and addressed during the Out-Brief Meeting:
* Cover page with C3PAO logo, name of Lead CCA, and date of Out-Brief Meeting;
* Dates during which the CMMC Level 2 certification assessment was conducted;
* Name of the OSC;
* CAGE code(s) of the entity/entities associated with the data environment that was assessed;
* Unique Identifier (UID) from SPRS of the system previously self-assessed (if one exists);
* Short name and/or description of the assessment enclave or network that was assessed; the environment that was assessed;
* Final MET / NOT MET / NA determination for each security requirement;
* Status of POA&Ms (if applicable);
* Determination of CMMC Level 2 Certificate of CMMC Status to be issued or denied;
* Artifact retention and integrity procedures (i.e., hashing requirements);
* Proprietary information return and/or destruction per NDA or contract; and
* Summary of OSC Assessment Appeal rights and C3PAO appeals process.

'''3.15.''' '''Under no circumstances shall the Assessment Results Briefing contain any information that communicates, references, or insinuates any recommended or suggested remedial actions that the OSC could or should consider based on the results of the assessment.'''

'''3.16.''' The Assessment Team shall inform the OSC that the hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date that will appear on their Certificate of CMMC Status.<ref>32 CFR §170.17(c)(4)</ref> The Assessment Team shall inform the OSC that it must hash the artifact files using a NIST-approved hashing algorithm. The OSC must provide the Assessment Team with a list of the following for upload into CMMC eMASS.:
* Names of all artifacts;
* Return values of the hashing algorithm; and
* Hashing algorithm.
: Additional guidance for hashing artifacts can be found in the supplemental guidance document, “CMMC Hashing Guide” available at https://DoDcio.defense.gov/CMMC/.

=== Upload Certification Assessment Results into CMMC eMASS ===
'''3.17.''' A C3PAO quality assurance individual shall upload the certification assessment results into CMMC eMASS. '''The C3PAO shall follow the CMMC eMASS data standard and upload procedures as set forth in current version of “The Department of Defense CMMC eMASS Concept of Operations for CMMC Third-Party Assessment Organizations”.'''

'''3.18.''' C3PAOs may utilize the certification assessment results template provided by DoD (CMMC_AssessmentResults_Template.xlsx) that is available on the CMMC eMASS website.

'''3.19.''' Although CMMC Level 2 certification assessment results at the point of creation may not necessarily meet the formal definition of Controlled Unclassified Information (CUI), '''C3PAOs and their CMMC Assessment Teams shall process, store, and transmit CMMC Level 2 certification assessment results as if those assessment results, were, in fact, CUI.'''

'''3.20.''' '''Accordingly, the C3PAO shall utilize their IT environment that is resident within their CMMC Level 2 Assessment Scope as assessed by the Defense Industrial Security Cybersecurity Assessment Center (DIBCAC)—as a qualifying condition of their C3PAO authorization or accreditation—for the purposes of accessing and uploading CMMC Level 2 certification assessment results into CMMC eMASS.''' Specifically, the user workspace that is used to upload CMMC Level 2 certification assessment results to CMMC eMASS shall be one that exists within the scope of the C3PAO’s DIBCAC-assessed environment. There will be no “system-to-system” connections from C3PAOs to CMMC eMASS, so a valid user workspace or end point is required.

'''3.21.''' The C3PAO quality assurance individual shall ensure that the OSC’s hashing data is incorporated into the certification assessment results prior to uploading into CMMC eMASS.

'''3.22.''' Once the certification assessment results are uploaded into CMMC eMASS, if the results warrant a determination of either FINAL or CONDITIONAL CMMC Status of Level 2 (C3PAO) for the OSC, the quality assurance individual will receive from CMMC eMASS the following information: 1) a confirmation of the FINAL or CONDITIONAL CMMC Level 2 Status; 2) an assessment unique Identifier (UID); and 3) the CMMC Status Date of record for the determination.

=== Administer Assessment Appeals (if required) ===
'''3.23.''' The C3PAO shall address any appeals of the Assessment Team’s findings, results, and/or Certificate of CMMC Status determination that is received by the OSC '''in accordance with 32 CFR §170.9(b)(19)''' and its own internal assessment appeals process. The OSC must file an initial appeal with the same C3PAO that conducted its CMMC Level 2 certification assessment.

'''3.24.''' The C3PAO shall have an assessment appeals process, in accordance with ISO/IEC 17020 (2012), on file with The Cyber AB. The C3PAO’s assessment appeals process shall have a time- bound, internal appeals process clearly identified to address all appeals received. The C3PAO shall follow its own published assessment appeals process and shall not deviate from the version that is on file with The Cyber AB.

'''3.25.''' A quality assurance individual who is a CCA shall manage within the C3PAO’s assessment appeals process the OSC’s Level 2 certification Assessment Appeal. The quality assurance individual assigned to manage the OSC’s Assessment Appeal '''cannot be a member of the CMMC Assessment Team that conducted the CMMC Level 2 certification assessment.''' In addition, if the quality assurance individual managing the OSC Assessment Appeal performed any quality assurance reviews of the assessment in question, that individual shall not be involved in determining the final decision on the Appeal.

'''3.26.''' The C3PAO shall complete its assessment appeals process and render a decision on the OSC’s assessment appeal. The adjudication decision of the assessment appeal must be conveyed to the OSC in writing with its supporting rationale.

'''3.27.''' The C3PAO shall enter the required Assessment Appeal information into the assessment appeals template required for CMMC eMASS. The quality assurance individual managing the OSC’s Assessment Appeal shall perform a quality review of the assessment appeals template prior to it being uploaded to CMMC eMASS.

'''3.28.''' Should the OSC refute or oppose the adjudication decision of their Assessment Appeal by the C3PAO, they may elevate their appeal to The Cyber AB. The OSC must elevate its appeal to The Cyber AB within fifteen (15) business days of receiving the adjudication decision of their Assessment Appeal by the C3PAO in writing. '''All Assessment Appeals decisions rendered by The Cyber AB are final.''' The Assessment Appeals Process of The Cyber AB may be found on www.cyberab.org.

== PHASE 4 – ISSUE CERTIFICATE AND CLOSE OUT POA&M ==
'''The final phase of the CMMC Level 2 certification assessment centers on the C3PAO issuing a CMMC Level 2 Certificate of CMMC Status to the OSC, as well as closing out any Plan of Action and Milestones (POA&Ms) that might exist.'''

'''The completion of Phase 4 brings the CMMC Level 2 certification assessment to its formal conclusion.'''

=== Generate Certificate of Status ===
'''4.1.''' Upon receipt from CMMC eMASS of the confirmation of CMMC Level 2 Status (FINAL or CONDITIONAL), the UID, and CMMC Status Date following the submission of the certification assessment results, a quality assurance individual shall generate the Certificate of Status for approval and issuance to the C3PAO.

'''4.2.''' The C3PAO shall only use the standardized CMMC Level 2 Certificate of CMMC Status templates (FINAL and CONDITIONAL) that are approved and provided by The Cyber AB.

'''4.3.''' All C3PAO-generated Certificates of CMMC Status must be approved and signed only by an Authorized Certifying Official that is on file with The Cyber AB.

'''4.4.''' When generating the Certificate of CMMC Status, a quality assurance individual shall enter, affix, or retain the following required information to the document prior to approval and signature by the Authorized Certifying Official:
: '''4.4.1.''' OSC full legal name;
: '''4.4.2.''' All industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope;
: '''4.4.3.''' Short description of the information system assessed;
: '''4.4.4.''' Unique identifier (UID) received from CMMC eMASS;
: '''4.4.5.''' Dates of assessment (beginning of Phase 1 to date of Out-Brief Meeting);
: '''4.4.6.''' CMMC Status Date;
: '''4.4.7.''' CMMC Level;
: '''4.4.8.''' Statement of conformity to NIST SP 800-171 R2;
: '''4.4.9.''' Name and Logo of C3PAO;
: '''4.4.10.''' Logo of the CMMC Program;
: '''4.4.11.''' C3PAO authorization or accreditation badge with ID number; and 4.4.12. Signature block for Authorized Certifying Official.

=== Issue Certificate of CMMC Status ===
'''4.5.''' Upon generation of the Certificate of CMMC Status, an Authorized Certifying Official shall review and sign the Certificate to convey formal issuance on behalf of the C3PAO.

'''4.6.''' The C3PAO shall produce the approved Certificate of CMMC Status in PDF file format.

'''4.7.''' A C3PAO quality assurance individual shall upload the Certificate of CMMC Status into CMMC eMASS '''in accordance with the current version of the “Department of Defense CMMC eMASS Concept of Operations for CMMC Third-Party Assessment Organizations”.'''

'''4.8.''' The C3PAO shall deliver, either in electronic or physical form, a copy of the CMMC Level 2 Certificate of CMMC Status to the Affirming Official, and the OSC POC. The CMMC Level 2 Certificate of CMMC Status is not considered CUI and is not required to be stored, processed, or transmitted as such.

'''4.9.''' The C3PAO shall deliver an electronic copy of the Certificate of CMMC Status to The Cyber AB via the certificates@cyberab.org account.

=== Close-Out POA&M ===
'''4.10.''' An OSC that has been issued a CONDITIONAL Level 2 Certificate of CMMC Status may retain the services of an authorized or accredited C3PAO to close out a Plan of Action & Milestones (POA&M). The OSC may engage a C3PAO different from the C3PAO that conducted Phases 1 through 3 of the applicable CMMC Level 2 certification assessment and issued the CONDITIONAL Level 2 Certificate of CMMC Status. In this situation, the POA&M Closeout C3PAO assumes the responsibility for FINAL CMMC Status determination and, if the POA&M satisfies the closeout requirements, issues the Level 2 FINAL Certificate of CMMC Status to the OSC.

'''4.11.''' The C3PAO shall conduct and document a conflict-of interest disclosure and mitigation review prior to commencing a POA&M closeout for the OSC.

'''4.12.''' '''The C3PAO shall follow the procedures and meet the requirements for closing out a POA&M as established in 32 CFR part 170.17(a)(1)(ii)(B).'''

'''4.13.''' A quality assurance individual shall conduct a quality assurance review of the POA&M close-out upon completion by the Assessment Team. The C3PAO shall ensure that any individual(s) fulfilling this quality assurance function '''must be a CCA and cannot be a member of the CMMC Assessment Team conducting the POA&M closeout assessment for which they are performing the quality assurance function.'''<ref>32 CFR §170.9(14)</ref>

'''4.14.''' The C3PAO quality assurance review of the POA&M closeout shall, at a minimum, incorporate quality checks on the accuracy and completeness of the evaluation of all POA&M security requirements as well as the conformance to the required reporting formats and incorporated data fields for each. The C3PAO shall conduct the quality assurance review of the CMMC POA&M closeout '''prior to''' its upload into CMMC eMASS.

'''4.15.''' The Assessment Team may choose to offer the OSC a POA&M Out-Brief Meeting, but one is not required. The Assessment Team is required to convey the results of the POA&M closeout in writing and convey the remaining administrative next steps to the OSC.

'''4.16.''' In the event the C3PAO refutes the findings of the CMMC Assessment Team during the POA&M closeout, they retain the right to appeal the findings, results, and/or CMMC Level 2 Status decision. The process and timelines for administering and adjudicating a POA&M closeout appeal are identical to those of established in Phase 3, with the exception that the assessment appeals process of the Phase 4 C3PAO that closed out the POA&M is controlling and shall be followed.

'''4.17.''' Upon conclusion of the POA&M closeout and quality assurance review, the C3PAO shall submit the POA&M closeout results to CMMC eMASS. If the POA&M was satisfactorily closed out, the C3PAO shall then issue a FINAL Level 2 Certificate of CMMC Status, utilizing the same procedures and following the same requirements as established above in activities 4.1 through 4.9.

== Notes ==
<references />

CMMC Hashing Guide

2026-03-02T01:30:58Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Hashing Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== CMMC Artifact Hashing Tool User Guide ==
=== Audience ===
This guide assumes that the reader has a basic understanding of command-line tools and scripting. Given the proprietary nature of the artifacts generated during a CMMC assessment, it also assumes that the Organization Seeking Assessment (OSA) has staff with sufficient technical background to use the hashing tool independently on an approved organizational system. If the OSA lacks staff with the requisite background, they may request assistance from the assessor or another party in order to complete the process of artifact hashing. Step- by-step instructions are provided below.

=== Scope and Purpose ===
When doing self-assessments, OSAs are not required to generate hashes for artifacts. Hashing is only required for assessments by C3PAOs and DCMA DIBCAC.

NOTE: Do not confuse hashing with encryption. Both are cryptographic functions, but hashing does not provide confidentiality for the artifacts. It provides only a mechanism to track the integrity of the artifacts. Confidentiality of the artifacts needs to be handled separately by the OSA, using a different mechanism, such as encryption. When choosing a location to archive the artifacts, the OSA should consider data protection requirements.

During the performance of a CMMC assessment, the team will collect objective evidence using a combination of three assessment methods:
* examination of artifacts,
* affirmations through interviews, and
* observations of actions.

Because these OSA artifacts may be proprietary, the assessment team will not take or retain OSA artifacts offsite at the conclusion of the assessment. For the protection of all stakeholders, the OSA must retain the artifacts. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the date of assessment.

Because the artifacts will remain with the OSA, a tool has been developed to provide a cryptographic reference (or hash) for each artifact used in the assessment as discussed
in 32 CFR § 170.17 and 32 CFR § 170.18. If needed, the integrity of the assessment artifacts may be checked by verifying the hash generated during the assessment. If an artifact has not been modified, the hash will remain the same.

The Artifact Hashing Tool is a Microsoft PowerShell script that uses the SHA-256 algorithm to generate a hash of each artifact. Next, it generates a list of artifact filenames and associated hashes, then completes the process by generating a hash of the list. At the conclusion of the assessment, the OSA and the assessor will each have the list of artifact names, artifact hashes, and a hash of the list.

=== System Requirements ===
A computer capable of running Microsoft PowerShell is required for this tool. PowerShell is available for Windows, Linux, and macOS. Please refer to [https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell?view=powershell-7.5&viewFallbackFrom=powershell-7.1 Microsoft PowerShell instructions] for installation, if the software is not already on the system. The execution of PowerShell scripts may be restricted by the organization. Microsoft’s instructions explain how to temporarily bypass such restrictions to use the tool. It may be necessary to speak to an administrator to obtain the necessary permissions to execute PowerShell scripts. Additional details can be found in the Supplemental Information section.

This tool was tested on Windows 11 (version 23H2), Windows 10 (version 1904), Linux (Ubuntu 20.04), and macOS (10.15.7).

=== Process Overview ===
During the assessment planning and preparation, the OSA and assessment team should decide jointly how they will store artifact files during the assessment. The agreed-upon location should be secure and accessible only to those with a need to know because the artifacts may contain sensitive or proprietary information.

During the course of the assessment, the team collects information through three assessment methods: interviews, artifact examination, and observation. This collection may include such activities as interviewing organization staff, examining the documents or the configuration of a device, and observing organization staff performing actions (Figure 1). It is important to collect evidence while performing these actions, to substantiate MET or NOT MET decisions for each CMMC requirement.

[[ File:ArtifactHashingToolFigure1.png | center | Figure 1 - Assessment Execution ]]

The central location where collected assessment artifacts are stored may be a single root directory (Figure 2, Scenario 1) where all documents are stored. Optionally, the root directory may have subdirectories within it (Figure 2, Scenario 2). The Artifact Hashing Tool can operate in either scenario.

[[ File:ArtifactHashingToolFigure2.png | center | Figure 2 - Folder Hierarchy Scenarios ]]

Clearly naming artifacts will aid in the event of an audit or retrospective reviews of assessment data. Artifact filenames should follow a standardized naming pattern or be grouped by CMMC requirement.

After all artifacts reviewed by the assessment team are consolidated into the central location, the OSA may run the artifact hashing tool. Both the OSA and assessor should retain a copy of the file log, file hashes, and the integrity hash. The following section details the process for generating hashes for all collected assessment artifacts.

=== Tool Usage Process ===
Use the commands listed in the instructions below to execute the Artifact Hashing Tool on a computer running Microsoft Windows. If the computer running the tool is operating on Linux or macOS, minor command modifications will need to be made (e.g., in Linux and macOS, use '''mv''' instead of '''ren''', respectively).

==== Preparation ====
NOTE: The command line entries in this guide can be copied and pasted into the respective OS Command Prompt.
# Create the ArtifactHash.txt file from the content located in Appendix A. The ArtifactHash.txt file location should be the root directory of the collected assessment artifacts. Ensure you have access to the root directory location.
# Locate the root directory where collected assessment artifacts are stored. In this instance, "root directory" refers to the directory in which all of the assessment artifacts and/or other folders containing assessment artifacts have been stored.
# Modify the file extension of the script file created from the Appendix A content. The script content is located as text within Appendix A. You should have a copy of the ArtifactHash.txt file in the root directory of collected assessment artifacts. You can use another location, but this guide assumes that the script file has been copied to this directory.
# Open '''Windows Command Prompt''' or a terminal window for macOS/Linux, then navigate to the location of the script file.
# Change the file extension of the script file to read as follows:

:: <code>Windows:</code>
:: <code>ren ArtifactHash.txt ArtifactHash.ps1</code>
:: <code>Linux/macOS:</code>
:: <code>mv ArtifactHash.txt ArtifactHash.ps1</code>

==== Execution of Tool ====
NOTE: Contact the system administrator to address permission errors or other restrictions when running this script.
# After you rename the script, you can run the tool. The script has three parameters:
#* ''Execution Policy'': This parameter allows the script to run unrestricted. It is recommended that you retain the ByPass value.
#* ''ArtifactRootDirectory'': This specifies the root directory path of the CMMC assessment artifacts. This location can be represented by a traditional Windows file path, a UNC path, or even .\ to indicate the current directory. The default value is the current directory. If the script is located in the root of the artifact repository, this parameter does not need to be specified on the command line.
#* ''ArtifactOutputDirectory'': This specifies the directory where the script will write two log files. The first log is the listing of all files within the ''ArtifactRootDirectory'' as well as the corresponding hash. The second log is a hashed value of the first log. This is a simple way to help preserve the integrity of the artifact listing without requiring the maintenance of a public/private key pair or a password for an HMAC. The default value for this parameter is the current directory. If the script is located in the desired output location, this parameter does not need to be specified on the command line.
# Execute the following command, along with the determined values for the two directory parameters:
#: <code>Windows:</code>
#: <code>powershell -ExecutionPolicy ByPass .\ArtifactHash.ps1 -ArtifactRootDirectory .\ -ArtifactOutputDirectory .\</code>
#: <code>Linux/macOS:</code>
#: <code>pwsh -ExecutionPolicy ByPass ./ArtifactHash.ps1 -ArtifactRootDirectory ./ -ArtifactOutputDirectory ./</code>
#: '''Important'''
#: The command above assumes that the script file is located in the root assessment artifact directory and that the output hash files typically goes into to the same directory. The “.\” following the parameters should be modified if the script is located in a different directory or to output the hash files to a different directory. In addition, this command assumes usage of the ExecutionPolicy cmdlet, which may not be necessary. See the Supplemental Information section for details.
# If the tool has run successfully, SCRIPT COMPLETE will be displayed in the command prompt. At this time, verify that the files (CMMCAssessmentArtifacts.log) and (CMMCAssessmentLogHash.log) have been generated in the output directory specified by the second script parameter.

==== Use Example ====
In this simple example, a C3PAO has used four files provided by an OSC to support an assessment. The four assessment related files are in a directory along with the PowerShell script as shown in Figure 3.

[[ File:ArtifactHashingToolFigure3.png | center | Figure 3 - Assessment file directory before hash ]]

Figure 4 shows the successful execution of the PowerShell script and Figure 5 shows the same directory with the addition of the two PowerShell output files.

[[ File:ArtifactHashingToolFigure4.png | center | Figure 4 - Successful execution of ArtifactHash.ps1 ]]

[[ File:ArtifactHashingToolFigure5.png | center | Figure 5 - Assessment file directory after script execution ]]

CMMCAssessmentArtifacts.log, in Figure 6, is a text file that contains the hashing algorithm used, hash value of each individual file in the directory, and the filename and path. This text file contains the list of artifacts. The filename is entered into the Hashed Data List data field in the CMMC instantiation of eMASS.

[[ File:ArtifactHashingToolFigure6.png | center | Figure 6 - CMMCAssessmentArtifacts.log ]]

CMMCAssessmentLogHash.log in Figure 7, is a text file that contains the single return value generated by creating a hash of CMMCAssessmentArtifacts.log. This hash is the string to enter in the Hash Value data field in the CMMC instantiation of eMASS.

[[ File:ArtifactHashingToolFigure7.png | center | Figure 7 - CMMCAssessmentLogHash.log ]]

=== Supplemental Information ===
* For parameters that include spaces in the paths, surround the entire path name in single quotes. During testing, double quotes produced an error.
* If the script file is not placed in the root assessment artifact directory, you will need to specify the path of the script, for example, Z:\Files\Tool ArtifactHash.ps1.
* In certain instances, the organization may restrict the execution of PowerShell scripts. The By Pass value of the Execution Policy cmdlet within the command should temporarily bypass these restrictions. In addition, it is possible to manually verify and modify the PowerShell script execution policy of the current user as follows. 

: '''Note:''' The content following the # (hashtag) symbol represents a comment in the script.
# Verify the policy that is set.
#: <code>Windows:</code>
#: <code>powershell get-ExecutionPolicy -Scope CurrentUser #make note of the current setting</code>
# Set the execution policy for the user to bypass, and verify that "Bypass" is reflected.
#: <code>Windows:</code>
#: <code>set-ExecutionPolicy ByPass -Scope CurrentUser</code>
#: <code>get-ExecutionPolicy -Scope CurrentUser #verify the setting was updated</code>
# After completion of the hashing process, change the execution policy back to the default state.
#: <code>Windows:</code>
#: <code>set-ExecutionPolicy Default -Scope CurrentUser</code>

== Appendix A: ArtifactHash.txt File Content ==
The blue courier text below is the powershell script needed for this task. Use cut and paste to copy all of the blue courier content into your favorite text editor and store the file with the name: ArtifactHash.txt.

<pre style="color: blue">
<#
.SYNOPSIS
Hash artifacts for a CMMC Assessment to maintain integrity in the event any files are needed in the future
.DESCRIPTION
This script will recursively evaluate all files in a local or UNC path. Each file will be hashed and written to a text file. Additionally, the record is hashed to preserve the integrity of the output
.PARAMETER ArtifactRootDirectory
Specifies the root path of the CMMC assessment artifacts. This location can be represented by a traditional Windows file path, a UNC path, or even .\
.PARAMETER ArtifactOutputDirectory
Specifies the directory where the script will write two log files. The first log is the listing of all files within the ArtifactRootDirectory as well as the corresponding hash. The second log, is a hashed value of the first log. This is a simple way to help preserve the integrity of the artifact listing without requiring the maintenance of a public/private key pair or a password for an HMAC
#>
#VERSION 1.11
param
(
[Parameter(mandatory=$false)][string]$ArtifactRootDirectory = ".\",
[Parameter(mandatory=$false)][string]$ArtifactOutputDirectory = ".\"
)

function GetFileHashes ([string] $rootLocation, [boolean] $isDirectory)
{
if ($isDirectory)
{
$hashList = Get-ChildItem -path $rootLocation -Recurse -Force -File | Get-FileHash
}
else
{
$hashList = Get-FileHash $rootLocation
}
return $hashList
}

function WriteASCIIFile ([string] $filePath, [object] $fileContent)
{
Out-File -FilePath $filePath -Force -Encoding ASCII -InputObject $fileContent -Width 1024
}

function VerifyLocationExist ([string] $location)
{
try
{ $doesExist = Test-Path $location
if (-Not $doesExist)
{
ECHO "Location $location does not exist"
throw
}
}
catch
{
ECHO "The program failed to evaluate the path. Perhaps you specified an incorrectly formatted command line parameter?"
EXIT
}
}

function IsDirectory ([string] $location)
{
$isDirectory = (get-item $location) -is [System.IO.DirectoryInfo]
return $isDirectory
}

$version = "1.11"
ECHO "Artifact Hashing Script Version $version"
#Just making sure locations are legit
ECHO "Verifying existence of $ArtifactRootDirectory"
VerifyLocationExist $ArtifactRootDirectory
ECHO "Verifying existence of $ArtifactOutputDirectory"
VerifyLocationExist $ArtifactOutputDirectory

#determine if the input provided is for a single file or for a directory of files
$artifactLocationIsDir = IsDirectory($ArtifactRootDirectory)
$logFileLocationIsDir = IsDirectory($ArtifactOutputDirectory)

if($logFileLocationIsDir)
{
$logFileLocation = $ArtifactOutputDirectory + "\CMMCAssessmentArtifacts.log"
$hashedLogFileLocation = $ArtifactOutputDirectory + "\CMMCAssessmentLogHash.log"
}
else
{
$endOfString = $ArtifactOutputDirectory.LastIndexOf("\")
$logFileLocation = $ArtifactOutputDirectory.Substring(0,$endOfString) + "\CMMCAssessmentArtifacts.log"
$hashedLogFileLocation = $ArtifactOutputDirectory.Substring(0,$endOfString) + "\CMMCAssessmentLogHash.log"
}

#return the list of artifacts with their hashed values
$hashedFiles = GetFileHashes $ArtifactRootDirectory $artifactLocationIsDir
ECHO "Writing artifact file listing to $logFileLocation"
WriteASCIIFile $logFileLocation $hashedFiles

#Now, I'm going to create a second file hashing the artifacts file
$hashTheHash = GetFileHashes $logFileLocation $false
ECHO "Writing hashed value of artifact file listing to $hashedLogFileLocation"
WriteASCIIFile $hashedLogFileLocation $hashTheHash
ECHO "SCRIPT COMPLETE"
</pre>

Level 3 Assessment Guide

2026-03-02T01:30:43Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 3 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 3 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.18 of title 32, Code of Federal Regulations (CFR). Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting both a Level 2 self-assessment and Level 2 certification assessment, can be found in ''CMMC Assessment Guide – Level 2''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system, or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''. A ''Level 3 certification assessment'' as defined in 32 CFR § 170.4 is ''the activity performed by the Department of Defense (DoD) to evaluate the CMMC level of an Organization Seeking Certification (OSC)''. For Level 3, assessments are conducted exclusively by the DCMA DIBCAC.

An OSC seeking a Level 3 certification assessment must have first achieved a CMMC Status of Final Level 2 (C3PAO), as set forth in 32 CFR § 170.18(a), for all applicable information systems within the CMMC Assessment Scope, and the OSC must implement the Level 3 requirements specified in 32 CFR § 170.14(c)(4). This is followed by the Level 3 certification assessment conducted by the DCMA DIBCAC.

OSCs may also use this guide to perform Level 3 self-assessments (for example, in preparation for an annual affirmation); however, they are not eligible to submit results from a self-assessment in support of a Level 3 certification assessment. Only the results from an assessment by DCMA DIBCAC are considered for award of the CMMC Statuses Conditional Level 3 (DIBCAC) or Final Level 3 (DIBCAC). Level 3 reporting and affirmation requirements can be found in 32 CFR § 170.18 and 32 CFR § 170.22.

=== Level 3 Description ===
Level 3 consists of selected security requirements derived from National Institute of Standards and Technology (NIST) Special Publication (SP) 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'', with DoD-approved parameters where applicable. Level 3 only applies to systems that have already achieved a Final Level 2 (C3PAO) CMMC Status. Level 2 consists of the security requirements specified in NIST SP 800-171, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Like Level 2, Level 3 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 3 provides additional protections against advanced persistent threats (APTs), and increased assurance to the DoD that an OSC can adequately protect CUI at a level commensurate with the adversarial risk, to include protecting information flow with the government and with subcontractors in a multitier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSCs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 3 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 3 assessment processes set forth in 32 CFR § 170.18. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(d).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4, definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of specific terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 3 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' Provides guidance specific to each Level 3 security requirement.

== Assessment and Certification ==
The DCMA DIBCAC will use the assessment methods defined in NIST SP 800-172A<ref>NIST SP800-172A, March 2022</ref>, ''Assessing Enhanced Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide to conduct Level 3 certification assessments. Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 3 certification assessment for an entire enterprise network or for specific enclave(s), depending on how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(d).

=== Assessment Scope ===
Prior to conducting a CMMC Level 3 certification assessment, the Level 3 CMMC Assessment Scope must be defined as addressed in 32 CFR § 170.19(d) and the ''CMMC Scoping Guide – Level 3'' document<ref>Note that an OSC ought to be mindful of their full Level 3 scoping in their request for a Level 2 assessment.</ref>. The CMMC Assessment Scope informs which assets within the OSC’s environment will be assessed and the details of the assessment. The OSC must have achieved a CMMC Status of Final Level 2 (C3PAO) of all systems included within the Level 3 CMMC Assessment Scope prior to requesting the Level 3 assessment, as set forth in 32 CFR § 170.18.

The Level 3 assessment scoping is based on the requirements defined in 32 CFR § 170.19(d) and supported by the ''CMMC Scoping Guide – Level 3 ''document. The ''CMMC Scoping Guide – Level 3'' document is available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/. If a Final Level 2 (C3PAO) CMMC Status has not already been achieved for the desired CMMC Assessment Scope, the OSC may not proceed with the Level 3 assessment.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The custom terms associated with Level 3 are:
* '''Assessment:''' As defined 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** Level 3 certification assessment is the term for the activity performed by the DCMA DIBCAC to evaluate the information system of an OSC when seeking a CMMC Status of Level 3 (DIBCAC).
** POA&M closeout certification assessment is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' Means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' Means an item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns. Understanding ''assets'' is critical to identifying the ''CMMC Assessment Scope''; for more information see ''CMMC Scoping Guide – Level 3''.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all ''assets'' in the OSC’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' The result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** '''Conditional Level 3 (DIBCAC):''' Defined in 32 CFR § 170.18(a)(1)(ii). The OSC will achieve CMMC Status of Conditional Level 3 (DIBCAC) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 3 POA&M requirements listed in 32 CFR § 170.21(a)(3).
** '''Final Level 3 (DIBCAC):''' Defined in 32 CFR § 170.18(a)(1)(iii). The OSC will achieve Final Level 3 (DIBCAC) CMMC Status for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and, if applicable a POA&M closeout assessment within 180 days. Additional guidance can be found in 32 CFR §170.21.
* '''Enduring Exception:''' As defined 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and Government Furnished Equipment (GFE) may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSC being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of a OSC’s solution.
* '''Organization-Defined Parameters (ODPs):''' Selected enhanced security requirements contain selection and assignment operations to give organizations<ref>The organization defining the parameters is the DoD.</ref> flexibility in defining variable parts of those requirements, as defined in NIST SP 800-172A. ODPs are used in NIST SP 800-172 and NIST SP 800-172A to allow Federal agencies, in this case the DoD, to customize security requirements. Once specified, the values for the assignment and selection operations become part of the requirement and objectives, where applicable.
: The assignments and selections chosen for Level 3 are underlined in the requirement statement and objectives. In some cases, further specificity of the assignment or selection will need to be made by the OSC. In those cases, the term and abbreviation ODPs is used in the assessment objectives to denote where additional definition is required.
* '''Periodically:''' Means occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSC flexibility, with an interval length of no more than one year.
* '''Security Protection Data:''' As defined 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. Security Protection Data is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' Means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems.
* '''Temporary deficiency:''' As defined 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 3'' leverages the assessment procedure described in NIST SP 800-172A Section 2.1:

: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and objects that can be used to conduct the assessment. Each assessment objective includes a set of determination statements related to the CUI enhanced security requirement that is the subject of the assessment. Organization-defined parameters (ODP) that are part of selected enhanced security requirements are included in the initial determination statements for the assessment procedure. ODPs are included since the specified parameter values are used in subsequent determination statements. ODPs are numbered sequentially and noted in bold italics.
: Determination statements reflect the content of the enhanced security requirements to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to an enhanced security requirement produces assessment findings. The findings are used to determine if the enhanced security requirement has been satisfied.
: Assessment objects are associated with the specific items being assessed. These objects can include specifications, mechanisms, activities, and individuals.''
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''
: ''Assessment methods define the nature and the extent of the assessor’s actions. The methods include examine, interview, and test.''
: * ''The examine method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities).''
: * ''The interview method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The test method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''
: ''The purpose of the assessment methods is to facilitate understanding, achieve clarification, and obtain evidence. The results obtained from applying the methods are used for making the specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-172A. The criteria are authoritative and provide a basis for the assessor to conduct an assessment of a requirement.

=== Methodology ===
During the CMMC certification assessment, the assessor will verify and validate that the OSC has met the requirements. Because an OSC can meet the assessment objectives in different ways (e.g., through documentation, computer configuration, network configuration, or training), the assessor may use a variety of techniques, including one or more of the three assessment methods described above from NIST SP 800-172A, to determine if the OSC meets the intent of the requirements.

The assessor will follow the guidance in NIST SP 800-172A when determining which assessment methods to use:

: ''Organizations [DoD] are not expected to use all of the assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations have the flexibility to establish the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and objects are deemed to be the most useful in obtaining the desired results). The decision on level of effort is made based on how the organization can accomplish the assessment objectives in the most cost-effective and efficient manner and with sufficient confidence to support the determination that the CUI enhanced security requirements have been satisfied.''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix C of NIST SP 800-172A.

Figure 1 illustrates an example of an assessment procedure for requirement AC.L3-3.1.3e.

=== Who Is Interviewed ===
The assessor has discussions with OSC staff to understand if a requirement has been addressed. Interviews with applicable staff (possibly at different organizational levels) determine if CMMC security requirements are implemented and if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

=== What Is Examined ===
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities. The primary focus will be to examine through demonstrations during interviews.

For some requirements, the assessor reviews documentation to determine if assessment objectives are met. Interviews with OSC staff may identify the documents uses. Documents need to be in their final forms; working papers (e.g., drafts) of documentation are not eligible to be submitted as evidence because they are not yet official and are still subject to change.

Common types of documents that can be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system-level, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSC may not have these specific documents, and other documents may be used to provide evidence of compliance.

In other cases, the requirement is best assessed by observing that safeguards are in place by viewing hardware or associated configuration information or observe staff exercising a process.

=== What Is Tested ===
Testing is an important part of the assessment process. Interviews tell the assessor what the OSC staff believe to be true, documentation provides evidence of intent, and testing demonstrates what has or has not been done and is the preferred assessment method when possible. For example, staff may talk about how users are identified and documentation may provide details on how users are identified, but seeing a demonstration of user identification provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC security requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve CMMC Status of Final Level 3 (DIBCAC) as described in 32 CFR § 170.18, the OSC will need a finding of MET or NOT APPLICABLE on all Level 3 security requirements.

* '''MET:''' All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and a not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET:''' One or more objectives for the security requirement is not satisfied. During a Level 3 certification assessment, for each requirement objective marked NOT MET, the assessor will document why the evidence provided by the OSC does not conform.
* '''NOT APPLICABLE (N/A):''' A security requirement and/or objective does not apply at the time of the assessment. For example, SI.L3-3.14.3e might be N/A if there are no Internet of Things (IoT), Industrial Internet of Things (IIoT), Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, or test equipment included in the Level 3 CMMC Assessment Scope.

If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.

Each assessment objective in NIST SP 800-171A and NIST SP 800-172A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.

CMMC certification assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.

A security requirement can be applicable even when assessment objectives included in the security requirements are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.

Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or ESP, implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSC uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
This section provides detailed information and guidance for assessing each Level 3 security requirement. The section is organized first by domain and then by individual security requirement. Each security requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format DD.L#-REQ (e.g., AC.L3-3.1.2e); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement. In the case where the original NIST SP 800-172 requirement requires an assignment and/or selection statement, the Level 3 assignment (and any necessary selection) text is emphasized using underlining. See Section 2.2 in NIST SP 800-172 for the discussion on assignments and selections.
* '''Assessment Objectives [NIST SP 800-172A]:''' Identifies the specific list of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-172A and includes the Level 3 assignment/selection text (as appropriate). In cases where a Level 3 assignment fully satisfies the definition(s) required in an organization-defined parameter (ODP) in NIST SP 800-172A, the ODP statement is not included as an objective, since that objective has been met by the assignment itself. However, when the assignment does not fully contain all required aspects of a NIST SP 800-172A ODP, the ODP is included as its own objective, using the original NIST SP 800-172A ODP number (e.g., “[ODP4]”). See the breakout box ''ORGANIZATION-DEFINED PARAMETERS'' in Section 2.1 of NIST SP 800-172A for additional details on an ODP. In all cases where an assignment is used within an objective, it also emphasized using underlining.
* '''Potential Assessment Methods and Objects [NIST SP 800-172A]:''' Defines the nature and extent of the assessor’s actions. Potential assessment methods and objects are as defined in NIST SP 800-172A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.
* '''Discussion [NIST SP 800-172]:''' Contains discussion from the associated NIST SP 800-172 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST content to provide supplemental information on the requirement intent.
** Contains examples illustrating how the OSC might apply the requirement. These examples provide insight but are not intended to be prescriptive of how the requirement must be implemented, nor comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in brackets (e.g., [a,d] for objectives “a” and “d”) within the text. Note that some of the examples contain company names; all company names used in this document are fictitious.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions the assessor may ask when assessing the objectives.
* '''Key References:''' Lists the security requirement from NIST SP 800-172.

== Access Control (AC) ==
=== AC.L3-3.1.2e – Organizationally Controlled Assets ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] Information resources that are owned, provisioned, or issued by the organization are identified; and
: [b] Access to systems and system components is restricted to only those information resources that are owned, provisioned, or issued by the organization.
|-
|[[Practice_AC.L3-3.1.2e_Details|More Practice Details...]]
|}
=== AC.L3-3.1.3e – Secured Information Transfer ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ secure information transfer solutions to control information flows between security domains on connected systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [ODP1] Secure information transfer solutions are defined;
: [a] Information flows between security domains on connected systems are identified; and
: [b] Secure information transfer solutions are employed to control information flows between security domains on connected systems.
|-
|[[Practice_AC.L3-3.1.3e_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L3-3.2.1e – Advanced Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide awareness training upon initial hire, following a significant cyber event, and at least annually, focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training at least annually or when there are significant changes to the threat.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified;
: [b] Awareness training focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors is provided upon initial hire, following a significant cyber event, and at least annually;
: [c] Significant changes to the threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors are identified; and
: [d] Awareness training is updated at least annually or when there are significant changes to the threat.
|-
|[[Practice_AT.L3-3.2.1e_Details|More Practice Details...]]
|}
=== AT.L3-3.2.2e – Practical Training Exercises ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Include practical exercises in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users, that are aligned with current threat scenarios and provide feedback to individuals involved in the training and their supervisors.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Practical exercises are identified;
: [b] Current threat scenarios are identified;
: [c] Individuals involved in training and their supervisors are identified;
: [d] Practical exercises that are aligned with current threat scenarios are included in awareness training for all users, tailored by roles, to include general users, users with specialized roles, and privileged users; and
: [e] Feedback is provided to individuals involved in the training and their supervisors.
|-
|[[Practice_AT.L3-3.2.2e_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L3-3.4.1e – Authoritative Repository ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Approved system components are identified;
: [b] Implemented system components are identified;
: [c] An authoritative source and repository are established to provide a trusted source and accountability for approved and implemented system components; and
: [d] An authoritative source and repository are maintained to provide a trusted source and accountability for approved and implemented system components.
|-
|[[Practice_CM.L3-3.4.1e_Details|More Practice Details...]]
|}
=== CM.L3-3.4.2e – Automated Detection & Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, remove the components or place the components in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Automated mechanisms to detect misconfigured or unauthorized system components are identified;
: [b] Automated mechanisms are employed to detect misconfigured or unauthorized system components;
: [c] Misconfigured or unauthorized system components are detected; and
: [d] After detection, system components are removed or placed in a quarantine or remediation network to facilitate patching, re-configuration, or other mitigations.
|-
|[[Practice_CM.L3-3.4.2e_Details|More Practice Details...]]
|}
=== CM.L3-3.4.3e – Automated Inventory ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Automated discovery and management tools for the inventory of system components are identified;
: [b] An up-to-date, complete, accurate, and readily available inventory of system components exists; and
: [c] Automated discovery and management tools are employed to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|-
|[[Practice_CM.L3-3.4.3e_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L3-3.5.1e – Bidirectional Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify and authenticate systems and system components, where possible, before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP1] Systems and system components to identify and authenticate are defined;
: [a] Bidirectional authentication that is cryptographically-based is implemented;
: [b] Bidirectional authentication that is replay-resistant is implemented; and
: [c] Systems and system components, where possible, are identified and authenticated before establishing a network connection using bidirectional authentication that is cryptographically-based and replay-resistant.
|-
|[[Practice_IA.L3-3.5.1e_Details|More Practice Details...]]
|}
=== IA.L3-3.5.3e – Block Untrusted Assets ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] System components that are known, authenticated, in a properly configured state, or in a trust profile are identified;
: [b] Automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems are identified; and
: [c] Automated or manual/procedural mechanisms are employed to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|-
|[[Practice_IA.L3-3.5.3e_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L3-3.6.1e – Security Operations Center ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain a security operations center capability that operates 24/7, with allowance for remote/on-call staff.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] A security operations center capability is established;
: [b] The security operations center capability operates 24/7, with allowance for remote/on-call staff; and
: [c] The security operations center capability is maintained.
|-
|[[Practice_IR.L3-3.6.1e_Details|More Practice Details...]]
|}
=== IR.L3-3.6.2e – Cyber Incident Response Team ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain a cyber incident response team that can be deployed by the organization within 24 hours.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] A cyber incident response team is established;
: [b] The cyber incident response team can be deployed by the organization within 24 hours; and
: [c] The cyber incident response team is maintained.
|-
|[[Practice_IR.L3-3.6.2e_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L3-3.9.2e – Adverse Information ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Individuals with access to CUI are identified;
: [b] Adverse information about individuals with access to CUI is defined;
: [c] Organizational systems to which individuals have access are identified; and
: [d] Mechanisms are in place to protect organizational systems if adverse information develops or is obtained about individuals with access to CUI.
|-
|[[Practice_PS.L3-3.9.2e_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L3-3.11.1e – Threat-Informed Risk Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, as part of a risk assessment to guide and inform the development of organizational systems, security architectures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP1] Sources of threat intelligence are defined;
: [a] A risk assessment methodology is identified;
: [b] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform the development of organizational systems and security architectures;
: [c] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform the selection of security solutions;
: [d] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform system monitoring activities;
: [e] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform threat hunting activities; and
: [f] Threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources, are employed as part of a risk assessment to guide and inform response and recovery activities.
|-
|[[Practice_RA.L3-3.11.1e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.2e – Threat Hunting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Conduct cyber threat hunting activities on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems and detect, track, and disrupt threats that evade existing controls.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP4] Organizational systems to search for indicators of compromise are defined;
: [a] Indicators of compromise are identified;
: [b] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when indications warrant, to search for indicators of compromise in organizational systems; and
: [c] Cyber threat hunting activities are conducted on an on-going aperiodic basis or when indications warrant, to detect, track, and disrupt threats that evade existing controls.
|-
|[[Practice_RA.L3-3.11.2e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.3e – Advanced Risk Identification ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Advanced automation and analytics capabilities to predict and identify risks to organizations, systems, and system components are identified;
: [b] Analysts to predict and identify risks to organizations, systems, and system components are identified; and
: [c] Advanced automation and analytics capabilities are employed in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|[[Practice_RA.L3-3.11.3e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.4e – Security Solution Rationale ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] The system security plan documents or references the security solution selected;
: [b] The system security plan documents or references the rationale for the security solution; and
: [c] The system security plan documents or references the risk determination.
|-
|[[Practice_RA.L3-3.11.4e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.5e – Security Solution Effectiveness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Assess the effectiveness of security solutions at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Security solutions are identified;
: [b] Current and accumulated threat intelligence is identified;
: [c] Anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence is identified; and
: [d] The effectiveness of security solutions is assessed at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident, to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|[[Practice_RA.L3-3.11.5e_Details|More Practice Details...]]
|}

=== RA.L3-3.11.6e – Supply Chain Risk Response ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Supply chain risks associated with organizational systems and system components are identified;
: [b] Supply chain risks associated with organizational systems and system components are assessed;
: [c] Supply chain risks associated with organizational systems and system components are responded to; and
: [d] Supply chain risks associated with organizational systems and system components are monitored.
|-
|[[Practice_RA.L3-3.11.6e_Details|More Practice Details...]]
|}
=== RA.L3-3.11.7e – Supply Chain Risk Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Supply chain risks associated with organizational systems and system components are identified;
: [b] Organizational systems and system components to include in a supply chain risk management plan are identified;
: [c] A plan for managing supply chain risks associated with organizational systems and system components is developed; and
: [d] The plan for managing supply chain risks is updated at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident.
|-
|[[Practice_RA.L3-3.11.7e_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L3-3.12.1e – Penetration Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Automated scanning tools are identified;
: [b] Ad hoc tests using subject matter experts are identified; and
: [c] Penetration testing is conducted at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.
|-
|[[Practice_CA.L3-3.12.1e_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L3-3.13.4e – isolation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ physical isolation techniques or logical isolation techniques or both in organizational systems and system components.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP1] One or more of the following is/are selected: physical isolation techniques; logical isolation techniques;
: [ODP2] Physical isolation techniques are defined (if selected);
: [ODP3] Logical isolation techniques are defined (if selected);
: [a] Physical isolation techniques or logical isolation techniques or both are employed in organizational systems and system components.
|-
|[[Practice_SC.L3-3.13.4e_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L3-3.14.1e – Integrity Verification ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify the integrity of security critical and essential software using root of trust mechanisms or cryptographic signatures.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP1] Security critical or essential software is defined;
: [a] Root of trust mechanisms or cryptographic signatures are identified; and
: [b] The integrity of security critical and essential software is verified using root of trust mechanisms or cryptographic signatures.
|-
|[[Practice_SI.L3-3.14.1e_Details|More Practice Details...]]
|}
=== SI.L3-3.14.3e – Specialized Asset Security ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment are included in the scope of the specified enhanced security requirements or are segregated in purpose-specific networks.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [a] Specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment are included in the scope of the specified enhanced security requirements; and
: [b] Systems and system components that are not included in specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems and test equipment are segregated in purpose-specific networks.
|-
|[[Practice_SI.L3-3.14.3e_Details|More Practice Details...]]
|}
=== SI.L3-3.14.6e – Threat-Guided Intrusion Detection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources, and any DoD-provided sources, to guide and inform intrusion detection and threat hunting.
|-
|'''ASSESSMENT OBJECTIVES'''
Determine if:
: [ODP1] External organizations from which to obtain threat indicator information and effective mitigations are defined;
: [a] Threat indicator information is identified;
: [b] Effective mitigations are identified;
: [c] Intrusion detection approaches are identified;
: [d] Threat hunting activities are identified; and
: [e] Threat indicator information and effective mitigations obtained from, at a minimum, open or commercial sources and any DoD-provided sources, are used to guide and inform intrusion detection and threat hunting.
|-
|[[Practice_SI.L3-3.14.6e_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| ACL || Access Control List
|-
|| ACM || Automated Configuration Management
|-
|| ACMS || Automated Configuration Management System
|-
|| APT || Advanced Persistent Threat
|-
|| AT || Awareness and Training
|-
|| C3PAO || CMMC Third-Party Assessment Organization
|-
|| CA || Certification Authority
|-
|| CA || Security Assessment
|-
|| CERT || Computer Emergency Response Team
|-
|| CFR || Code of Federal Regulations
|-
|| CIO || Chief Information Officer
|-
|| CIRT || Computer Incident Response Team; Cyber Incident Response Team
|-
|| CISO || Chief Information Security Officer
|-
|| CM || Configuration Management
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| DCSA || Defense Counterintelligence and Security Agency
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DIB || Defense Industrial Base
|-
|| DLP || Data Loss Prevention
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| DRM || Digital Rights Management
|-
|| ESP || External Service Provider
|-
|| FIPS || Federal Information Processing Standard
|-
|| GFE || Government Furnished Equipment
|-
|| GPO || Group Policy Object
|-
|| HR || Human Resources
|-
|| IA || Identification and Authentication
|-
|| ICS || Industrial Control System
|-
|| IIoT || Industrial Internet of Things
|-
|| IOC || Indicators of Compromise
|-
|| IoT || Internet of Things
|-
|| IP || Internet Protocol
|-
|| IR || Incident Response
|-
|| ISAC || Information Sharing and Analysis Center
|-
|| ISAO || Information Sharing and Analysis Organization
|-
|| IT || Information Technology
|-
|| MLS || Multi-Level Secure
|-
|| N/A || Not Applicable
|-
|| NAC || Network Access Control
|-
|| NIST || National Institute of Standards and Technology
|-
|| ODP || Organization-Defined Parameters
|-
|| OS || Operating System
|-
|| OT || Operational Technology
|-
|| PKI || Public Key Infrastructure
|-
|| PS || Personnel Security
|-
|| RA || Risk Assessment
|-
|| SC || System and Communications Protection
|-
|| SCADA || Supervisory Control and Data Acquisition
|-
|| SCRM || Supply Chain Risk Management
|-
|| SI || System and Information Integrity
|-
|| SIEM || Security Information and Event Management
|-
|| SOAR || Security Orchestration, Automation, and Response
|-
|| SOC || Security Operations Center
|-
|| SP || Special Publication
|-
|| SSP || System Security Plan
|-
|| TEE || Trusted Execution Environment
|-
|| TLS || Transport Layer Security
|-
|| TPM || Trusted Platform Module
|-
|| TTP || Tactics, Techniques, and Procedures
|-
|| UEFI || Unified Extensible Firmware Interface
|-
|| USB || Universal Serial Bus
|-
|| VLAN || Virtual Local Area Network
|-
|| VPN || Virtual Private Network
|-
|| XDR || Extended Detection and Response
|}

Level 3 Scoping Guidance

2026-03-02T01:30:33Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 3 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing CMMC requirements under the law or departmental policies. DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 3 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR). Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document. Guidance for scoping a Level 2 self-assessment or certification assessment can be found in the ''CMMC Scoping Guide – Level 2'' document. More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Certification (OSCs) that will be obtaining a Level 3 certification assessment and the professionals or companies that will support them in those efforts.

== Identifying the CMMC Assessment Scope ==
An ''assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment. The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a Level 3 certification assessment, the CMMC Assessment Scope must be defined as addressed in 32 CFR § 170.19(d). The CMMC Assessment Scope informs which assets within the OSC’s environment will be assessed and the details of the assessment.

When seeking a Level 3 certification assessment, the OSC must have a Final Level 2 (C3PAO) CMMC Status for the same CMMC Assessment Scope as the Level 3 assessment. Any Level 2 Plan of Action and Milestones (POA&M) items, as defined in 32 CFR §170.4, must be closed prior to the initiation of the Level 3 assessment. The Level 3 CMMC Assessment Scope may be a subset of the Level 2 CMMC Assessment Scope (e.g., a Level 3 data enclave with greater restrictions and protections within the Level 2 data enclave).

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment Scope. OSCs may choose to designate them as CUI assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment. During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment, will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC Level 3 certification assessment and will be assessed against all CMMC Level 3 security requirements.

=== CMMC Asset Categories ===
For a Level 3 assessment, assets are mapped into one of four categories defined in 32 CFR § 170.19(d)(1) Table 4. This table describes each asset category and its corresponding OSC requirements and CMMC assessment requirements. Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="margin:auto"
|+ '''Table 1. Level 3 Asset Categories and Associated Requirements Overview'''
|-
!colspan="4"|'''Assets that are in the Level 3 CMMC Assessment Scope'''
|-
! Asset Category !! Asset Description !! OSC Requirements !! CMMC Assessment Requirements
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
* Assets that can, but are not intended to, process, store, or transmit CUI (defined as Contractor Risk Managed Assets in Table 1 to 32 CFR § 170.19(c)(1))
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 and Level 3 security requirements
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements
|-
|
'''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSC’s CMMC Assessment Scope, irrespective of whether or not these assets process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 and Level 3 security requirements
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements that are relevant to the capabilities provided
|-
|
'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 and Level 3 security requirements
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements
* Intermediary devices are permitted to provide the capability for the specialized asset to meet one or more CMMC security requirements
|-
!colspan="4"|'''Assets that are not in the Level 3 CMMC Assessment Scope'''
|-
|
'''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUI Assets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 3 Scoping ==
The OSC is required to document all assets that are part of the Level 3 certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets can process, store, or transmit CUI as follows:
* '''Process'''– CUI is used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store'''– CUI is inactive or at rest on an asset (e.g., located on electronic media or in physical format such as paper documents).
* '''Transmit'''– CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSC is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSC’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against all Level 2 and Level 3 security requirements that are relevant to the capabilities provided. For example, an External Service Provider (ESP) that provides a security information and event management (SIEM) service may be separated logically and may process no CUI, but the SIEM contributes to meeting the CMMC requirements within the OSC’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system. It includes, but is not limited to:

* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSC is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 3 certification assessment:
* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSC-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A<ref>NIST SP800-172A March 2022</ref>. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the Level 3 CMMC Assessment Scope per 32 CFR § 170.19(d)(1) Table 3. Note that Specialized Assets may be eligible for an Enduring Exception. The OSC should prepare for these assets to be assessed against all CMMC requirements unless they are physically or logically isolated into purpose-specific networks (with no connection to the Internet or other networks). Specialized Assets may have limitations on the application of certain security requirements. To accommodate such issues intermediary devices are permitted to provide the capability for the specialized asset to meet one or more CMMC requirements. An example of an intermediary device used in conjunction with a specialized asset is a boundary device or a proxy.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(d)(1), Out-of-Scope Assets are not part of a Level 3 certification assessment. There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSC then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSC’s environment that will be assessed in accordance with [[Level_3_Scoping_Guidance#CMMC Asset Categories|Table 1]]. OSCs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor. Details about required documentation for each asset category can be found in the [[Level_3_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 3 CMMC Assessment Scope: 
* CUI Assets
* Security Protection Assets
* Specialized Assets

Self-assessments and certification assessments are valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping. A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP do not require a new assessment, but rather are covered by the annual affirmations to the continuing compliance with requirements.

== External Service Provider Considerations ==
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(d)(2). Special considerations in for an OSC using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security control objectives that are the provider’s responsibility and security control objectives that are the OSC’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSC’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
*** Use of a CSP does not relieve an OSC of its obligation to implement the 24 Level 3 security requirements. These 24 requirements apply to every environment where the CUI data is processed, stored, or transmitted, when Level 3 (DIBCAC) is the designated CMMC Status. If any of these 24 requirements are inherited from a CSP, the OSC must demonstrate that protection during a Level 3 certification assessment via a Customer Implementation Summary/Customer Responsibility Matrix (CIS/CRM) and associated Body of Evidence (BOE). The BOE must clearly indicate whether the OSC or the CSP is responsible for meeting each requirement and which requirements are implemented versus inherited.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012. Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a DIBCAC assessment, and the DIBCAC may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2 or Level 3, as applicable, against their on-premise infrastructure connecting to the ESP. As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

An ESP may voluntarily request its own Level 3 assessment by contacting the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC). Contact information can be found[https://www/ at https://www.dc]ma.mil/DIBCAC/.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

== Notes ==
<references />

Level 2 Assessment Guide

2026-03-02T01:30:21Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified; and
: [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Level 2 Scoping Guidance

2026-03-02T01:30:10Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us].Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.This document is intended only to provide clarity to the public
regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A.Approved for public release.Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 2 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR).Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document.Guidance for scoping a Level 3 certification assessment can be
found in the ''CMMC Scoping Guide – Level 3'' document.More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 2 self-assessment in accordance with 32 CFR § 170.16, Organizations Seeking Certification (OSCs) that will be obtaining a Level 2 certification assessment in accordance with 32 CFR § 170.17, and the professionals or companies that will support them in those
efforts.The security requirements for a Level 2 self-assessment and a Level 2 certification assessment are the same, the only difference in these assessments is whether it is conducted by the OSA or by an independent C3PAO.

OSCs are a subset of OSAs as all organizations will participate in an assessment, but self-assessment cannot result in a certification.

=== Identifying the CMMC Assessment Scope ===
An ''Assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment.The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a CMMC assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(c).The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the assessment.

Because the scoping of a Level 2 assessment is not the same as the scoping of a Level 3 assessment, before determining the CMMC Assessment Scope it is important to first consider if the organization will seek a CMMC Status of Final Level 3 (DIBCAC).If the intent is to obtain a CMMC Status of Final Level 3 (DIBCAC), the OSC should also consider the guidance provided in the ''CMMC Scoping Guide – Level 3'' document.The OSC must closeout any Level 2 Plan of Action and Milestones (POA&M) and achieve a CMMC Status of Final Level 2 (C3PAO) prior to initiating a Level 3 certification assessment.

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment
Scope. OSCs may choose to designate them as CUI Assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment.During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC certification assessment.

== CMMC Asset Categories ==
For a Level 2 assessment, assets are mapped into one of five categories defined in 32 CFR § 170.19(c)(1) Table 3. This table describes each asset category and its corresponding OSA requirements and CMMC assessment requirements.Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="width: 85%;"
|+ Table 1. CMMC Asset Categories and Associated Requirements Overview
! style="width: 16%"| '''Asset Category'''
! style="width: 28%"| '''Asset Description'''
! style="width: 28%"| '''OSA Requirements'''
! style="width: 28%"| '''CMMC Assessment Requirements'''
|-
| colspan="4" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against all Level 2 security requirements
|-
| '''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope
|
* Document in the asset inventory
* Document asset treatment in SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against Level 2 security requirements that are relevant to the capabilities provided
|-
| '''Contractor Risk Managed Assets'''
|
* Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
* Assets are not required to be physically or logically separated from CUI assets
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC security requirements, except as noted
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost
** The limited check(s) will be assessed against CMMC security requirements
|-
|'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
** Show these assets are managed using the contractor's risk-based security policies
* Document in the network diagram of the CMMC Assessment Scope
|
* Review the SSP
* Do not assess against other CMMC security requirements
|-
| colspan="4" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|-
| '''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUIassets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 2 Scoping ==
The OSA is required to document all asset categories that are part of the Level 2 self-assessment or certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets process, store, or transmit CUI as follows:
* '''Process''' – CUI can be used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – CUI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the System Security Plan (SSP);
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSA’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against Level 2 security requirements that are relevant to the capabilities provided.For example, an External Service Provider (ESP), defined in 32 CFR §170.4, that provides a security information and event management (SIEM) service may be separated logically and may not process CUI, but the SIEM does contribute to meeting the CMMC requirements within the OSA’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system.It includes, but is not limited to:
* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Contractor Risk Managed Assets ===
Contractor Risk Managed Assets are not intended to, but are capable of processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

Contractor Risk Managed Assets are part of the Level 2 CMMC Assessment Scope. These assets are managed using the OSA’s risk-based information security policy, procedures, and practices. Furthermore, the assets must be assessed against CMMC requirements if insufficiently documented in the SSP or if the OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets.In these cases, the assessor can conduct a limited check to identify deficiencies.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

Assessment requirements for Contractor Risk Managed Asset are detailed in Table 1.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 2 assessment when documented in accordance with Table 1 (reprinted from 32 CFR § 170.19(c)(1) Table 3). Note that a Specialized Asset may be eligible for an Enduring Exception.

* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSA-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the CMMC Assessment Scope.In accordance with 32 CFR § 170.19(c)(1) Table 3, the OSA shall document these assets in the SSP and detail how they are managed using the OSA’s risk-based information security policy, procedures, and practices.

In addition, the OSA is required to:
* document each asset in asset inventory; there is no requirement to embed every asset in the SSP;
* document these assets in the SSP to show they are managed using the OSA’s risk-based security policies, procedures, and practices; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

An assessor will review the SSP to verify that specialized assets are managed using the OSA’s risk-based information security policy, procedures, and practices, and accounted for within the OSA’s CMMC Assessment Scope.The assessor will not retain a copy of the SSP.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(c)(1), Out-of-Scope Assets are not part of a Level 2 self-assessment or certification assessment.There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSA then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSA’s environment that will be assessed in accordance with Table 1. OSAs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor.Details about required documentation for each asset category can be found in the [[Level_2_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 2 CMMC Assessment Scope:
* CUI Assets
* Security Protection Assets
* Contractor Risk Managed Assets
* Specialized Assets

=== Separation Techniques ===
Separation is a system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI. Effective separation involves logically or physically separating assets and is required only for Out-of-Scope Assets. By separating assets, the CMMC Assessment Scope can be limited. Effective separation for CMMC follows the guidance in NIST SP 800-171 Rev 2, which states:

''If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms).Security domains may employ physical separation, logical separation, or a combination of both. This approach can provide adequate security for the CUI and avoid increasing the organization’s security posture to a level beyond that which it requires for protecting its missions, operations, and assets.''

'''Logical separation''' occurs when data transfer between physically connected assets (wired or wireless) is prevented by non-physical means such as software or network assets (e.g., firewall, routers, VPNs, VLANs).

'''Physical separation''' occurs when assets have no connection (wired or wireless). Data can only be transferred manually (e.g., USB drive).

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping. A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP, do not require a new assessment, but rather may be covered by annual affirmations to the continuing compliance with requirements.

=== External Service Provider Considerations ===
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI Asset and/or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(c)(2). Special considerations for an OSA using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security requirement objectives that are the provider’s responsibility and security requirement objectives that are the OSA’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSA’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012.Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a C3PAO assessment, and a C3PAO may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2, as applicable, against their on-premise infrastructure connecting to the CSP.As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

=== Use Cases ===
'''FCI and CUI in the Same Assessment Scope'''

A Level 2 self-assessment or Level 2 certification assessment satisfies the Level 1 self-assessment requirements for the same CMMC Assessment Scope.If FCI is processed, stored, or transmitted within the same scope as CUI in the Level 2 scope, then the methods to implement the Level 2 security requirements apply towards meeting the Level 1 assessment objectives. The OSA is responsible for ensuring that only authorized users and processes have access to data regardless of its designation.

'''FCI and CUI in Different Assessment Scopes'''

If FCI and CUI do not share an environment, the two assessments would be conducted independently and methods to implement security requirements in one scope would not apply to the other scope.

'''Use of Enclaves'''

Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise.This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope.For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool.Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope.

Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way.

There is no established metric for inherited implementations from an enterprise to any defined enclaves.The OSA determines the architecture that best meets its business needs and complies with CMMC requirements.

'''Security Protection Data'''

Security Protection Data (SPD) can be created by or used by a Security Protection Asset (SPA).Aggregated logs in a SIEM are one example of SPD and the SIEM is considered the SPA. The SIEM is part of the assessment scope.Because of the wide range of SIEM tools available, (on-premise hardware appliance; on-premise virtual appliance; or cloud based), methods of assessing the SIEM will also vary. If the SIEM and/or associated log data is hosted or maintained by an ESP, then the portion of the ESP that is used to provide the SIEM service or log storage is part of the OSA’s assessment scope.SIEM logs are typically available in hot storage for some period of time as part of the SIEM deployment.In this case, the SPD is collocated with the SPA.Cold storage of logs for a longer period of time is typically done offline or in cloud storage.The method used and the location of the cold storage are also in the OSA’s assessment scope.

== Notes ==
<references />

Level 1 Self-Assessment Guide

2026-03-02T01:29:55Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 1 Self-Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and execution of a Level 1 self-assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.15 of title 32, Code of Federal Regulations (CFR). Guidance for conducting a Level 2 self-assessment or certification assessment can be found in ''CMMC Assessment Guide – Level 2''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC Assessment Guide – Level 3''. More details on the CMMC Model can be found in ''CMMC Model Overview''.

Level 1 focuses on the protection of Federal Contract Information (FCI), which is defined in 32 CFR § 170.4 and 48 CFR § 4.1901:

: ''Federal contract information means information, not intended for public release, that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government, but not including information provided by the Government to the public (such as on public websites) or simple transactional information, such as necessary to process payments.''

Level 1 is comprised of the 15 basic safeguarding requirements specified in Federal Acquisition Regulation (FAR) Clause 52.204-21.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs), cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 1 self-assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Compliance:''' provides an overview of the Level 1 self-assessment process set forth in 32 CFR § 170.15, describes ways of documenting compliance, and provides guidance regarding OSA size and the self-assessment scope requirements set forth in 32 CFR § 170.19.
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') that may be employed during a Level 1 self-assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 1 security requirement.

== Assessment and Compliance ==
Level 1 self-assessment requirements are set forth in 32 CFR § 170.15. The OSA will assess its own contractor information system(s) to determine if it meet all the basic safeguarding requirements for FCI specified in FAR Clause 52.204-21. OSAs should use the self-assessment methods as described in 32 CFR § 170.15.

Level 1 requirements may apply to an entire enterprise infrastructure or to a particular enclave(s), depending upon where the FCI will be processed, stored, or transmitted.

OSAs can choose to perform the annual self-assessment internally or engage a third party to assist. Use of a third party to assist is still considered a self-assessment and does not result in a certification. The primary result of a self-assessment is the submission of Level 1 compliance results into the Supplier Performance Risk System (SPRS) and a self-assessment report, which contains the findings associated with the self- assessment.

=== Assessment Scope ===
Prior to conducting a Level 1 self-assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(a). The CMMC Assessment Scope identifies which assets within the OSA’s environment will be assessed and the details of the self-assessment. In accordance with §170.19, for a Level 1 self-assessment, the assets that process, store, or transmit FCI are considered in-scope and should be assessed against the Level 1 requirements. See the ''CMMC Scoping Guide – Level 1 ''document for additional information.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The custom terms associated with Level 1 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** Level 1 self-assessment is the term for the activity performed by an OSA to evaluate its own information system, when seeking a CMMC Status of Final Level 1 (Self).
* '''Assessment Objective:''' A set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** Final Level 1 (Self) is defined in § 170.15(c)(1). To achieve a CMMC Status of Final Level 1 (Self) the OSA must conduct a Level 1 self-assessment scored in accordance with the CMMC Scoring Methodology described in § 170.24. The Level 1 self-assessment must be performed in accordance with the Level 1 scope requirements set forth in § 170.19(a) and (b). In instances where an objective addresses CUI, the term FCI should be substituted for CUI.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' A special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Information System (IS):''' A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information [NIST 800-171 Rev. 2]. An ''IS'' is one type of ''asset''.''' '''
* '''Monitoring:''' Continual checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected [NIST SP 800-160 Vol 1].
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-Defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology==
This ''CMMC Assessment Guide – Level 1'' provides guidance regarding the assessment procedures required by 32 CFR § 170.15, which requires the Level 1 self-assessment to be performed using the objectives defined in NIST Special Publication (SP) 800-171A<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information, ''June 2018 (italics and bulleted list formatting altered)</ref>. NIST SP 800-171A Section 2.1 says the following:

: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
* ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, and architectural designs) associated with a system.''
* ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
* ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
* ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

''The assessment methods define the nature and the extent of the assessor’s actions. The methods include'' examine, interview, ''and'' test.
* ''The'' examine ''method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
* ''The'' interview ''method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
* ''And finally, the'' test ''method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

The guidance specified in NIST SP 800-171A focuses on Controlled Unclassified Information (CUI). Since Level 1 focuses on safeguarding FCI, the applicable self-assessment objectives for Level 1 are modified to address FCI rather than CUI as set forth in 32 CFR § 170.15(c)(1)(i). Where '''CUI''' is noted in a NIST SP 800-171A assessment objective, '''[FCI]''' has been substituted in the Level 1 objective description. Level 1 security requirement descriptions align with FAR Clause 52.204-21.

=== Criteria ===
Assessment objectives are provided for each Level 1 requirement and are based on existing criteria in NIST SP 800-171A modified for FCI rather than CUI as set forth in 32 CFR § 170.15(c)(1)(i). The criteria are authoritative and provide the basis for the self-assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 1 requirements. Because different self-assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 1 requirements, including any of the three assessment methods from NIST SP 800-171A.

Follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [OSAs] are not expected to employ all assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the [FCI] requirements have been satisfied.''

For more detailed information on assessment methods, see NIST SP 800-171A Appendix D.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an entity determine if Level 1 security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to implement the security requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist an entity in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. As set forth in 32 CFR § 170.24, documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.

In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. Not all security requirements utilize testing to allow an entity to determine if whether the assessment objective has been met.

=== Assessment Findings ===
The self-assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To demonstrate Level 1 compliance, the OSA will need a finding of MET or NOT APPLICABLE on all Level 1 security requirements.
* '''MET''': All applicable objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives of the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective do not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, SC.L1-b.1.xi might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.

Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.

CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET Assessment Objective results in a failure of the entire security requirement.

A security requirement can be applicable even when assessment objectives included in the security requirement are scored N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.

Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or ESP implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 1 security requirement. The section is organized first by domain and then by individual security requirement. Each security requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L1-b.1.i); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the self-assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Self-assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement. Level 1 aligns with FAR Clause 52.204-21, which focuses on FCI, and the NIST text has been modified, as set forth in 32 CFR § 170.15(c)(1), to reflect this.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not intended to be prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a,d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the identical basic safeguarding requirement from FAR clause 52.204-21 and the pertinent security requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L1-B.1.I – Authorized Access Control [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L1-B.1.II – Transaction & Function Control [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L1-B.1.III – External Connections [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L1-B.1.IV – Control Public Information [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure FCI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include FCI; and
: [e] mechanisms are in place to remove and address improper posting of FCI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L1-B.1.V – Identification [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L1-B.1.VI – Authentication [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L1-B.1.VII – Media Disposal [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing FCI is sanitized or destroyed before disposal; and
: [b] system media containing FCI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L1-B.1.VIII – Limit Physical Access [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L1-B.1.IX – Manage Visitors & Physical Access [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L1-B.1.X – Boundary Protection [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[DoD_Assessment_Methodology|DoD Assessment Scoring Value]]: '''5'''
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L1-B.1.XI – Public-Access System Separation [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L1-B.1.XII – Flaw Remediation [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L1-B.1.XIII – Malicious Code ProTection [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L1-B.1.XIV – Update Malicious Code Protection [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L1-B.1.XV – System & File Scanning [FCI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Level 1 Scoping Guidance

2026-03-02T01:29:41Z

David:

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 1 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmcwiki.org contact us]. Thank you.

== NOTICES ==

The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 1 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR). Guidance for scoping a Level 2 self-assessment or certification assessment can be found in the ''CMMC Scoping Guide – Level 2 '' document. Guidance for scoping a Level 3 certification assessment can be found in the ''CMMC Scoping Guide – Level 3'' document. More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 1 self-assessment and the professionals or companies that will support them in those efforts.

== Identifying the CMMC Assessment Scope ==
=== Level 1 Assessment Scope ===
Prior to a Level 1 self-assessment the OSA must specify the CMMC Assessment Scope. The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the self-assessment. There are no documentation requirements for Level 1 self-assessments including In-Scope, Out-of-Scope, and Specialized Assets.

==== In-Scope Assets ====
Assets in scope for a Level 1 self-assessment, as defined in 32 CFR § 170.19(b), are all assets that process, store, or transmit Federal Contract Information (FCI).
* '''Process''' – FCI is used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – FCI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – FCI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

These assets are part of the CMMC Assessment Scope and are assessed against all Level 1 requirements.

==== Out-of-Scope Assets ====
Assets out of scope for a Level 1 self-assessment, as defined in 32 CFR § 170.19(b)(2), are those that do not process, store, or transmit FCI. These assets are outside of the CMMC Assessment Scope and are not part of the assessment.

=== ''Specialized Assets'' ===
Specialized Assets, as defined in 32 CFR § 170.19(b)(2)(ii), are those assets that can process, store, or transmit FCI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment. Specialized Assets are not part of the Level 1 self-assessment scope and are not assessed against CMMC requirements. The following assets, defined in 32 CFR § 170.4, are considered specialized assets for a Level 1 self-assessment.
* '''Government Furnished Equipment''' (GFE) has the same meaning as “government-furnished property” as defined in 48 CFR § 45.101. Government-furnished property means property in the possession of, or directly acquired by, the Government and subsequently furnished to the contractor for performance of a contract. Government-furnished property includes, but is not limited to, spares and property furnished for repair, maintenance, overhaul, or modification. Government-furnished property also includes contractor-acquired property if the contractor-acquired property is a deliverable under a cost contract when accepted by the Government for continued use under the contract.
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' is defined is NIST SP800-172A. These are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors [Reference: iot.ieee.org/definition; National Institute of Standards and Technology (NIST) 800-183].
* '''Operational Technology (OT)'''<ref>Operational Technology includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: NIST SP 800-160v2 Rev 1] NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: NIST SP 800-82r3]
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based entirely on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables.

== Additional Guidance on Level 1 Scoping ==
In accordance with 32 CFR § 170.19(b)(3), to appropriately scope a Level 1 self-assessment, the OSA should consider the people, technology, facilities, and external service providers within its environment that process, store, or transmit FCI.
* '''People''' – May include, but are not limited to, employees, contractors, vendors, and external service provider personnel.
* '''Technology''' – May include, but are not limited to, servers, client computers, mobile devices, network appliances (e.g., firewalls, switches, APs, and routers), VoIP devices, applications, virtual machines, and database systems.
* '''Facilities''' – May include, but are not limited to, physical office locations, satellite offices, server rooms, datacenters, manufacturing plants, and secured rooms.
* '''External Service Provider (ESP) '''–''' '''as defined in''' '''32 CFR § 170.4, means external people, technology, or facilities that an OSA utilizes for provision and management of comprehensive IT and/or cybersecurity services on behalf of the OSA.

In accordance with 32 CFR § 170.19(b)(1), assets that process, store, or transmit FCI and which are not Specialized Assets are in the CMMC Assessment Scope. Using the asset types approach allows an OSA to determine how they will satisfy the Level 1 requirements. FCI is a broad category of information; therefore, the self-assessment may need to address a wide array of assets.

For example, identifying the people within the OSA who process, store, or transmit FCI, will assist with fulfillment of the assessment of the following Level 1 security requirement:
* ''IA.L1-b.1.v – Identify information system users, processes acting on behalf of users, or devices.''

As another example, identification of all technologies may inform assessment of the following Level 1 security requirements:
* ''AC.L1-b.1.iii – Verify and control/limit connections to and use of external information systems.''
* ''SC.L1-b.1.x – Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.''

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping. A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP<ref>It is recommended that an OSA develop a SSP as a best practice at Level 1. However, it is not required in order to conduct a Level 1 self-assessment.</ref> do not require a new assessment, but rather are covered by the annual affirmations to the continuing compliance with requirements.

== Notes ==
<references />

Certification Practice Quiz

2026-03-02T01:29:21Z

David:

'''Certification Practice Quiz Instructions'''

The practice quiz will have questions drawn randomly from the questions bank. There is NO pass, fail, or any sort of grading after taking the quiz.

At the end of the quiz, you can review your answers. Once you have exited the review process, you will not be able to go back and check on it again.

You are welcome to retake the quiz as many times as you like. Each set of questions will be random and likely different. The quiz will NOT ask for personal information such as your name or email address.

The sole purpose of the practice quizzes is to enhance the learners’ understanding of the CMMC model and its ecosystem. I hope you will find the quizzing tool educational and helpful in learning CMMC.

For reporting errors on the quiz questions, please [mailto:support@cmmcwiki.org contact us]. Thank you.

'''[https://www.flexiquiz.com/SC/N/cmmcwiki-ccp-quiz Practice with the CCP Quiz (20 questions), hosted by FlexiQuiz]'''

'''[https://www.flexiquiz.com/SC/N/cmmcwiki-ccp-40q Practice with the CCP Quiz (40 questions), hosted by FlexiQuiz]'''

Level 2 Scoping Guidance

2026-02-23T18:31:00Z

David: /* Separation Techniques */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us].Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.This document is intended only to provide clarity to the public
regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A.Approved for public release.Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 2 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR).Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document.Guidance for scoping a Level 3 certification assessment can be
found in the ''CMMC Scoping Guide – Level 3'' document.More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 2 self-assessment in accordance with 32 CFR § 170.16, Organizations Seeking Certification (OSCs) that will be obtaining a Level 2 certification assessment in accordance with 32 CFR § 170.17, and the professionals or companies that will support them in those
efforts.The security requirements for a Level 2 self-assessment and a Level 2 certification assessment are the same, the only difference in these assessments is whether it is conducted by the OSA or by an independent C3PAO.

OSCs are a subset of OSAs as all organizations will participate in an assessment, but self-assessment cannot result in a certification.

=== Identifying the CMMC Assessment Scope ===
An ''Assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment.The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a CMMC assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(c).The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the assessment.

Because the scoping of a Level 2 assessment is not the same as the scoping of a Level 3 assessment, before determining the CMMC Assessment Scope it is important to first consider if the organization will seek a CMMC Status of Final Level 3 (DIBCAC).If the intent is to obtain a CMMC Status of Final Level 3 (DIBCAC), the OSC should also consider the guidance provided in the ''CMMC Scoping Guide – Level 3'' document.The OSC must closeout any Level 2 Plan of Action and Milestones (POA&M) and achieve a CMMC Status of Final Level 2 (C3PAO) prior to initiating a Level 3 certification assessment.

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment
Scope. OSCs may choose to designate them as CUI Assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment.During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC certification assessment.

== CMMC Asset Categories ==
For a Level 2 assessment, assets are mapped into one of five categories defined in 32 CFR § 170.19(c)(1) Table 3. This table describes each asset category and its corresponding OSA requirements and CMMC assessment requirements.Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="width: 85%;"
|+ Table 1. CMMC Asset Categories and Associated Requirements Overview
! style="width: 16%"| '''Asset Category'''
! style="width: 28%"| '''Asset Description'''
! style="width: 28%"| '''OSA Requirements'''
! style="width: 28%"| '''CMMC Assessment Requirements'''
|-
| colspan="4" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against all Level 2 security requirements
|-
| '''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope
|
* Document in the asset inventory
* Document asset treatment in SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against Level 2 security requirements that are relevant to the capabilities provided
|-
| '''Contractor Risk Managed Assets'''
|
* Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
* Assets are not required to be physically or logically separated from CUI assets
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC security requirements, except as noted
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost
** The limited check(s) will be assessed against CMMC security requirements
|-
|'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
** Show these assets are managed using the contractor's risk-based security policies
* Document in the network diagram of the CMMC Assessment Scope
|
* Review the SSP
* Do not assess against other CMMC security requirements
|-
| colspan="4" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|-
| '''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUIassets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 2 Scoping ==
The OSA is required to document all asset categories that are part of the Level 2 self-assessment or certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets process, store, or transmit CUI as follows:
* '''Process''' – CUI can be used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – CUI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the System Security Plan (SSP);
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSA’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against Level 2 security requirements that are relevant to the capabilities provided.For example, an External Service Provider (ESP), defined in 32 CFR §170.4, that provides a security information and event management (SIEM) service may be separated logically and may not process CUI, but the SIEM does contribute to meeting the CMMC requirements within the OSA’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system.It includes, but is not limited to:
* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Contractor Risk Managed Assets ===
Contractor Risk Managed Assets are not intended to, but are capable of processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

Contractor Risk Managed Assets are part of the Level 2 CMMC Assessment Scope. These assets are managed using the OSA’s risk-based information security policy, procedures, and practices. Furthermore, the assets must be assessed against CMMC requirements if insufficiently documented in the SSP or if the OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets.In these cases, the assessor can conduct a limited check to identify deficiencies.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

Assessment requirements for Contractor Risk Managed Asset are detailed in Table 1.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 2 assessment when documented in accordance with Table 1 (reprinted from 32 CFR § 170.19(c)(1) Table 3). Note that a Specialized Asset may be eligible for an Enduring Exception.

* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSA-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the CMMC Assessment Scope.In accordance with 32 CFR § 170.19(c)(1) Table 3, the OSA shall document these assets in the SSP and detail how they are managed using the OSA’s risk-based information security policy, procedures, and practices.

In addition, the OSA is required to:
* document each asset in asset inventory; there is no requirement to embed every asset in the SSP;
* document these assets in the SSP to show they are managed using the OSA’s risk-based security policies, procedures, and practices; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

An assessor will review the SSP to verify that specialized assets are managed using the OSA’s risk-based information security policy, procedures, and practices, and accounted for within the OSA’s CMMC Assessment Scope.The assessor will not retain a copy of the SSP.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(c)(1), Out-of-Scope Assets are not part of a Level 2 self-assessment or certification assessment.There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSA then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSA’s environment that will be assessed in accordance with Table 1. OSAs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor.Details about required documentation for each asset category can be found in the [[Level_2_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 2 CMMC Assessment Scope:
* CUI Assets
* Security Protection Assets
* Contractor Risk Managed Assets
* Specialized Assets

=== Separation Techniques ===
Separation is a system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI. Effective separation involves logically or physically separating assets and is required only for Out-of-Scope Assets. By separating assets, the CMMC Assessment Scope can be limited. Effective separation for CMMC follows the guidance in NIST SP 800-171 Rev 2, which states:

''If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms).Security domains may employ physical separation, logical separation, or a combination of both. This approach can provide adequate security for the CUI and avoid increasing the organization’s security posture to a level beyond that which it requires for protecting its missions, operations, and assets.''

'''Logical separation''' occurs when data transfer between physically connected assets (wired or wireless) is prevented by non-physical means such as software or network assets (e.g., firewall, routers, VPNs, VLANs).

'''Physical separation''' occurs when assets have no connection (wired or wireless). Data can only be transferred manually (e.g., USB drive).

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping. A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP, do not require a new assessment, but rather may be covered by annual affirmations to the continuing compliance with requirements.

=== External Service Provider Considerations ===
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI Asset and/or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(c)(2). Special considerations for an OSA using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security requirement objectives that are the provider’s responsibility and security requirement objectives that are the OSA’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSA’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012.Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a C3PAO assessment, and a C3PAO may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2, as applicable, against their on-premise infrastructure connecting to the CSP.As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

=== Use Cases ===
'''FCI and CUI in the Same Assessment Scope'''

A Level 2 self-assessment or Level 2 certification assessment satisfies the Level 1 self-assessment requirements for the same CMMC Assessment Scope.If FCI is processed, stored, or transmitted within the same scope as CUI in the Level 2 scope, then the methods to implement the Level 2 security requirements apply towards meeting the Level 1 assessment objectives. The OSA is responsible for ensuring that only authorized users and processes have access to data regardless of its designation.

'''FCI and CUI in Different Assessment Scopes'''

If FCI and CUI do not share an environment, the two assessments would be conducted independently and methods to implement security requirements in one scope would not apply to the other scope.

'''Use of Enclaves'''

Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise.This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope.For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool.Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope.

Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way.

There is no established metric for inherited implementations from an enterprise to any defined enclaves.The OSA determines the architecture that best meets its business needs and complies with CMMC requirements.

'''Security Protection Data'''

Security Protection Data (SPD) can be created by or used by a Security Protection Asset (SPA).Aggregated logs in a SIEM are one example of SPD and the SIEM is considered the SPA. The SIEM is part of the assessment scope.Because of the wide range of SIEM tools available, (on-premise hardware appliance; on-premise virtual appliance; or cloud based), methods of assessing the SIEM will also vary. If the SIEM and/or associated log data is hosted or maintained by an ESP, then the portion of the ESP that is used to provide the SIEM service or log storage is part of the OSA’s assessment scope.SIEM logs are typically available in hot storage for some period of time as part of the SIEM deployment.In this case, the SPD is collocated with the SPA.Cold storage of logs for a longer period of time is typically done offline or in cloud storage.The method used and the location of the cold storage are also in the OSA’s assessment scope.

== Notes ==
<references />

Level 2 Scoping Guidance

2026-02-23T18:30:32Z

David: /* Separation Techniques */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us].Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.This document is intended only to provide clarity to the public
regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A.Approved for public release.Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 2 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR).Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document.Guidance for scoping a Level 3 certification assessment can be
found in the ''CMMC Scoping Guide – Level 3'' document.More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 2 self-assessment in accordance with 32 CFR § 170.16, Organizations Seeking Certification (OSCs) that will be obtaining a Level 2 certification assessment in accordance with 32 CFR § 170.17, and the professionals or companies that will support them in those
efforts.The security requirements for a Level 2 self-assessment and a Level 2 certification assessment are the same, the only difference in these assessments is whether it is conducted by the OSA or by an independent C3PAO.

OSCs are a subset of OSAs as all organizations will participate in an assessment, but self-assessment cannot result in a certification.

=== Identifying the CMMC Assessment Scope ===
An ''Assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment.The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a CMMC assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(c).The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the assessment.

Because the scoping of a Level 2 assessment is not the same as the scoping of a Level 3 assessment, before determining the CMMC Assessment Scope it is important to first consider if the organization will seek a CMMC Status of Final Level 3 (DIBCAC).If the intent is to obtain a CMMC Status of Final Level 3 (DIBCAC), the OSC should also consider the guidance provided in the ''CMMC Scoping Guide – Level 3'' document.The OSC must closeout any Level 2 Plan of Action and Milestones (POA&M) and achieve a CMMC Status of Final Level 2 (C3PAO) prior to initiating a Level 3 certification assessment.

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment
Scope. OSCs may choose to designate them as CUI Assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment.During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC certification assessment.

== CMMC Asset Categories ==
For a Level 2 assessment, assets are mapped into one of five categories defined in 32 CFR § 170.19(c)(1) Table 3. This table describes each asset category and its corresponding OSA requirements and CMMC assessment requirements.Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="width: 85%;"
|+ Table 1. CMMC Asset Categories and Associated Requirements Overview
! style="width: 16%"| '''Asset Category'''
! style="width: 28%"| '''Asset Description'''
! style="width: 28%"| '''OSA Requirements'''
! style="width: 28%"| '''CMMC Assessment Requirements'''
|-
| colspan="4" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against all Level 2 security requirements
|-
| '''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope
|
* Document in the asset inventory
* Document asset treatment in SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against Level 2 security requirements that are relevant to the capabilities provided
|-
| '''Contractor Risk Managed Assets'''
|
* Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
* Assets are not required to be physically or logically separated from CUI assets
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC security requirements, except as noted
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost
** The limited check(s) will be assessed against CMMC security requirements
|-
|'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
** Show these assets are managed using the contractor's risk-based security policies
* Document in the network diagram of the CMMC Assessment Scope
|
* Review the SSP
* Do not assess against other CMMC security requirements
|-
| colspan="4" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|-
| '''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUIassets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 2 Scoping ==
The OSA is required to document all asset categories that are part of the Level 2 self-assessment or certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets process, store, or transmit CUI as follows:
* '''Process''' – CUI can be used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – CUI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the System Security Plan (SSP);
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSA’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against Level 2 security requirements that are relevant to the capabilities provided.For example, an External Service Provider (ESP), defined in 32 CFR §170.4, that provides a security information and event management (SIEM) service may be separated logically and may not process CUI, but the SIEM does contribute to meeting the CMMC requirements within the OSA’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system.It includes, but is not limited to:
* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Contractor Risk Managed Assets ===
Contractor Risk Managed Assets are not intended to, but are capable of processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

Contractor Risk Managed Assets are part of the Level 2 CMMC Assessment Scope. These assets are managed using the OSA’s risk-based information security policy, procedures, and practices. Furthermore, the assets must be assessed against CMMC requirements if insufficiently documented in the SSP or if the OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets.In these cases, the assessor can conduct a limited check to identify deficiencies.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

Assessment requirements for Contractor Risk Managed Asset are detailed in Table 1.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 2 assessment when documented in accordance with Table 1 (reprinted from 32 CFR § 170.19(c)(1) Table 3). Note that a Specialized Asset may be eligible for an Enduring Exception.

* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSA-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the CMMC Assessment Scope.In accordance with 32 CFR § 170.19(c)(1) Table 3, the OSA shall document these assets in the SSP and detail how they are managed using the OSA’s risk-based information security policy, procedures, and practices.

In addition, the OSA is required to:
* document each asset in asset inventory; there is no requirement to embed every asset in the SSP;
* document these assets in the SSP to show they are managed using the OSA’s risk-based security policies, procedures, and practices; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

An assessor will review the SSP to verify that specialized assets are managed using the OSA’s risk-based information security policy, procedures, and practices, and accounted for within the OSA’s CMMC Assessment Scope.The assessor will not retain a copy of the SSP.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(c)(1), Out-of-Scope Assets are not part of a Level 2 self-assessment or certification assessment.There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSA then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSA’s environment that will be assessed in accordance with Table 1. OSAs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor.Details about required documentation for each asset category can be found in the [[Level_2_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 2 CMMC Assessment Scope:
* CUI Assets
* Security Protection Assets
* Contractor Risk Managed Assets
* Specialized Assets

=== Separation Techniques ===
Separation is a system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI. Effective separation involves logically or physically separating assets and is required only for Out-of-Scope Assets.By separating assets, the CMMC Assessment Scope can be limited. Effective separation for CMMC follows the guidance in NIST SP 800-171 Rev 2, which states:

''If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms).Security domains may employ physical separation, logical separation, or a combination of both.This approach can provide adequate security for the CUI and avoid increasing the organization’s security posture to a level beyond that which it requires for protecting its missions, operations, and assets.''

'''Logical separation''' occurs when data transfer between physically connected assets (wired or wireless) is prevented by non-physical means such as software or network assets (e.g., firewall, routers, VPNs, VLANs).

'''Physical separation''' occurs when assets have no connection (wired or wireless). Data can only be transferred manually (e.g., USB drive).

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping. A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP, do not require a new assessment, but rather may be covered by annual affirmations to the continuing compliance with requirements.

=== External Service Provider Considerations ===
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI Asset and/or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(c)(2). Special considerations for an OSA using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security requirement objectives that are the provider’s responsibility and security requirement objectives that are the OSA’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSA’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012.Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a C3PAO assessment, and a C3PAO may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2, as applicable, against their on-premise infrastructure connecting to the CSP.As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

=== Use Cases ===
'''FCI and CUI in the Same Assessment Scope'''

A Level 2 self-assessment or Level 2 certification assessment satisfies the Level 1 self-assessment requirements for the same CMMC Assessment Scope.If FCI is processed, stored, or transmitted within the same scope as CUI in the Level 2 scope, then the methods to implement the Level 2 security requirements apply towards meeting the Level 1 assessment objectives. The OSA is responsible for ensuring that only authorized users and processes have access to data regardless of its designation.

'''FCI and CUI in Different Assessment Scopes'''

If FCI and CUI do not share an environment, the two assessments would be conducted independently and methods to implement security requirements in one scope would not apply to the other scope.

'''Use of Enclaves'''

Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise.This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope.For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool.Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope.

Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way.

There is no established metric for inherited implementations from an enterprise to any defined enclaves.The OSA determines the architecture that best meets its business needs and complies with CMMC requirements.

'''Security Protection Data'''

Security Protection Data (SPD) can be created by or used by a Security Protection Asset (SPA).Aggregated logs in a SIEM are one example of SPD and the SIEM is considered the SPA. The SIEM is part of the assessment scope.Because of the wide range of SIEM tools available, (on-premise hardware appliance; on-premise virtual appliance; or cloud based), methods of assessing the SIEM will also vary. If the SIEM and/or associated log data is hosted or maintained by an ESP, then the portion of the ESP that is used to provide the SIEM service or log storage is part of the OSA’s assessment scope.SIEM logs are typically available in hot storage for some period of time as part of the SIEM deployment.In this case, the SPD is collocated with the SPA.Cold storage of logs for a longer period of time is typically done offline or in cloud storage.The method used and the location of the cold storage are also in the OSA’s assessment scope.

== Notes ==
<references />

External References

2025-09-28T12:03:33Z

David: /* N */

Additional References: The [https://dodcio.defense.gov/CMMC/Resources/ CMMC Resources] page contains a variety of external links to CMMC resources throughout the DoD.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== B ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Blue Cyber Education Series for Small Business
|
* [https://www.safcn.af.mil/CISO/Small-Business-Cybersecurity-Information/ Home Page]
|}

== C ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''CISA Cyber Security Evaluation Tool (CSET®)'''
|
* [https://www.cisa.gov/stopransomware/cyber-security-evaluation-tool-csetr Home Page]
* [https://github.com/cisagov/cset/releases CSET Download]
|-
|'''CMMC Program Final Rule'''
|
* [https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program 32 CFR Part 170 rule]
|-
|'''Cyber AB, The'''
|
* [https://cyberab.org/ Home Page]
|-
|'''Cybersecurity and Privacy Reference Tool (CPRT)'''
|
* [https://csrc.nist.gov/projects/cprt/catalog#/cprt/home/ CPRT Catalog]
|}

== D ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) Contractor Resources
|
* [https://www.dcma.mil/DIBCAC/ Home Page]
|}

== M ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''MITRE ATT&CK Knowledge Base
|
* [https://attack.mitre.org/ Home Page]
|}

== N ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''NIST Cybersecurity Framework'''
|
* [https://www.nist.gov/cyberframework Home Page]
* [https://www.nist.gov/cyberframework/framework Framework Documents]
* [https://www.nist.gov/cyberframework/online-learning Online Learning]
|-
|'''NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf PDF Download]
|-
|'''NIST SP 800-171 Rev. 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf PDF Download]
|-
|'''NIST SP 800-171A Assessing Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/a/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171a.pdf PDF Download]
|-
|'''NIST SP 800-171 Rev. 3 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/r3/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf PDF Download]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171r3/NIST.SP.800-171r3.html HTML Version]
|-
|'''NIST SP 800-171A Rev.3 Assessing Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/pubs/sp/800/171/a/r3/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171Ar3.pdf PDF Download]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171Ar3/NIST.SP.800-171Ar3.html HTML Version]
|-
|'''NIST SP 800-172 Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-172/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-172.pdf PDF Download]
|-
|'''NIST SP 800-172A Assessing Enhanced Security Requirements for Controlled Unclassified Information'''
|
* [https://csrc.nist.gov/publications/detail/sp/800-172a/final Home Page]
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-172A.pdf PDF Download]
|-
|'''NSA Cybersecurity Products and Services'''
|
* [https://www.nsa.gov/Cybersecurity/Cybersecurity-Products-Services/ Home Page]
* [https://github.com/nsacyber Cybersecurity Directorate GitHub]
|}

== O ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''OSCAL: the Open Security Controls Assessment Language
|
* [https://pages.nist.gov/OSCAL/ Home Page]
|}

== P ==
{|class="wikitable" style="width: 80%;"
! style="width: 70%"| Standards and Organizations
! style="width: 30%"| Links
|-
|'''Project Spectrum'''
|
* [https://www.projectspectrum.io/ Home Page]
|}

Practice CA.L2-3.12.4 Details

2025-09-11T21:47:56Z

David: /* FURTHER DISCUSSION */

'''Source of Reference: The official [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Level 2 Assessment Guide] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== CA.L2-3.12.4 – SYSTEM SECURITY PLAN ==
=== SECURITY REQUIREMENT ===
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
=== ASSESSMENT OBJECTIVES ===
Determine if:
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
=== POTENTIAL ASSESSMENT METHODS AND OBJECTS ===
'''Examine'''

[SELECT FROM: Security planning policy; procedures addressing system security plan development and implementation; procedures addressing system security plan reviews and updates; enterprise architecture documentation; system security plan; records of system security plan reviews and updates; other relevant documents or records].

'''Interview'''

[SELECT FROM: Personnel with security planning and system security plan implementation responsibilities; personnel with information security responsibilities].

'''Test'''

[SELECT FROM: Organizational processes for system security plan development, review, update, and approval; mechanisms supporting the system security plan].
=== DISCUSSION ===
System security plans relate security requirements to a set of security controls. System security plans also describe, at a high level, how the security controls meet those security requirements, but do not provide detailed, technical descriptions of the design or implementation of the controls. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk if the plan is implemented as intended. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.

NIST SP 800-18 provides guidance on developing security plans.
=== FURTHER DISCUSSION ===
A system security plan (SSP) is a document that outlines how an organization implements its security requirements. At a minimum, an SSP must include:
* Description of the CMMC Assessment Scope;
* CMMC Assessment Scope Description: high-level description of the assets within the assessment scope;
* Description of the Environment of Operation: physical surroundings in which an information system processes, stores, and transmits information;
* Identified and Approved Security Requirements: requirements levied on an information system that are derived from applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, procedures, or organizational mission/business case needs to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted;
* Implementation Method for Security Requirements: description of how the identified and approved security requirements are implemented with the system or environment;
* Connections and Relationships to Other Systems and Networks: description of related, dependent, and interconnected systems; and
* Defined Frequency of Updates: typically at least annually.

In addition to the requirements above, an SSP often includes:
* general information system description: technical and functional description;
* design philosophies: defense-in-depth strategies and allowed interfaces and network protocols; and
* roles and responsibilities: description of the roles and responsibilities for key personnel, which may include the system owner, system custodian, authorizing officials, and other stakeholders

This practice, CA.L2-3.12.4, which requires developing, documenting, and updating system security plans, promotes effective information security within organizational systems required by SC.L2-3.13.2, as well as other system and communications protection practices.

'''Example'''

You are in charge of system security. You develop an SSP and have senior leadership formally approve the document [a]. The SSP explains how your organization handles CUI and defines how that data is stored, transmitted, and protected [d,e]. The criteria outlined in the SSP is used to guide configuration of the network and other information resources to meet your company’s goals. Knowing that it is important to keep the SSP current, you establish a policy that requires a formal review and update of the SSP each year [g,h].

'''Potential Assessment Considerations'''
* Do mechanisms exist to develop and periodically update an SSP [a,g]?
* Are security requirements identified and approved by the designated authority as non-applicable documented [d]?

=== KEY REFERENCES ===
* NIST SP 800-171 Rev 2 3.12.4

Level 2 Assessment Guide

2025-08-16T23:32:59Z

David: /* SC.L2-3.13.4 – Shared Resource Control */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified; and
: [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Level 2 Assessment Guide

2025-08-16T21:37:12Z

David: /* IA.L2-3.5.8 – Password Reuse */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified; and
: [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is
prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Main Page

2025-06-11T20:35:29Z

David: /* Site Update Notices */

'''This website contains information about the Cybersecurity Maturity Model Certification (CMMC) program of the U.S. Department of Defense (DoD).

The wiki aims to provide educational references for those who are interested in learning more about the framework.'''

Primary Source of Reference: The official [https://dodcio.defense.gov/CMMC/ CMMC Home Page] from the Department of Defense Chief Information Officer (DoD CIO).

Additional References: The [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Resources & Documentation] page contains a variety of links to CMMC resources throughout the DoD.

Basic information on FedRAMP and Cybersecurity Framework are also available on this website. Select one of the menu items on the Sidebar.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Site Update Notices ==
The CMMCWiki site is currently undergoing a comprehensive update to align with the latest content on the official CMMC website. For the most up-to-date information on our progress and recent changes, please refer to the following table.

{| class="wikitable" style="margin:auto"
|+ Update Status as of March 27, 2025
|-
! Page Name !! Status
|-
| Model Overview || Update completed on March 16, 2025
|-
| 32 CFR Part 170 Rule || Update completed on March 3, 2025
|-
| Level 1 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 1 Self-Assessment Guide || Update completed on March 16, 2025
|-
| Level 2 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 2 Assessment Guide || Update completed on March 20, 2025
|-
| Level 3 Scoping Guidance || Update completed on February 24, 2025
|-
| Level 3 Assessment Guide || Update completed on March 27, 2025
|-
| CMMC Hashing Guide || Update completed on March 16, 2025
|-
| CMMC Assessment Process (CAP) by CyberAB || Update completed on February 24, 2025
|-
| DoD Assessment Methodology || Update completed on March 18, 2025
|-
| 110 L1 & L2 Security Requirements || Update completed on March 16, 2025
|-
| 24 L3 Security Requirements || Update completed on March 27, 2025
|-
| FedRAMP Information || Update Pending
|-
| Cybersecurity Framework Information || Update Pending
|}

32 CFR Part 170

2025-05-28T22:07:35Z

David: /* § 170.4 Acronyms and definitions. */

'''Source of Reference: The official [https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program Cybersecurity Maturity Model Certification (CMMC) Program] final rule.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== PART 170 - CYBERSECURITY MATURITY MODEL CERTIFICATION (CMMC) PROGRAM ==

=== Subpart A - General Information ===
Sec.
* 170.1 Purpose.
* 170.2 Incorporation by reference.
* 170.3 Applicability.
* 170.4 Acronyms and definitions.
* 170.5 Policy.

=== Subpart B - Government Roles and Responsibilities ===
* 170.6 CMMC PMO.
* 170.7 DCMA DIBCAC.

=== Subpart C - CMMC Assessment and Certification Ecosystem ===
* 170.8 Accreditation Body.
* 170.9 CMMC Third-Party Assessment Organizations (C3PAOs).
* 170.10 CMMC Assessor and Instructor Certification Organization (CAICO).
* 170.11 CMMC Certified Assessor (CCA).
* 170.12 CMMC Instructor.
* 170.13 CMMC Certified Professional (CCP).

=== Subpart D - Key Elements of the CMMC Program ===
* 170.14 CMMC Model.
* 170.15 CMMC Level 1 self-assessment and affirmation requirements.
* 170.16 CMMC Level 2 self-assessment and affirmation requirements.
* 170.17 CMMC Level 2 certification assessment and affirmation requirements.
* 170.18 CMMC Level 3 certification assessment and affirmation requirements.
* 170.19 CMMC scoping.
* 170.20 Standards acceptance.
* 170.21 Plan of Action and Milestones requirements.
* 170.22 Affirmation.
* 170.23 Application to subcontractors.
* 170.24 CMMC Scoring Methodology.
* Appendix A to Part 170 - Guidance

'''Authority''': 5 U.S.C. 301; Sec. 1648, Pub. L. 116-92, 133 Stat. 1198.

== Subpart A - General Information. ==
=== § 170.1 Purpose. ===
(a) This part describes the Cybersecurity Maturity Model Certification (CMMC) Program of the Department of Defense (DoD) and establishes requirements for defense contractors and subcontractors to implement prescribed cybersecurity standards for safeguarding Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). This part (the CMMC Program) also establishes requirements for conducting an assessment of compliance with the applicable prescribed cybersecurity standard for contractor information systems that: process, store, or transmit FCI or CUI; provide security protections for systems which process, store, or transmit CUI; or are not logically or physically isolated from systems which process, store, or transmit CUI.

(b) The CMMC Program provides DoD with a viable means of conducting the volume of assessments necessary to verify contractor and subcontractor implementation of required cybersecurity requirements.

(c) The CMMC Program is designed to ensure defense contractors are properly safeguarding FCI and CUI that is processed, stored, or transmitted on defense contractor information systems. FCI and CUI must be protected to meet evolving threats and safeguard nonpublic, unclassified information that supports and enables the warfighter. The CMMC Program provides a consistent methodology to assess a defense contractor’s implementation of required cybersecurity requirements. The CMMC Program utilizes the security standards set forth in the 48 CFR 52.204-21; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, ''Basic Safeguarding of Covered Contractor Information Systems, ''Revision 2, February 2020 (includes updates as of January 28, 2021) (NIST SP 800-171 R2); and selected requirements from the NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, ''February 2021 (NIST SP 800-172 Feb2021), as applicable (see table 1 to § 170.14(c)(4) for requirements, see § 170.2 for availability of NIST publications).

(d) The CMMC Program balances the need to safeguard FCI and CUI and the requirement to share information appropriately with defense contractors in order to develop capabilities for the DoD. The CMMC Program is designed to ensure implementation of cybersecurity practices for defense contractors and to provide DoD with increased assurance that FCI and CUI information will be adequately safeguarded when residing on or transiting contractor information systems.

(e) The CMMC Program creates no right or benefit, substantive or procedural, enforceable by law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.

=== § 170.2 Incorporation by reference. ===

Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. Material approved for incorporation by reference (IBR) is available for inspection at the Department of Defense (DoD) and at the National Archives and Records Administration (NARA). Contact DoD online: ''https://DoDcio.defense.gov/CMMC/''; email: ''osd.mc-alex.DoD-cio.mbx.cmmc-rule@mail.mil''; or phone: (202) 770-9100. For information on the availability of this material at NARA, visit: ''www.archives.gov/federal-register/ cfr/ibr-locations'' or email: ''fr.inspection@nara.gov''. The material may be obtained from the following sources:

(a) National Institute of Standards and Technology, U.S. Department of Commerce, 100 Bureau Drive, Gaithersburg, MD 20899; phone: (301) 975-8443; website: ''https://csrc.nist.gov/ publications/''.

(1) FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006 (FIPS PUB 200 Mar2006); IBR approved for § 170.4(b).

(2) FIPS PUB 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022 (FIPS PUB 201-3 Jan2022); IBR approved for § 170.4(b).

(3) SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, Revision 2, December 2018 (NIST SP 800-37 R2); IBR approved for § 170.4(b).

(4) SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, March 2011 (NIST SP 800-39 Mar2011); IBR approved for § 170.4(b).

(5) SP 800-53, Security and Privacy Controls for Information Systems and Organizations, Revision 5, September 2020 (includes updates as of December 10, 2020) (NIST SP 800-53 R5); IBR approved for § 170.4(b).

(6) SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023 (NIST SP 800-82r3); IBR approved for § 170.4(b).

(7) SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008 (NIST SP 800-115 Sept2008); IBR approved for § 170.4(b).

(8) SP 800-160, Volume 2, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, Revision 1, December 2021 (NIST SP 800-160 V2R1); IBR approved for § 170.4(b).

(9) SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 2, February 2020 (includes updates as of January 28, 2021), (NIST SP 800-171 R2); IBR approved for §§ 170.4(b) and 170.14(a) through (c).

(10) SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information, June 2018 (NIST SP 800-171A Jun2018); IBR approved for §§ 170.11(a), 170.14(d), 170.15(c), 170.16(c), 170.17(c), and 170.18(c).

(11) SP 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, February 2021 (NIST SP 800-172 Feb2021); IBR approved for §§ 170.4(b), 170.5(a), and 170.14(a) and (c).

(12) SP 800-172A, Assessing Enhanced Security Requirements for Controlled Unclassified Information, March 2022 (NIST SP 800-172A Mar2022); IBR approved for §§ 170.4(b), 170.14(d), and 170.18(c).

(b) International Organization for Standardization (ISO) Chemin de Blandonnet 8, CP 401 - 1214 Vernier, Geneva, Switzerland; phone: +41 22 749 01 11; website: ''www.iso.org/popular- standards.html''.

(1) ISO/IEC 17011:2017(E), Conformity assessment - Requirements for accreditation bodies accrediting conformity assessment bodies, Second edition, November 2017 (ISO/IEC 17011:2017(E)); IBR approved for §§ 170.8(b)(3), 170.9(b)(13), and 170.10(b)(4).

(2) ISO/IEC 17020:2012(E), Conformity assessment - Requirement for the operation of various types of bodies performing inspection, Second edition, March 1, 2012 (ISO/IEC 17020:2012(E)); IBR approved for §§ 170.8(a), (b)(1), (b)(3) and 170.9(b)(2) and (b)(13).

(3) ISO/IEC 17024:2012(E), Conformity assessment - General requirements for bodies operating certification of persons, second edition, July 1, 2012 (ISO/IEC 17024:2012(E)); IBR approved for §§ 170.8(b)(2) and 170.10(a) and (b)(4), (7), and (8).

'''Note 1 to paragraph (b):''' The ISO/IEC standards incorporated by reference in this part may be viewed at no cost in ‘‘read only’’ format at ''https://ibr.ansi.org''.

=== § 170.3 Applicability. ===

(a) The requirements of this part apply to:

(1) All DoD contract and subcontract awardees that will process, store, or transmit information, in performance of the DoD contract, that meets the standards for FCI or CUI on contractor information systems; and,

(2) Private-sector businesses or other entities comprising the CMMC Assessment and Certification Ecosystem, as specified in subpart C of this part.

(b) The requirements of this part do not apply to Federal information systems operated by contractors or subcontractors on behalf of the Government.

(c) CMMC Program requirements apply to all DoD solicitations and contracts pursuant to which a defense contractor or subcontractor will process, store, or transmit FCI or CUI on unclassified contractor information systems, including those for the acquisition of commercial items (except those exclusively for COTS items) valued at greater than the micro- purchase threshold except under the following circumstances:

(1) The procurement occurs during Implementation Phase 1, 2, or 3 as described in paragraph (e) of this section, in which case CMMC Program requirements apply in accordance with the requirements for the relevant phase- in period; or

(2) Application of CMMC Program requirements to a procurement or class of procurements may be waived in advance of the solicitation at the discretion of DoD in accordance with all applicable policies, procedures, and approval requirements.

(d) DoD Program Managers or requiring activities are responsible for selecting the CMMC Status that will apply for a particular procurement or contract based upon the type of information, FCI or CUI, that will be processed on, stored on, or transmitted through a contractor information system. Application of the CMMC Status for subcontractors will be determined in accordance with § 170.23.

(e) DoD is utilizing a phased approach for the inclusion of CMMC Program requirements in solicitations and contracts. Implementation of CMMC Program requirements will occur over four (4) phases:

(1) ''Phase 1''. Begins on the effective date of the complementary 48 CFR part 204 CMMC Acquisition final rule. DoD intends to include the requirement for CMMC Statuses of Level 1 (Self) or Level 2 (Self) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, include the requirement for CMMC Status of Level 1 (Self) or Level 2 (Self) for applicable DoD solicitations and contracts as a condition to exercise an option period on a contract awarded prior to the effective date. DoD may also, at its discretion, include the requirement for CMMC Status of Level 2 (C3PAO) in place of the Level 2 (Self) CMMC Status for applicable DoD solicitations and contracts.

(2) ''Phase 2''. Begins one calendar year following the start date of Phase 1. In addition to Phase 1 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 2 (C3PAO) to an option period instead of as a condition of contract award. DoD may also, at its discretion, include the requirement for CMMC Status of Level 3 (DIBCAC) for applicable DoD solicitations and contracts.

(3) ''Phase 3''. Begins one calendar year following the start date of Phase 2. In addition to Phase 1 and 2 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for all applicable DoD solicitations and contracts as a condition of contract award and as a condition to exercise an option period on a contract awarded after the effective date. DoD intends to include the requirement for CMMC Status of Level 3 (DIBCAC) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 3 (DIBCAC) to an option period instead of as a condition of contract award.

(4) ''Phase 4, full implementation''. Begins one calendar year following the start date of Phase 3. DoD will include CMMC Program requirements in all applicable DoD solicitations and contracts including option periods on contracts awarded prior to the beginning of Phase 4.

=== § 170.4 Acronyms and definitions. ===

(a) ''Acronyms. ''Unless otherwise noted, the following acronyms and their terms are for the purposes of this part.

AC - Access Control 
APT - Advanced Persistent Threat 
AT - Awareness and Training 
C3PAO - CMMC Third-Party Assessment Organization 
CA - Security Assessment CAICO - CMMC Assessors and Instructors Certification Organization 
CAGE - Commercial and Government Entity 
CCA - CMMC-Certified Assessor 
CCI - CMMC-Certified Instructor 
CCP - CMMC-Certified Professional 
CFR - Code of Federal Regulations 
CIO - Chief Information Officer 
CM - Configuration Management 
CMMC - Cybersecurity Maturity Model Certification 
CMMC PMO - CMMC Program Management Office 
CNC - Computerized Numerical Control 
CoPC - Code of Professional Conduct 
CSP - Cloud Service Provider 
CUI - Controlled Unclassified Information 
DCMA - Defense Contract Management Agency 
DD - Represents any two-character CMMC Domain acronym 
DFARS - Defense Federal Acquisition Regulation Supplement 
DIB - Defense Industrial Base 
DIBCAC - DCMA’s Defense Industrial Base Cybersecurity Assessment Center 
DoD - Department of Defense DoDI - Department of Defense Instruction 
eMASS - Enterprise Mission Assurance Support Service 
ESP - External Service Provider 
FAR - Federal Acquisition Regulation 
FCI - Federal Contract Information 
FedRAMP - Federal Risk and Authorization Management Program 
GFE - Government Furnished Equipment 
IA - Identification and Authentication 
ICS - Industrial Control System 
IIoT - Industrial Internet of Things 
IoT - Internet of Things 
IR - Incident Response 
IS - Information System 
IEC - International Electrotechnical Commission 
ISO/IEC - International Organization for Standardization/International Electrotechnical Commission 
IT - Information Technology 
L# - CMMC Level Number 
MA - Maintenance 
MP - Media Protection 
MSSP - Managed Security Service Provider 
NARA - National Archives and Records Administration 
NAICS - North American Industry Classification System 
NIST - National Institute of Standards and Technology 
N/A - Not Applicable 
ODP - Organization-Defined Parameter 
OSA - Organization Seeking Assessment 
OSC - Organization Seeking Certification 
OT - Operational Technology 
PI - Provisional Instructor 
PIEE - Procurement Integrated Enterprise Environment 
PII - Personally Identifiable Information 
PLC - Programmable Logic Controller 
POA&M - Plan of Action and Milestones 
PRA - Paperwork Reduction Act 
RM - Risk Management 
SAM - System of Award Management 
SC - System and Communications Protection 
SCADA - Supervisory Control and Data Acquisition 
SI - System and Information Integrity 
SIEM - Security Information and Event Management 
SP - Special Publication 
SPD - Security Protection Data 
SPRS - Supplier Performance Risk System 
SSP - System Security Plan 

(b) ''Definitions''. Unless otherwise noted, these terms and their definitions are for the purposes of this part.

''Access Control (AC) ''means the process of granting or denying specific requests to obtain and use information and related information processing services; and/or entry to specific physical facilities (''e.g., ''Federal buildings, military establishments, or border crossing entrances), as defined in FIPS PUB 201-3 Jan2002 (incorporated by reference, see § 170.2).

''Accreditation'' means a status pursuant to which a CMMC Assessment and Certification Ecosystem member (person or organization), having met all criteria for the specific role they perform including required ISO/IEC accreditations, may act in that role as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC- custom term)

''Accreditation Body'' is defined in § 170.8 and means the one organization DoD contracts with to be responsible for authorizing and accrediting members of the CMMC Assessment and Certification Ecosystem, as required. The Accreditation Body must be approved by DoD. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program. (CMMC-custom term)

''Advanced Persistent Threat (APT) ''means an adversary that possesses sophisticated levels of expertise and significant resources that allow it to create opportunities to achieve its objectives by using multiple attack vectors (''e.g.'', cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period-of-time, adapts to defenders’ efforts to resist it, and is determined to maintain the level of interaction needed to execute its objectives, as is defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Affirming Official'' means the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations. (CMMC-custom term)

''Assessment'' means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in §§ 170.15 through 170.18. (CMMC-custom term)

(i) ''Level 1 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 1 (Self).

(ii) ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).

(iii) ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).

(iv) ''Level 3 certification assessment'' is the term for the activity performed by the DCMA DIBCAC to evaluate the information system of an OSC when seeking a CMMC Status of Level 3 (DIBCAC).

(v) ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).

(vi) ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.

''Assessment Findings Report'' means the final written assessment results by the third-party or government assessment team. The Assessment Findings Report is submitted to the OSC and to the DoD via CMMC eMASS. (CMMC-custom term)

''Assessment objective'' means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) or NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). (CMMC-custom term)

''Assessment Team'' means participants in the Level 2 certification assessment (CMMC Certified Assessors and CMMC Certified Professionals) or the Level 3 certification assessment (DCMA DIBCAC assessors). This does not include the OSC participants preparing for or participating in the assessment. (CMMC-custom term)

''Asset'' means an item of value to stakeholders. An asset may be tangible (''e.g.'', a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (''e.g.'', humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Asset Categories'' means a grouping of assets that process, store or transmit information of similar designation, or provide security protection to those assets. (CMMC-custom term)

''Authentication'' is defined in FIPS PUB 200 Mar2006 (incorporated by reference, see § 170.2).

''Authorized'' means an interim status during which a CMMC Ecosystem member (person or organization), having met all criteria for the specific role they perform other than the required ISO/IEC accreditations, may act in that role for a specified time as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC-custom term)

''Capability'' means a combination of mutually reinforcing controls implemented by technical means, physical means, and procedural means. Such controls are typically selected to achieve a common information security or privacy purpose, as defined in NIST SP 800-37 R2 (incorporated by reference, see § 170.2).

''Cloud Service Provider (CSP) ''means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable computing resources (''e.g.'', networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This definition is based on the definition for cloud computing in NIST SP 800-145 Sept2011. (CMMC-custom term)

''CMMC Assessment and Certification Ecosystem'' means the people and organizations described in subpart C of this part. This term is sometimes shortened to CMMC Ecosystem. (CMMC-custom term)

''CMMC Assessment Scope'' means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements. (CMMC-custom term)

''CMMC Assessor and Instructor Certification Organization (CAICO) ''is defined in § 170.10 and means the organization responsible for training, testing, authorizing, certifying, and recertifying CMMC certified assessors, certified instructors, and certified professionals. (CMMC-custom term)

''CMMC Instantiation of eMASS'' means a CMMC instance of the Enterprise Mission Assurance Support Service (eMASS), a government owned and operated system. (CMMC-custom term)

''CMMC Security Requirements'' means the 15 Level 1 requirements listed in the 48 CFR 52.204-21(b)(1), the 110 Level 2 requirements from NIST SP 800-171 R2 (incorporated by reference, see § 170.2), and the 24 Level 3 requirements selected from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2).

''CMMC Status'' is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC. The potential CMMC Statuses are outlined in the paragraphs that follow. (CMMC-custom term)

(i) ''Final Level 1 (Self) ''is defined in § 170.15(a)(1) and (c)(1). (CMMC-custom term)

(ii) ''Conditional Level 2 (Self) ''is defined in § 170.16(a)(1)(ii). (CMMC- custom term)

(iii) ''Final Level 2 (Self) ''is defined in § 170.16(a)(1)(iii). (CMMC-custom term)

(iv) ''Conditional Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(ii). (CMMC- custom term)

(v) ''Final Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(iii). (CMMC-custom term)

(vi) ''Conditional Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(ii). (CMMC- custom term)

(vii) ''Final Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(iii). (CMMC-custom term)

''CMMC Status Date'' means the date that the CMMC Status results are submitted to SPRS or the CMMC instantiation of eMASS, as appropriate. The date of the Conditional CMMC Status will remain as the CMMC Status Date after a successful POA&M closeout. A new date is not set for a Final that follows a Conditional. (CMMC-custom term)

''CMMC Third-Party Assessment Organization (C3PAO) ''means an organization that has been authorized or accredited by the Accreditation Body to conduct Level 2 certification assessments and has the roles and responsibilities identified in § 170.9. (CMMC-custom term)

''Contractor'' is defined in 48 CFR 3.502-1.

''Contractor Risk Managed Assets'' are defined in table 3 to § 170.19(c)(1). (CMMC-custom term)

''Controlled Unclassified Information (CUI) ''is defined in 32 CFR 2002.4(h).

''Controlled Unclassified Information (CUI) Assets'' means assets that can process, store, or transmit CUI. (CMMC- custom term)

''DCMA DIBCAC High Assessment'' means an assessment that is conducted by Government personnel in accordance with NIST SP 800-171A Jun2018 and leveraging specific guidance in the DoD Assessment Methodology that:

(i) Consists of: (A) A review of a contractor’s Basic Assessment;

(B) A thorough document review;

(C) Verification, examination, and demonstration of a contractor’s system security plan to validate that NIST SP 800-171 R2 security requirements have been implemented as described in the contractor’s system security plan; and

(D) Discussions with the contractor to obtain additional information or clarification, as needed; and

(ii) Results in a confidence level of ‘‘High’’ in the resulting score. (Source: 48 CFR 252.204-7020).

''Defense Industrial Base (DIB) ''is defined in 32 CFR 236.2.

''DoD Assessment Methodology (DoDAM) ''documents a standard methodology that enables a strategic assessment of a contractor’s implementation of NIST SP 800-171 R2, a requirement for compliance with 48 CFR 252.204-7012. (Source: DoDAM Version 1.2.1)

''Enduring Exception'' means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be enduring exceptions. (CMMC-custom term)

''Enterprise'' means an organization with a defined mission/goal and a defined boundary, using information systems to execute that mission, and with responsibility for managing its own risks and performance. An enterprise may consist of all or some of the following business aspects: acquisition, program management, financial management (''e.g.'', budgets), human resources, security, and information systems, information and mission management, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''External Service Provider (ESP) ''means external people, technology, or facilities that an organization utilizes for provision and management of IT and/or cybersecurity services on behalf of the organization. In the CMMC Program, CUI or Security Protection Data (''e.g.'', log data, configuration data), must be processed, stored, or transmitted on the ESP assets to be considered an ESP. (CMMC-custom term)

''Federal Contract Information (FCI) ''is defined in 48 CFR 4.1901.

''Government Furnished Equipment (GFE) ''has the same meaning as ‘‘government-furnished property’’ as defined in 48 CFR 45.101.

''Industrial Control Systems (ICS) ''means a general term that encompasses several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations that are often found in the industrial sectors and critical infrastructures, such as Programmable Logic Controllers (PLC). An ICS consists of combinations of control components (''e.g.'', electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (''e.g.'', manufacturing, transportation of matter or energy), as defined in NIST SP 800-82r3 (incorporated by reference, see § 170.2).

''Information System (IS) ''is defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

''Internet of Things (IoT) ''means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Operational plan of action'' as used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies (''e.g.'', necessary information system updates, patches, or reconfiguration as threats evolve) in implementation of requirements and documents how they will be mitigated, corrected, or eliminated. The OSA defines the format (''e.g.'', document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment for remediation of deficiencies that must be completed within 180 days. (CMMC- custom term)

''Operational Technology (OT) ''means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Organization-defined'' means as determined by the OSA except as defined in the case of Organization- Defined Parameter (ODP). (CMMC- custom term)

''Organization-Defined Parameters (ODPs) ''means selected enhanced security requirements contain selection and assignment operations to give organizations flexibility in defining variable parts of those requirements, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Note 1 to ODPs:'' The organization defining the parameters is the DoD.

''Organization Seeking Assessment (OSA) ''means the entity seeking to undergo a self-assessment or certification assessment for a given information system for the purposes of achieving and maintaining any CMMC Status. The term OSA includes all Organizations Seeking Certification (OSCs). (CMMC-custom term)

''Organization Seeking Certification (OSC) ''means the entity seeking to undergo a certification assessment for a given information system for the purposes of achieving and maintaining the CMMC Status of Level 2 (C3PAO) or Level 3 (DIBCAC). An OSC is also an OSA. (CMMC-custom term)

''Out-of-Scope Assets'' means assets that cannot process, store, or transmit CUI because they are physically or logically separated from information systems that do process, store, or transmit CUI, or are inherently unable to do so; except for assets that provide security protection for a CUI asset (see the definition for ''Security Protection Assets''). (CMMC- custom term)

''Periodically'' means occurring at a regular interval as determined by the OSA that may not exceed one year. (CMMC-custom term)

''Personally Identifiable Information'' means information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Plan of Action and Milestones (POA&M) ''means a document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in NIST SP 800-115 Sept2008 (incorporated by reference, see § 170.2).

''Prime Contractor'' is defined in 48 CFR 3.502-1.

''Process, store, or transmit'' means data can be used by an asset (''e.g.'', accessed, entered, edited, generated, manipulated, or printed); data is inactive or at rest on an asset (''e.g.'', located on electronic media, in system component memory, or in physical format such as paper documents); or data is being transferred from one asset to another asset (''e.g.'', data in transit using physical or digital transport methods). (CMMC-custom term)

''Restricted Information Systems'' means systems (and associated IT components comprising the system) that are configured based on government requirements (''e.g.'', connected to something that was required to support a functional requirement) and are used to support a contract (''e.g.'', fielded systems, obsolete systems, and product deliverable replicas). (CMMC-custom term)

''Risk'' means a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of:

(i) The adverse impacts that would arise if the circumstance or event occurs; and

(ii) The likelihood of occurrence, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Risk Assessment'' means the process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. Risk Assessment is part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis, as defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Security Protection Assets (SPA) ''means assets providing security functions or capabilities for the OSA’s CMMC Assessment Scope. (CMMC- custom term)

''Security Protection Data (SPD) ''means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC’s assessed environment. SPD is security relevant information and includes but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment. (CMMC-custom term)

''Specialized Assets'' means types of assets considered specialized assets for CMMC: Government Furnished Equipment, Internet of Things (IoT) or Industrial Internet of Things (IIoT), Operational Technology (OT), Restricted Information Systems, and Test Equipment. (CMMC-custom term)

''Subcontractor'' is defined in 48 CFR 3.502-1.

''Supervisory Control and Data Acquisition (SCADA) ''means a generic name for a computerized system that is capable of gathering and processing data and applying operational controls over long distances. Typical uses include power transmission and distribution and pipeline systems. SCADA was designed for the unique communication challenges (''e.g.'', delays, data integrity) posed by the various media that must be used, such as phone lines, microwave, and satellite. Usually shared rather than dedicated, as defined in NIST SP 800- 82r3 (incorporated by reference, see § 170.2).

''System Security Plan (SSP) ''means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Temporary deficiency'' means a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency. (CMMC-custom term)

''Test Equipment'' means hardware and/ or associated IT components used in the testing of products, system components, and contract deliverables. (CMMC- custom term)

''User'' means an individual, or (system) process acting on behalf of an individual, authorized to access a system, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

=== § 170.5 Policy. ===

(a) Protection of FCI and CUI on contractor information systems is of paramount importance to the DoD and can directly impact its ability to successfully conduct essential missions and functions. It is DoD policy that defense contractors and subcontractors shall be required to safeguard FCI and CUI that is processed, stored, or transmitted on contractor information systems by applying specified security requirements. In addition, defense contractors and subcontractors may be required to implement additional safeguards defined in NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2), implementing DoD specified parameters to meet CMMC Level 3 security requirements (see table 1 to § 170.14(c)(4)). These additional requirements are necessary to protect CUI being processed, stored, or transmitted in contractor information systems, when designated by a requirement for CMMC Status of Level 3 (DIBCAC) as defined by a DoD program manager or requiring activity. In general, the Department will identify a requirement for a CMMC Status of Level 3 (DIBCAC) for solicitations and resulting contracts supporting its most critical programs and technologies.

(b) Program managers and requiring activities are responsible for identifying the CMMC Status that will apply to a procurement. Selection of the applicable CMMC Status will be based on factors including but not limited to:

(1) Criticality of the associated mission capability;

(2) Type of acquisition program or technology;

(3) Threat of loss of the FCI or CUI to be shared or generated in relation to the effort;

(4) Impacts from exploitation of information security deficiencies; and

(5) Other relevant policies and factors, including Milestone Decision Authority guidance.

(c) In accordance with the implementation plan described in § 170.3, CMMC Program requirements will apply to new DoD solicitations and contracts, and shall flow down to subcontractors who will process, store, or transmit FCI or CUI in performance of the subcontract, as described in § 170.23.

(d) In very limited circumstances, and in accordance with all applicable policies, procedures, and requirements, a Service Acquisition Executive or Component Acquisition Executive in the DoD, or as delegated, may elect to waive inclusion of CMMC Program requirements in a solicitation or contract. In such cases, contractors and subcontractors will remain obligated to comply with all applicable cybersecurity and information security requirements.

(e) The CMMC Program does not alter any separately applicable requirements to protect FCI or CUI, including those requirements in accordance with 48 CFR 52.204-21'', Basic Safeguarding of Covered Contractor Information Systems'', or covered defense information in accordance with 48 CFR 252.204- 7012'', Safeguarding Covered Defense Information and Cyber Incident Reporting'', or any other applicable information protection requirements. The CMMC Program provides a means of verifying implementation of the security requirements set forth in 48 CFR 52.204-21, NIST SP 800-171 R2, and NIST SP 800-172 Feb2021, as applicable.

== Subpart B - Government Roles and Responsibilities. ==
=== § 170.6 CMMC PMO. ===

(a) The Office of the Department of Defense Chief Information Officer (DoD CIO) Office of the Deputy CIO for Cybersecurity (DoD CIO(CS)) provides oversight of the CMMC Program and is responsible for establishing CMMC assessment, accreditation, and training requirements as well as developing and updating CMMC Program policies and implementing guidance.

(b) The CMMC PMO is responsible for monitoring the CMMC AB’s performance of roles assigned in this rule and acting as necessary to address problems pertaining to effective performance.

(c) The CMMC PMO retains, on behalf of the DoD CIO(CS), the prerogative to review decisions of the CMMC Accreditation Body as part of its oversight of the CMMC program and evaluate any alleged conflicts of interest purported to influence the CMMC Accreditation Body’s objectivity.

(d) The CMMC PMO is responsible for sponsoring necessary DCSA activities including FOCI risk assessment and Tier 3 security background investigations for the CMMC Ecosystem members as specified in §§ 170.8(b)(4) and (5), 170.9(b)(3) through (5), 170.11(b)(3) and (4), and 170.13(b)(3) and (4).

(e) The CMMC PMO is responsible for investigating and acting upon indications that an active CMMC Status has been called into question. Indications that may trigger investigative evaluations include, but are not limited to, reports from the CMMC Accreditation Body, a C3PAO, or anyone knowledgeable of the security processes and activities of the OSA. Investigative evaluations include, but are not limited to, reviewing pertinent assessment information, and exercising the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020.

(f) If a subsequent DCMA DIBCAC assessment shows that adherence to the provisions of this rule and the required CMMC Status have not been achieved or maintained, the DIBCAC results will take precedence over any pre-existing CMMC Status recorded in SPRS, or its successor capability. The DoD will update SPRS to reflect that the OSA is out of compliance and does not meet DoD CMMC requirements. If the OSA is working on an active contract requiring CMMC compliance, then standard contractual remedies will apply.

=== § 170.7 DCMA DIBCAC. ===

(a) DCMA DIBCAC assessors in support of the CMMC Program will:

(1) Complete CMMC Level 2 and Level 3 training.

(2) Conduct Level 3 certification assessments and upload assessment results into the CMMC instantiation of eMASS, or its successor capability.

(3) Issue Certificates of CMMC Status resulting from Level 3 certification assessments.

(4) Conduct Level 2 certification assessments of the Accreditation Body and prospective C3PAOs’ information systems that process, store, and/or transmit CUI.

(5) Create and maintain a process for assessors to collect the list of assessment artifacts to include artifact names, their return value of the hashing algorithm, the hashing algorithm used, and upload that data into the CMMC instantiation of eMASS.

(6) As authorized and in accordance with all legal requirements, enter and track, OSC appeals and updated results arising from Level 3 certification assessment activities into the CMMC instantiation of eMASS.

(7) Retain all records in accordance with DCMA-MAN 4501-04.

(8) Conduct an assessment of the OSA, when requested by the CMMC PMO per §§ 170.6(e) and (f), as provided for under the 48 CFR 252.204-7019 and 48 CFR 252.204-7020.

(9) Identify assessments that meet the criteria in § 170.20 and verify that SPRS accurately reflects the CMMC Status.

(b) An OSC, the CMMC AB, or a C3PAO may appeal the outcome of its DCMA DIBCAC conducted assessment within 21 days by submitting a written basis for appeal with the requirements in question for DCMA DIBCAC consideration. Appeals may be submitted for review by visiting ''www.dcma.mil/DIBCAC'' for contact information, and a DCMA DIBCAC Quality Assurance Review Team will provide a written response or request additional supporting documentation.

== Subpart C - CMMC Assessment and Certification Ecosystem. ==
=== § 170.8 Accreditation Body. ===

(a)''Roles and responsibilities''. The Accreditation Body is responsible for authorizing and ensuring the accreditation of CMMC Third-Party Assessment Organizations (C3PAOs) in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and all applicable authorization and accreditation requirements set forth. The Accreditation Body is responsible for establishing the C3PAO authorization requirements and the C3PAO Accreditation Scheme and submitting both for approval by the CMMC PMO. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program.

(b)''Requirements''. The CMMC Accreditation Body shall:

(1) Be US-based and be and remain a member in good standing of the Inter- American Accreditation Cooperation (IAAC) and become an International Laboratory Accreditation Cooperation (ILAC) Mutual Recognition Arrangement (MRA) signatory, with a signatory status scope of ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2).

(2) Be and remain a member in good standing of the International Accreditation Forum (IAF) with mutual recognition arrangement signatory status scope of ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(3) Achieve and maintain full compliance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2) and complete a peer assessment by other ILAC signatories for competence in accrediting conformity assessment bodies to ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), both within 24 months of DoD approval.

(i) Prior to achieving full compliance as set forth in this paragraph (b)(3), the Accreditation Body shall:

(A) Authorize C3PAOs who meet all requirements set forth in § 170.9 as well as administrative requirements as determined by the Accreditation Body to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the assessment results.

(B) Require all C3PAOs to achieve and maintain the ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) requirements within 27 months of authorization.

(ii) The Accreditation Body shall accredit C3PAOs, in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), who meet all requirements set forth in § 170.9 to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the results.

(4) Ensure that the Accreditation Body’s Board of Directors, professional staff, Information Technology (IT) staff, accreditation staff, and independent CMMC Certified Assessor staff complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions'') and ]submitted by DoD CIO Security to Washington Headquarters Services (WHS) for coordination for processing by the Defense Counterintelligence and Security Agency (DCSA). These positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing the Standard Form (SF) 328 (''www.gsa.gov/reference/forms/ certificate-pertaining-to-foreign- interests''), ]''Certificate Pertaining to Foreign Interests'', and submit it directly to Defense Counterintelligence and Security Agency (DCSA) and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c). The Accreditation Body must receive a non-disqualifying eligibility determination by the CMMC PMO to be recognized by the Department of Defense.

(ii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the Accreditation Body losing its authorization or accreditation under the CMMC Program.

(iii) Identifying all prospective C3PAOs to the CMMC PMO. The CMMC PMO will sponsor the prospective C3PAO for a FOCI risk assessment conducted by the DCSA using the SF 328 as part of the authorization and accreditation processes.

(iv) Notifying prospective C3PAOs of the CMMC PMO’s eligibility determination resulting from the FOCI risk assessment.

(6) Obtain a Level 2 certification assessment in accordance with the procedures specified in § 170.17(a)(1) and (c). This assessment, conducted by DCMA DIBCAC, shall meet all requirements for a Final Level 2 (C3PAO) but will not result in a CMMC Status of Level 2 (C3PAO). The Level 2 certification assessment process must be performed every three years.

(7) Provide all documentation and records in English.

(8) Establish, maintain, and manage an up-to-date list of authorized and accredited C3PAOs on a single publicly accessible website and provide the list of these entities and their status to the DoD through submission in the CMMC instantiation of eMASS.

(9) Provide the CMMC PMO with current data on C3PAOs, including authorization and accreditation records and status in the CMMC instantiation of eMASS. This data shall include the dates associated with the authorization and accreditation of each C3PAO.

(10) Provide the DoD with information about aggregate statistics pertaining to operations of the CMMC Ecosystem to include the authorization and accreditation status of C3PAOs or other information as requested.

(11) Provide inputs for assessor supplemental guidance to the CMMC PMO. Participate and support coordination of these and other inputs through DoD-led Working Groups.

(12) Ensure that all information about individuals is encrypted and protected in all Accreditation Body information systems and databases.

(13) Provide all plans that are related to potential sources of revenue, to include but not limited to: fees, licensing, processes, membership, and/ or partnerships to the Department’s CMMC PMO.

(14) Ensure that the CMMC Assessors and Instructors Certification Organization (CAICO) is compliant with ISO/IEC 17024:2012(E)

(15) Ensure all training products, instruction, and testing materials are of high quality and subject to CAICO quality control policies and procedures, to include technical accuracy and alignment with all applicable legal, regulatory, and policy requirements.

(16) Develop and maintain an internal appeals process, as required by ISO/IEC 17020:2017(E), and render a final decision on all elevated appeals.

(17) Develop and maintain a comprehensive plan and schedule to comply with all ISO/IEC 17011:2017(E), and DoD requirements for Conflict of Interest, Code of Professional Conduct, and Ethics policies as set forth in the DoD contract. All policies shall apply to the Accreditation Body, and other individuals, entities, and groups within the CMMC Ecosystem who provide Level 2 certification assessments, CMMC instruction, CMMC training materials, or Certificates of CMMC Status on behalf of the Accreditation Body. All policies in this section must be approved by the CMMC PMO prior to effectivity in accordance with the following requirements.

(i) ''Conflict of Interest (CoI) policy.''

The CoI policy shall:

(A) Include a detailed risk mitigation plan for all potential conflicts of interest that may pose a risk to compliance with ISO/IEC 17011:2017(E).

(B) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees to disclose to the CMMC PMO, in writing, as soon as it is known or reasonably should be known, any actual, potential, or perceived conflict of interest with sufficient detail to allow for assessment.

(C) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees who leave the board or organization to enter a ‘‘cooling off period’’ of one (1) year whereby they are prohibited from working with the Accreditation Body or participating in any and all CMMC activities described in Subpart C.

(D) Require CMMC Ecosystem members to actively avoid participating in any activity, practice, or transaction that could result in an actual or perceived conflict of interest.

(E) Require CMMC Ecosystem members to disclose to Accreditation Body leadership, in writing, any actual or potential conflict of interest as soon as it is known, or reasonably should be known.

(ii) ''Code of Professional Conduct (CoPC) policy.''

The CoPC policy shall:

(A) Describe the performance standards by which the members of the CMMC Ecosystem will be held accountable and the procedures for addressing violations of those performance standards.

(B) Require the Accreditation Body to investigate and resolve any potential violations that are reported or are identified by the DoD.

(C) Require the Accreditation Body to inform the DoD in writing of new investigations within 72 hours.

(D) Require the Accreditation Body to report to the DoD in writing the outcome of completed investigations within 15 business days.

(E) Require CMMC Ecosystem members to represent themselves and their companies accurately; to include not misrepresenting any professional credentials or status, including CMMC authorization or CMMC Status, nor exaggerating the services that they or their company are capable or authorized to deliver.

(F) Require CMMC Ecosystem members to be honest and factual in all CMMC-related activities with colleagues, clients, trainees, and others with whom they interact.

(G) Prohibit CMMC Ecosystem members from participating in the Level 2 certification assessment process for an assessment in which they previously served as a consultant to prepare the organization for any CMMC assessment within 3 years.

(H) Require CMMC Ecosystem members to maintain the confidentiality of customer and government data to preclude unauthorized disclosure.

(I) Require CMMC Ecosystem members to report results and data from Level 2 certification assessments and training objectively, completely, clearly, and accurately.

(J) Prohibit CMMC Ecosystem members from cheating, assisting another in cheating, or allowing cheating on CMMC examinations.

(K) Require CMMC Ecosystem members to utilize official training content developed by a CMMC training organization approved by the CAICO in all CMMC certification courses.

(iii) ''Ethics policy.''

The Ethics policy shall:

(A) Require CMMC Ecosystem members to report to the Accreditation Body within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

(B) Prohibit harassment or discrimination by CMMC Ecosystem members in all interactions with individuals whom they encounter in connection with their roles in the CMMC Ecosystem.

(C) Require CMMC Ecosystem members to have and maintain a satisfactory record of integrity and business ethics.

=== § 170.9 CMMC Third-Party Assessment Organizations (C3PAOs). ===

(a)''Roles and responsibilities''. C3PAOs are organizations that are responsible for conducting Level 2 certification assessments and issuing Certificates of CMMC Status to OSCs based on the results. C3PAOs must be accredited or authorized by the Accreditation Body in accordance with the requirements set forth.

(b)''Requirements''. C3PAOs shall:

(1) Obtain authorization or accreditation from the Accreditation Body in accordance with § 170.8(b)(3)(i) and (ii).

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain compliance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) within 27 months of authorization.

(3) Require all C3PAO company personnel participating in the Level 2 certification assessment process to complete a Tier 3 background investigation resulting in a determination of national security eligibility. This includes the CMMC Assessment Team and the quality assurance individual. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/ reference/forms/questionnaire-for-national-security-positions''). These ]positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Require all C3PAO company personnel participating in the Level 2 certification assessment process who are not eligible to obtain a Tier 3 background investigation to meet the equivalent of a favorably adjudicated Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing and submitting Standard Form (SF) 328 (''www.gsa.gov/ reference/forms/certificate-pertaining-to-foreign-interests''), Certificate Pertaining to Foreign Interests'', upon request from DCSA and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c).

(ii) Receiving a non-disqualifying eligibility determination from the CMMC PMO resulting from the FOCI risk assessment in order to proceed to a DCMA DIBCAC CMMC Level 2 assessment, as part of the authorization and accreditation process set forth in paragraph (b)(6) of this section.

(iii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the C3PAO losing its authorization or accreditation.

(6) Undergo a Level 2 certification assessment meeting all requirements for a Final Level 2 (C3PAO) in accordance with the procedures specified in § 170.17(a)(1) and (c), with the following exceptions:

(i) The assessment will be conducted by DCMA DIBCAC.

(ii) The assessment will not result in a CMMC Status of Level 2 (C3PAO) nor receive a Certificate of CMMC Status.

(7) Provide all documentation and records in English.

(8) Submit pre-assessment and planning material, final assessment reports, and CMMC certificates of assessment into the CMMC instantiation of eMASS.

(9) Unless disposition is otherwise authorized by the CMMC PMO, maintain all assessment related records for a period of six (6) years. Such records include any materials generated by the C3PAO in the course of an assessment, any working papers generated from Level 2 certification assessments; and materials relating to monitoring, education, training, technical knowledge, skills, experience, and authorization of all personnel involved in assessment activities; contractual agreements with OSCs; and organizations for whom consulting services were provided.

(10) Provide any requested audit information, including any out-of-cycle from ISO/IEC 17020:2012(E) requirements, to the Accreditation Body.

(11) Ensure that all personally identifiable information (PII) is encrypted and protected in all C3PAO information systems and databases.

(12) Meet the requirements for Assessment Team composition. An Assessment Team must include at least two people: a Lead CCA, as defined in § 170.11(b)(10), and at least one other CCA. Additional CCAs and CCPs may also participate on an Assessment Team.

(13) Implement a quality assurance function that ensures the accuracy and completeness of assessment data prior to upload into the CMMC instantiation of eMASS. Any individual fulfilling the quality assurance function must be a CCA and cannot be a member of an Assessment Team for which they are performing a quality assurance role. A quality assurance individual shall manage the C3PAO’s quality assurance reviews as defined in paragraph (b)(14) of this section and the appeals process as required by paragraphs (b)(19) and (20) of this section and in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(14) Conduct quality assurance reviews for each assessment, including observations of the Assessment Team’s conduct and management of CMMC assessment processes.

(15) Ensure that all Level 2 certification assessment activities are performed on the information system within the CMMC Assessment Scope.

(16) Maintain all facilities, personnel, and equipment involved in CMMC activities that are in scope of their Level 2 certification assessment and comply with all security requirements and procedures as prescribed by the Accreditation Body.

(17) Ensure that all assessment data and information uploaded into the CMMC instantiation of eMASS assessment data is compliant with the CMMC assessment data standard as set forth in eMASS CMMC Assessment Import Templates on the CMMC eMASS website: ''https://cmmc.emass.apps.mil''. This system is accessible only to authorized users.

(18) Issue Certificates of CMMC Status to OSCs in accordance with the Level 2 certification assessment requirements set forth in § 170.17, that include, at a minimum, all industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope, the C3PAO name, assessment unique identifier, the OSC name, and the CMMC Status date and level.

(19) Address all OSC appeals arising from Level 2 certification assessment activities. If the OSC or C3PAO is not satisfied with the result of the appeal either the OSC or the C3PAO can elevate the matter to the Accreditation Body for final determination.

(20) Submit assessment appeals, review records, and decision results of assessment appeals to DoD using the CMMC instantiation of eMASS.

=== § 170.10 CMMC Assessor and Instructor Certification Organization (CAICO). ===

(a)''Roles and responsibilities''. The CAICO is responsible for training, testing, authorizing, certifying, and recertifying CMMC assessors, instructors, and related professionals. Only the CAICO may make decisions relating to examination certifications, including the granting, maintaining, recertifying, expanding, and reducing the scope of certification, and suspending or withdrawing certification in accordance with current ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2). At any given point in time, there will be only one CAICO for the DoD CMMC Program.

(b)''Requirements''. The CAICO shall: (1) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain ISO/IEC 17024(E) accreditation within 12 months of December 16, 2024.

(2) Provide all documentation and records in English.

(3) Train, test, and designate PIs in accordance with the requirements of this section. Train, test, certify, and recertify CCPs, CCAs, and CCIs in accordance with the requirements of this section.

(4) Ensure the instructor and assessor certification examinations are certified under ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2), by a recognized US-based accreditor who is not a member of the CMMC Accreditation Body. The US-based accreditor must be a signatory to International Laboratory Accreditation Cooperation (ILAC) or relevant International Accreditation Forum (IAF) Mutual Recognition Arrangement (MRA) and must operate in accordance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(5) Establish quality control policies and procedures for the generation of training products, instruction, and testing materials.

(6) Oversee development, administration, and management pertaining to the quality of training and examination materials for CMMC assessor and instructor certification and recertification.

(7) Establish and publish an authorization and certification appeals process to receive, evaluate, and make decisions on complaints and appeals in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(8) Address all appeals arising from the CCA, CCI, and CCP authorizations and certifications process through use of internal processes in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(9) Maintain records for a period of six (6) years of all procedures, processes, and actions related to fulfillment of the requirements set forth in this section and provide the Accreditation Body access to those records.

(10) Provide the Accreditation Body information about the authorization and accreditation status of assessors, instructors, training community, and publishing partners.

(11) Ensure separation of duties between individuals involved in testing activities, training activities, and certification activities.

(12) Safeguard and require any CAICO training support service providers, as applicable, to safeguard the confidentiality of applicant, candidate, and certificate-holder information and ensure the overall security of the certification process.

(13) Ensure that all PII is encrypted and protected in all CAICO information systems and databases and those of any CAICO training support service providers.

(14) Ensure the security of assessor and instructor examinations and the fair and credible administration of examinations.

(15) Neither disclose nor allow any CAICO training support service providers, as applicable, to disclose CMMC data or metrics related to authorization or certification activities to any entity other than the Accreditation Body and DoD, except as required by law.

(16) Require retraining and redesignation of PIs upon significant change to DoD’s CMMC Program requirements. Require retraining and recertification of CCPs, CCAs, and CCIs upon significant change to DoD’s CMMC Program requirements, as determined by the DoD or the CAICO.

(17) Require CMMC Ecosystem members to report to the CAICO within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

=== § 170.11 CMMC Certified Assessor (CCA). ===

(a)''Roles and responsibilities''. CCAs, in support of a C3PAO, conduct Level 2 certification assessments of OSCs in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2), the assessment processes defined in § 170.17, and the scoping requirements defined in § 170.19(c). CCAs must meet all of the requirements set forth in paragraph (b) of this section. A CCA may conduct Level 2 certification assessments and participate on a C3PAO Assessment Team.

(b)''Requirements''. CCAs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/ questionnaire-for-national-security- positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible for a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Be a CCP who has at least 3 years of cybersecurity experience, at least 1 year of assessment or audit experience, and at least one foundational qualification, aligned to at least the Intermediate Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program'' (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at ''https://public.cyber.mil/dcwf-work-role/security-control-assessor/''.

(7) Only use IT, cloud, cybersecurity services, and end-point devices provided by the authorized/accredited C3PAO that has been engaged to perform that OSA’s Level 2 certification assessment and which has undergone a Level 2 certification assessment by DCMA DIBCAC (or higher) for all assessment activities. Individual assessors are prohibited from using any other IT, including IT that is personally owned, to include internal and external cloud services and end-point devices, to process, store, or transmit CMMC assessment reports or any other CMMC assessment-related information. The evaluation of assessment evidence within the OSC environment, using OSC tools, is permitted.

(8) Immediately notify the responsible C3PAO of any breach or potential breach of security to any CMMC-related assessment materials under the assessors’ purview.

(9) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

(10) Qualify as a Lead CCA by having at least 5 years of cybersecurity experience, 5 years of management experience, 3 years of assessment or audit experience, and at least one foundational qualification aligned to Advanced Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at '' https://public.cyber.mil/dcwf-work-role/security-control-assessor/.''

=== § 170.12 CMMC Instructor. ===

(a) ''CMMC Provisional Instructor (PI) roles and responsibilities''. A CMMC Provisional Instructor (PI) teaches CCA and CCP candidates during the transitional period that ends 18 months after December 16, 2024. A PI is trained, tested, and designated to perform CMMC instructional duties by the CAICO to teach CCP and CCA candidates. PIs are designated by the CAICO after successful completion of the PI training and testing requirements set forth by the CAICO. A PI with a valid CCP certification may instruct CCP candidates, while a PI with a valid CCA certification may instruct CCP and CCA candidates. PIs are required to meet requirements in (c) of this section.

(b) ''CMMC Certified Instructor (CCI) roles and responsibilities''. A CMMC Certified Instructor (CCI) teaches CCP, CCA, and CCI candidates and performs CMMC instructional duties. Candidate CCIs are certified by the CAICO after successful completion of the CCI training and testing requirements. A CCI is required to obtain and maintain assessor and instructor certifications from the CAICO in accordance with the requirements set forth in § 170.10 and in paragraph (c) of this section. A CCI with a valid CCP certification may instruct CCP candidates, while a CCI with a valid CCA certification may instruct CCP, CCA, and CCI candidates. Certifications are valid for 3 years from the date of issuance. CCIs are required to meet requirements in paragraph (c) of this section.

(c)''Requirements''. CMMC Instructors shall:

(1) Obtain and maintain instructor designation or certification, as appropriate, from the CAICO in accordance with the requirements set forth in § 170.10.

(2) Obtain and maintain CCP or CCA certification to deliver CCP training.

(3) Obtain and maintain a CCA certification to deliver CCA training.

(4) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(5) Provide all documentation and records in English.

(6) Provide the Accreditation Body and the CAICO annually with accurate information detailing their qualifications, training experience, professional affiliations, and certifications, and, upon reasonable request, submit documentation verifying this information.

(7) Not provide CMMC consulting services while serving as a CMMC instructor; however, subject to the Code of Professional Conduct and Conflict of Interest policies, can serve on an assessment team.

(8) Not participate in the development of exam objectives and/or exam content or act as an exam proctor while at the same time serving as a CCI.

(9) Keep confidential all information obtained or created during the performance of CMMC training activities, including trainee records, except as required by law.

(10) Not disclose any CMMC-related data or metrics that is PII, FCI, or CUI to anyone without prior coordination with and approval from DoD.

(11) Notify the Accreditation Body or the CAICO if required by law or authorized by contractual commitments to release confidential information.

(12) Not share with anyone any CMMC training-related information not previously publicly disclosed.

=== § 170.13 CMMC Certified Professional (CCP). ===

(a)''Roles and responsibilities''. A CMMC Certified Professional (CCP) completes rigorous training on CMMC and the assessment process to provide advice, consulting, and recommendations to their OSA clients. Candidate CCPs are certified by the CAICO after successful completion of the CCP training and testing requirements set forth in paragraph (b) of this section. CCPs are eligible to become CMMC Certified Assessors and can participate as a CCP on Level 2 certification assessments with CCA oversight where the CCA makes all final determinations.

(b)''Requirements''. CCPs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics as set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible to obtain a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

== Subpart D - Key Elements of the CMMC Program ==
=== § 170.14 CMMC Model. ===

(a)''Overview''. The CMMC Model incorporates the security requirements from:

(1) 48 CFR 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems;''

(2) NIST SP 800-171 R2'', Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' (incorporated by reference, see § 170.2); and

(3) Selected security requirements from NIST SP 800-172 Feb2021, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'' (incorporated by reference, see § 170.2).

(b) ''CMMC domains''. The CMMC Model consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

(c) ''CMMC level requirements''. CMMC Levels 1-3 utilize the safeguarding requirements and security requirements specified in 48 CFR 52.204-21 (for Level 1), NIST SP 800-171 R2 (incorporated by reference, see § 170.2) (for Level 2), and selected security requirements from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2) (for Level 3). This paragraph discusses the numbering scheme and the security requirements for each level.

(1)''Numbering''. Each security requirement has an identification number in the format - DD.L#-REQ - where:

(i) DD is the two-letter domain abbreviation;

(ii) L# is the CMMC level number; and

(iii) REQ is the 48 CFR 52.204-21 paragraph number, NIST SP 800-171 R2 requirement number, or NIST SP 800- 172 Feb2021 requirement number.

(2) ''CMMC Level 1 security requirements''. The security requirements in CMMC Level 1 are those set forth in 48 CFR 52.204-21(b)(1)(i) through (xv).

(3) ''CMMC Level 2 security requirements''. The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.

(4) ''CMMC Level 3 security requirements''. The security requirements in CMMC Level 3 are selected from NIST SP 800-172 Feb2021, and where applicable, Organization-Defined Parameters (ODPs) are assigned. Table 1 to this paragraph identifies the selected requirements and applicable ODPs that represent the CMMC Level 3 security requirements. ODPs for the NIST SP 800-172 Feb2021 requirements are italicized, where applicable:

==== Table 1 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 1 TO § 170.14(c)(4)
|-
! style="width: 25%;text-align:center" | Security requirement No.*
! style="width: 75%;text-align:center" | CMMC Level 3 security requirements (selected NIST SP 800-172 Feb2021 security requirement with DoD ODPs italicized)
|-
|(i) AC.L3-3.1.2e
|Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
|-
|(ii) AC.L3-3.1.3e
|Employ ''secure information transfer solutions'' to control information flows between security domains on con-nected systems.
|-
|(iii) AT.L3-3.2.1e
|Provide awareness training ''upon initial hire, following a significant cyber event, and at least annually'', focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training ''at least annually'' or when there are significant changes to the threat.
|-
|(iv) AT.L3-3.2.2e
|Include practical exercises in awareness training for ''all users, tailored by roles, to include general users, users with specialized roles, and privileged users'', that are aligned with current threat scenarios and provide feed-back to individuals involved in the training and their supervisors.
|-
|(v) CM.L3-3.4.1e
|Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
|-
|(vi) CM.L3-3.4.2e
|Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, ''remove the components or place the components in a quarantine or remediation network'' to facilitate patching, re-configuration, or other mitigations.
|-
|(vii) CM.L3-3.4.3e
|Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|-
|(viii) IA.L3-3.5.1e
|Identify and authenticate ''systems and system components, where possible'', before establishing a network con-nection using bidirectional authentication that is cryptographically based and replay resistant.
|-
|(ix) IA.L3-3.5.3e
|Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|-
|(x) IR.L3-3.6.1e
|Establish and maintain a security operations center capability that operates ''24/7, with allowance for remote/on-call staff''.
|-
|(xi) IR.L3-3.6.2e
|Establish and maintain a cyber-incident response team that can be deployed by the organization within ''24 hours''.
|-
|(xii) PS.L3-3.9.2e
|Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.
|-
|(xiii) RA.L3-3.11.1e
|Employ ''threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources'', as part of a risk assessment to guide and inform the development of organizational systems, security architec-tures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
|-
|(xiv) RA.L3-3.11.2e
|Conduct cyber threat hunting activities ''on an on-going aperiodic basis or when indications warrant'', to search for indicators of compromise in'' organizational systems'' and detect, track, and disrupt threats that evade exist-ing controls.
|-
|(xv) RA.L3-3.11.3e
|Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|(xvi) RA.L3-3.11.4e
|Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
|-
|(xvii) RA.L3-3.11.5e
|Assess the effectiveness of security solutions ''at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident'', to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|(xviii) RA.L3-3.11.6e
|Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
|-
|(xix) RA.L3-3.11.7e
|Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan ''at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident''.
|-
|(xx) CA.L3-3.12.1e
|Conduct penetration testing ''at least annually or when significant security changes are made to the system'', leveraging automated scanning tools and ad hoc tests using subject matter experts.
|-
|(xxi) SC.L3-3.13.4e
|Employ ''physical isolation techniques or logical isolation techniques or both'' in organizational systems and system components.
|-
|(xxii) SI.L3-3.14.1e
|Verify the integrity of ''security critical and essential software'' using root of trust mechanisms or cryptographic signatures.
|-
|(xxiii) SI.L3-3.14.3e
|Ensure that ''specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems, and test equipment'' are included in the scope of the specified enhanced security requirements or are segregated in pur-pose-specific networks.
|-
|(xxiv) SI.L3-3.14.6e
|Use threat indicator information and effective mitigations obtained from'', at a minimum, open or commercial sources, and any DoD-provided sources'', to guide and inform intrusion detection and threat hunting.
|-
|colspan="2"|* Roman numerals in parentheses before the Security Requirement are for numbering purposes only. The numerals are not part of the naming convention for the requirement.
|}

(d) ''Implementation''. Assessment of security requirements is prescribed by NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). Descriptive text in these documents support OSA implementation of the security requirements and use the terms organization-defined and periodically. Except where referring to Organization- Defined Parameters (ODPs), organization-defined means as determined by the OSA. Periodically means occurring at regular intervals. As used in many requirements within CMMC, the interval length is organization-defined to provided contractor flexibility, with an interval length of no more than one year.

=== § 170.15 CMMC Level 1 self-assessment and affirmation requirements. ===

(a) ''Level 1 self-assessment''. To comply with CMMC Level 1 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 1 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of Final Level 1 (Self).

(1) ''Level 1 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(2) to achieve the CMMC Status of Final Level 1 (Self). No POA&Ms are permitted for CMMC Level 1. The OSA must conduct a self-assessment in accordance with the procedures set forth in § 170.15(c)(1) and submit assessment results in SPRS. To maintain compliance with the requirements for the CMMC Status of Final Level 1 (Self), the OSA must conduct a Level 1 self- assessment on an annual basis and submit the results in SPRS, or its successor capability.

(i) ''Inputs to SPRS''. The Level 1 self-assessment results in the Supplier Performance Risk System (SPRS) shall include, at minimum, the following items:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Compliance result.

(ii) [Reserved]

(2) ''Affirmation''. Affirmation of the Level 1 (Self) CMMC Status is required for all Level 1 self-assessments. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 1 (Self), OSAs must both achieve a CMMC Status of Level 1 (Self) and have submitted an affirmation of compliance into SPRS for all information systems within the CMMC Assessment Scope.

(c) ''Procedures - (1) Level 1 self-assessment''. The OSA must conduct a Level 1 self-assessment scored in accordance with the CMMC Scoring Methodology described in § 170.24. The Level 1 self-assessment must be performed in accordance with the CMMC Level 1 scope requirements set forth in § 170.19(a) and (b) and the following:

(i) The Level 1 self-assessment must be performed using the objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) for the security requirement that maps to the CMMC Level 1 security requirement as specified in table 1 to paragraph (c)(1)(ii) of this section. In any case where an objective addresses CUI, FCI should be substituted for CUI in the objective.

(ii) Mapping table for CMMC Level 1 security requirements to the NIST SP 800-171A Jun2018 objectives.

==== Table 2 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 2 TO § 170.15(c)(1)(ii) - CMMC LEVEL 1 SECURITY REQUIREMENTS MAPPED TO NIST SP 800-171A JUN2018
|-
! style="width: 65%;text-align:left" | CMMC Level 1 security requirements as set forth in § 170.14(c)(2)
! style="width: 35%;text-align:right" | NIST SP 800-171A Jun2018
|-
|AC.L1-b.1.i
| style="text-align:right" | 3.1.1
|-
|AC.L1-b.1.ii
| style="text-align:right" | 3.1.2
|-
|AC.L1-b.1.iii
| style="text-align:right" | 3.1.20
|-
|AC.L1-b.1.iv
| style="text-align:right" | 3.1.22
|-
|IA.L1-b.1.v
| style="text-align:right" | 3.5.1
|-
|IA.L1-b.1.vi
| style="text-align:right" | 3.5.2
|-
|MP.L1-b.1.vii
| style="text-align:right" | 3.8.3
|-
|PE.L1-b.1.viii
| style="text-align:right" | 3.10.1
|-
|First phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.3
|-
|Second phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.4
|-
|Third phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.5
|-
|SC.L1-b.1.x
| style="text-align:right" | 3.13.1
|-
|SC.L1-b.1.xi
| style="text-align:right" | 3.13.5
|-
|SI.L1-b.1.xii
| style="text-align:right" | 3.14.1
|-
|SI.L1-b.1.xiii
| style="text-align:right" | 3.14.2
|-
|SI.L1-b.1.xiv
| style="text-align:right" | 3.14.4
|-
|SI.L1-b.1.xv
| style="text-align:right" | 3.14.5
|-
|colspan="2"|* Three of the 48 CFR 52.204-21 requirements were broken apart by ‘‘phrase’’ when NIST SP 800-171 R2 was developed.
|}

(iii) Additional guidance can be found in the guidance document listed in paragraph (b) of appendix A to this part.

(2) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.16 CMMC Level 2 self-assessment and affirmation requirements. ===

(a) ''Level 2 self-assessment''. To comply with Level 2 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 2 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (Self). Achieving a CMMC Status of Level 2 (Self) also satisfies the requirements for a CMMC Status of Level 1 (Self) detailed in § 170.15 for the same CMMC Assessment Scope.

(1) ''Level 2 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (Self). The OSA must conduct a self- assessment in accordance with the procedures set forth in paragraph (c)(1) of this section and submit assessment results in Supplier Performance Risk System (SPRS). To maintain compliance with the requirements for a CMMC Status of Level 2 (Self), the OSA must conduct a Level 2 self-assessment every three years and submit the results in SPRS, within three years of the CMMC Status Date associated with the Conditional Level 2 (Self).

(i) ''Inputs to SPRS''. The Level 2 self-assessment results in the SPRS shall include, at minimum, the following information:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Overall Level 2 self-assessment score (''e.g''., 105 out of 110). 
(F) POA&M usage and compliance status, if applicable.

(ii) ''Conditional Level 2 (Self)''. The OSA has achieved the CMMC Status of Conditional Level 2 (Self) if the Level 2 self-assessment results in a POA&M and the POA&M meets all the CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSA must remediate any NOT MET requirements, must perform a POA&M closeout self- assessment, and must post compliance results to SPRS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (Self). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (Self) CMMC Status for the information system will expire. If Conditional Level 2 (Self) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSA will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (Self)''. The OSA has achieved the CMMC Status of Final Level 2 (Self) if the Level 2 self- assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial self-assessment or as the result of a POA&M closeout self- assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSA will be ineligible for additional awards with CMMC Status requirement of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (Self) CMMC Status is required for all Level 2 self-assessments at the time of each assessment, and annually thereafter. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 2 (Self), the following two requirements must be met:

(1) The OSA must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (Self) or Final Level 2 (Self).

(2) The OSA must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 self-assessment of the OSA''. The OSA must conduct a Level 2 self-assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in §§ 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 self-assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the OSA must upload the results into SPRS. If a POA&M exists, a POA&M closeout self-assessment must be performed by the OSA when all NOT MET requirements have been remediated. The POA&M closeout self- assessment must be performed within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in the guidance document listed in paragraph (c) of appendix A to this part.

(2) ''Level 2 self-assessment with the use of Cloud Service Provider (CSP)''. An OSA may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the Customer Responsibility Matrix (CRM) must be documented or referred to in the OSA’s System Security Plan (SSP).

(3) ''Level 2 self-assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and CRM.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

(4) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.17 CMMC Level 2 certification assessment and affirmation requirements. ===

(a) ''Level 2 certification assessment''. To comply with Level 2 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 2 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (C3PAO). Achieving a CMMC Status of Level 2 (C3PAO) also satisfies the requirements for a CMMC Statuses of Level 1 (Self) and Level 2 (Self) set forth in §§ 170.15 and 170.16 respectively for the same CMMC Assessment Scope.

(1) ''Level 2 certification assessment requirements''. The OSC must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (C3PAO). The OSC must obtain a Level 2 certification assessment from an authorized or accredited C3PAO following the procedures outlined in paragraph (c) of this section. The C3PAO must submit the Level 2 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 2 (C3PAO), the Level 2 certification assessment must be completed within three years of the CMMC Status Date associated with the Conditional Level 2 (C3PAO).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 2 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following information:

(A) Date and level of the assessment. 
(B) C3PAO name. 
(C) Assessment unique identifier. 
(D) For each Assessor conducting the assessment, name and business contact information. 
(E) All industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope. 
(F) The name, date, and version of the SSP. 
(G) CMMC Status Date. 
(H) Assessment result for each requirement objective. 
(I) POA&M usage and compliance, as applicable. 
(J) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Conditional Level 2 (C3PAO) if the Level 2 certification assessment results in a POA&M and the POA&M meets all CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from a C3PAO, and the C3PAO must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (C3PAO). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (C3PAO) CMMC Status for the information system will expire. If Conditional Level 2 (C3PAO) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Final Level 2 (C3PAO) if the Level 2 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (C3PAO) CMMC Status is required for all Level 2 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 certification assessment of the OSC''. An authorized or accredited C3PAO must perform a Level 2 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in § 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 certification assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the C3PAO must upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 2 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) Cannot change or limit the effectiveness of other requirements that have been scored MET; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment must be performed by a C3PAO within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in § 170.21 and in the guidance document listed in paragraph (c) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. The OSC must provide the C3PAO with a list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm for upload into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 2 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 2 certification assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

=== § 170.18 CMMC Level 3 certification assessment and affirmation requirements. ===

(a) ''Level 3 certification assessment''. To comply with Level 3 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 3 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 3 (DIBCAC). A CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope is a prerequisite to undergo a Level 3 certification assessment. CMMC Level 3 recertification also has a prerequisite for a new CMMC Level 2 assessment. Achieving a CMMC Status of Level 3 (DIBCAC) also satisfies the requirements for CMMC Statuses of Level 1 (Self), Level 2 (Self), and Level 2 (C3PAO) set forth in §§ 170.15 through 170.17 respectively for the same CMMC Assessment Scope.

(1) ''Level 3 certification assessment requirements''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) on the Level 3 CMMC Assessment Scope, as defined in § 170.19(d), prior to initiating a Level 3 certification assessment, which will be performed by DCMA DIBCAC (''www.dcma.mil/DIBCAC'') on behalf of the DoD. The OSC ]must complete and achieve a MET result for all security requirements specified in table 1 to § 170.14(c)(4) to achieve the CMMC Status of Level 3 (DIBCAC). DCMA DIBCAC will submit the Level 3 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 3 (DIBCAC), the Level 3 certification assessment must be performed every three years for all information systems within the Level 3 CMMC Assessment Scope. In addition, given that compliance with Level 2 requirements is a prerequisite for applying for CMMC Level 3, a Level 2 (C3PAO) certification assessment must also be conducted every three years to maintain CMMC Level 3 (DIBCAC) status. Level 3 certification assessment must be completed within three years of the CMMC Status Date associated with the Final Level 3 (DIBCAC) or, if there was a POA&M, then within three years of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 3 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following items:

(A) Date and level of the assessment. 
(B) For each Assessor(s) conducting the assessment, name and government organization information. 
(C) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(D) The name, date, and version of the system security plan(s) (SSP). 
(E) CMMC Status Date. (F) Result for each security requirement objective. 
(G) POA&M usage and compliance, as applicable. 
(H) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Conditional Level 3 (DIBCAC) if the Level 3 certification assessment results in a POA&M and the POA&M meets all CMMC Level 3 POA&M requirements listed in § 170.21(a)(3).

(A) ''Plan of Action and Milestones''. A Level 3 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from DCMA DIBCAC, and DCMA DIBCAC must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 3 (DIBAC) CMMC Status for the information system will expire. If Conditional Level 3 (DIBCAC) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Final Level 3 (DIBCAC) if the Level 3 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 3 (DIBCAC) CMMC Status is required for all Level 3 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 3 (DIBCAC), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 3 (DIBCAC) or Final Level 3 (DIBCAC).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 3 certification assessment of the OSC''. The CMMC Level 3 certification assessment process includes:

(i) ''Final Level 2 (C3PAO)''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope prior to the CMMC Level 3 certification assessment. The CMMC Assessment Scope for the Level 3 certification assessment must be equal to, or a subset of, the CMMC Assessment Scope associated with the OSC’s Final Level 2 (C3PAO). Asset requirements differ for each CMMC Level. Scoping differences are set forth in § 170.19.

(ii) ''Initiating the Final Level 3 (DIBCAC)''. The OSC (including ESPs that voluntarily elect to undergo a Level 3 certification assessment) initiates a Level 3 certification assessment by emailing a request to DCMA DIBCAC point of contact found at ''www.dcma.mil/DIBCAC''. The request ]must include the Level 2 certification assessment unique identifier. DCMA DIBCAC will validate the OSC has achieved a CMMC Status of Level 2 (C3PAO) and will contact the OSC to schedule their Level 3 certification assessment.

(iii) ''Conducting the Final Level 3 (DIBCAC)''. DCMA DIBCAC will perform a Level 3 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2) and the CMMC Level 3 scoping requirements set forth in § 170.19(d) for the information systems within the CMMC Assessment Scope. The Level 3 certification assessment will be scored in accordance with the CMMC Scoring Methodology set forth in § 170.24 and DCMA DIBCAC will upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report. For assets that changed asset category (''i.e''., CRMA to CUI Asset) or assessment requirements (''i.e''., Specialized Assets) between the Level 2 and Level 3 certification assessments, DCMA DIBCAC will perform limited checks of Level 2 security requirements. If the OSC had these upgraded asset categories included in their Level 2 certification assessment, then DCMA DIBCAC may still perform limited checks for compliance. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 3 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) The additional evidence does not materially impact previously assessed security requirements; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment will be performed by DCMA DIBCAC within 180-days of the Conditional CMMC Status Date. Additional guidance is located in § 170.21 and in the guidance document listed in paragraph (d) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. Assessors will collect the list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used and upload that data into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 3 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The OSC may utilize a CSP product or service offering that meets the FedRAMP Moderate (or higher) baseline. If the CSP’s product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline, the product or service offering must meet security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline in accordance with DoD Policy.

(ii) Use of a CSP does not relieve an OSC of its obligation to implement the 24 Level 3 security requirements. These 24 requirements apply to every environment where the CUI data is processed, stored, or transmitted, when Level 3 (DIBCAC) is the designated CMMC Status. If any of these 24 requirements are inherited from a CSP, the OSC must demonstrate that protection during a Level 3 certification assessment via a Customer Implementation Summary/Customer Responsibility Matrix (CIS/CRM) and associated Body of Evidence (BOE). The BOE must clearly indicate whether the OSC or the CSP is responsible for meeting each requirement and which requirements are implemented by the OSC versus inherited from the CSP.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 3 certification assessment with the use of an ESP, not a CSP''. An OSC may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The use of the ESP, its relationship to the OSC, and the services provided are documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSC requirements are assessed within the scope of the OSC’s assessment against all Level 2 and Level 3 security requirements.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

=== § 170.19 CMMC scoping. ===

(a) ''Scoping requirement''. (1) The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of this section. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

(2) The requirements for defining the CMMC Assessment Scope for CMMC Levels 1, 2, and 3 are set forth in this section. Additional guidance regarding scoping can be found in the guidance documents listed in paragraphs (e) through (g) of appendix A to this part.

(b) ''CMMC Level 1 scoping''. Prior to performing a Level 1 self-assessment, the OSA must specify the CMMC Assessment Scope.

(1) ''Assets in scope for Level 1 self-assessment''. OSA information systems which process, store, or transmit FCI are in scope for CMMC Level 1 and must be self-assessed against applicable CMMC security requirements.

(2) ''Assets not in scope for Level 1 self-assessment'' - (i) ''Out-of-Scope Assets''. OSA information systems which do not process, store, or transmit FCI are outside the scope for CMMC Level 1. An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of FCI beyond the Keyboard/Video/Mouse sent to the VDI client is considered out-of-scope. There are no documentation requirements for out-of-scope assets.

(ii) ''Specialized Assets''. Specialized Assets are those assets that can process, store, or transmit FCI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment. Specialized Assets are not part of the Level 1 CMMC Assessment Scope and are not assessed against CMMC security requirements.

(3) ''Level 1 self-assessment scoping considerations''. To scope a Level 1 self-assessment, OSAs should consider the people, technology, facilities, and External Service Providers (ESP) within its environment that process, store, or transmit FCI.

(c) ''CMMC Level 2 Scoping''. Prior to performing a Level 2 self-assessment or Level 2 certification assessment, the OSA must specify the CMMC Assessment Scope.

(1) The CMMC Assessment Scope for CMMC Level 2 is based on the specification of asset categories and their respective requirements as defined in table 3 to this paragraph (c)(1). Additional information is available in the guidance document listed in paragraph (f) of appendix A to this part.

==== Table 3 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 3 TO § 170.19(c)(1) - CMMC LEVEL 2 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against all Level 2 security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSA’s CMMC As-sessment Scope.
|
* Document in the asset inventory
* Document asset treatment in SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against Level 2 security requirements that are relevant to the ca-pabilities provided.
|- style="vertical-align:top;"
| Contractor Risk Managed Assets.
|
* Assets that can, but are not intended to, process, store, or transmit CUI be-cause of security policy, procedures, and practices in place.
* Assets are not required to be physically or logically separated from CUI assets.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC secu-rity requirements, except as noted.
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies.
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost.
** The limited check(s) will be assessed against CMMC security re-quirements.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Show these assets are managed using the contractor’s risk-based security poli-cies, procedures, and practices.
* Document in the network diagram of the CMMC Assessment Scope.
|
* Review the SSP.
* Do not assess against other CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
|Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 4 to this paragraph (c)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 4 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 4 TO § 170.19(c)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum assessment type for the ESP is dictated by the OSA’s DoD contract requirement.

(d) ''CMMC Level 3 scoping''. Prior to performing a Level 3 certification assessment, the CMMC Assessment Scope must be specified.

(1) The CMMC Assessment Scope for Level 3 is based on the specification of asset categories and their respective requirements as set forth in table 5 to this paragraph (d)(1). Additional information is available in the guidance document listed in paragraph (g) of appendix A to this part.

==== Table 5 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 5 TO § 170.19(d)(1) - CMMC LEVEL 3 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Assets that can, but are not intended to, process, store, or transmit CUI (de-fined as Contractor Risk Managed As-sets in table 1 to paragraph (c)(1) of this section CMMC Scoping).
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSC’s CMMC As-sessment Scope, irrespective of wheth-er or not these assets process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements that are relevant to the capabilities provided.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
* Intermediary devices are permitted to provide the capability for the special-ized asset to meet one or more CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 6 to this paragraph (d)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 6 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 6 TO § 170.19(d)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSC, and the services provided need to be documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSC and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum. The minimum assessment type for the ESP is dictated by the OSC’s DoD contract requirement.

(e) ''Relationship between Level 2 and Level 3 CMMC Assessment Scope''. The Level 3 CMMC Assessment Scope must be equal to or a subset of the Level 2 CMMC Assessment Scope in accordance with § 170.18(a) (''e.g.'', a Level 3 data enclave with greater restrictions and protections within a Level 2 data enclave). Any Level 2 POA&M items must be closed prior to the initiation of the Level 3 certification assessment. DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated. For further information regarding scoping of CMMC Level 3 assessments please contact DCMA DIBCAC at ''www.dcma.mil/DIBCAC/''.

=== § 170.20 Standards acceptance. ===

(a) ''NIST SP 800-171 R2 DoD assessments''. In order to avoid duplication of efforts, thereby reducing the aggregate cost to industry and the Department, OSCs that have completed a DCMA DIBCAC High Assessment aligned with CMMC Level 2 Scoping will be given the CMMC Status of Final Level 2 (C3PAO) under the following conditions:

(1) ''DCMA DIBCAC High Assessment''. An OSC that achieved a perfect score with no open POA&M from a DCMA DIBCAC High Assessment conducted prior to the effective date of this rule, will be given a CMMC Status of Level 2 Final (C3PAO) with a validity period of three (3) years from the date of the original DCMA DIBCAC High Assessment. DCMA DIBCAC will identify assessments that meet these criteria and verify that SPRS accurately reflects the CMMC Status. Eligible DCMA DIBCAC High Assessments include ones conducted with Joint Surveillance in accordance with the DCMA Manual 2302-01 Surveillance. The scope of the Level 2 certification assessment is identical to the scope of the DCMA DIBCAC High Assessment. In accordance with § 170.17(a)(2), the OSC must also submit an affirmation in SPRS and annually thereafter to achieve contractual eligibility.

(2) [Reserved]. 
(b) [Reserved]. 

=== § 170.21 Plan of Action and Milestones requirements. ===

(a) ''POA&M''. For purposes of achieving a Conditional CMMC Status, an OSA is only permitted to have a POA&M for select requirements scored as NOT MET during the CMMC assessment and only under the following conditions:

(1) ''Level 1 self-assessment''. A POA&M is not permitted at any time for Level 1 self-assessments.

(2) ''Level 2 self-assessment and Level 2 certification assessment''. An OSA is only permitted to achieve the CMMC Status of Conditional Level 2 (Self) or Conditional Level 2 (C3PAO), as appropriate, if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 2 security requirements is greater than or equal to 0.8;

(ii) None of the security requirements included in the POA&M have a point value of greater than 1 as specified in the CMMC Scoring Methodology set forth in § 170.24, except SC.L2-3.13.11 CUI Encryption may be included on a POA&M if encryption is employed but it is not FIPS-validated, which would result in a point value of 3; and

(iii) None of the following security requirements are included in the POA&M:

(A) AC.L2-3.1.20 External Connections (CUI Data). 
(B) AC.L2-3.1.22 Control Public Information (CUI Data). 
(C) CA.L2-3.12.4 System Security Plan. 
(D) PE.L2-3.10.3 Escort Visitors (CUI Data). 
(E) PE.L2-3.10.4 Physical Access Logs (CUI Data). 
(F) PE.L2-3.10.5 Manage Physical Access (CUI Data). 

(3) ''Level 3 certification assessment''. An OSC is only permitted to achieve the CMMC Status of Conditional Level 3 (DIBCAC) if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 3 security requirements is greater than or equal to 0.8; and

(ii) The POA&M does not include any of following security requirements:

(A) IR.L3-3.6.1e Security Operations Center. 
(B) IR.L3-3.6.2e Cyber Incident Response Team. 
(C) RA.L3-3.11.1e Threat-Informed Risk Assessment. 
(D) RA.L3-3.11.6e Supply Chain Risk Response. 
(E) RA.L3-3.11.7e Supply Chain Risk Plan. 
(F) RA.L3-3.11.4e Security Solution Rationale. 
(G) SI.L3-3.14.3e Specialized Asset Security. 

(b) ''POA&M closeout assessment''. A POA&M closeout assessment is a CMMC assessment that assesses only the NOT MET requirements that were identified with POA&M in the initial assessment. The closing of a POA&M must be confirmed by a POA&M closeout assessment within 180-days of the Conditional CMMC Status Date. If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional CMMC Status for the information system will expire.

(1) ''Level 2 self-assessment''. For a Level 2 self-assessment, the POA&M closeout self-assessment shall be performed by the OSA in the same manner as the initial self-assessment.

(2) ''Level 2 certification assessment''. For Level 2 certification assessment, the POA&M closeout certification assessment must be performed by an authorized or accredited C3PAO.

(3) ''Level 3 certification assessment''. For Level 3 certification assessment, DCMA DIBCAC will perform the POA&M closeout certification assessment.

=== § 170.22 Affirmation. ===

(a) ''General''. The OSA must affirm continuing compliance with the appropriate level self-assessment or certification assessment. An Affirming Official from each OSA, whether a prime or subcontractor, must affirm the continuing compliance of their respective organizations with the specified security requirement after every assessment, including POA&M closeout, and annually thereafter. Affirmations are entered electronically in SPRS. The affirmation shall be submitted in accordance with the following requirements:

(1) ''Affirming Official''. The Affirming Official is the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations.

(2) ''Affirmation content''. Each CMMC affirmation shall include the following information:

(i) Name, title, and contact information for the Affirming Official; and

(ii) Affirmation statement attesting that the OSA has implemented and will maintain implementation of all applicable CMMC security requirements to their CMMC Status for all information systems within the relevant CMMC Assessment Scope.

(3) ''Affirmation submission''. The Affirming Official shall submit a CMMC affirmation in the following instances:

(i) Upon achievement of a Conditional CMMC Status, as applicable;

(ii) Upon achievement of a Final CMMC Status;

(iii) Annually following a Final CMMC Status Date; and

(iv) Following a POA&M closeout assessment, as applicable.

(b) ''Submission procedures''. All affirmations shall be completed in SPRS. The Department will verify submission of the affirmation in SPRS to ensure compliance with CMMC solicitation or contract requirements.

(1) ''Level 1 self-assessment''. At the

completion of a Level 1 self-assessment and annually thereafter, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 1 (Self).

(2) ''Level 2 self-assessment''. At the

completion of a Level 2 self-assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (Self). An affirmation shall also be submitted at the completion of a POA&M closeout self-assessment.

(3) ''Level 2 certification assessment''. At

the completion of a Level 2 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (C3PAO). An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

(4) ''Level 3 certification assessment''. At

the completion of a Level 3 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 3 (DIBCAC). Because C3PAOs and DCMA DIBCAC check for compliance with different requirements in their respective assessments, OSCs must annually affirm their CMMC Status of Level 2 (C3PAO) in addition to their CMMC Status of Level 3 (DIBCAC) to maintain eligibility for contracts requiring compliance with Level 3. An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

=== § 170.23 Application to subcontractors. ===

(a) CMMC requirements apply to prime contractors and subcontractors throughout the supply chain at all tiers that will process, store, or transmit any FCI or CUI on contractor information systems in the performance of the DoD contract or subcontract. Prime contractors shall comply and shall require subcontractors to comply with and to flow down CMMC requirements, such that compliance will be required throughout the supply chain at all tiers with the applicable CMMC level and assessment type for each subcontract as follows:

(1) If a subcontractor will only process, store, or transmit FCI (and not CUI) in performance of the subcontract, then a CMMC Status of Level 1 (Self) is required for the subcontractor.

(2) If a subcontractor will process, store, or transmit CUI in performance of the subcontract, then a CMMC Status of Level 2 (Self) is the minimum requirement for the subcontractor.

(3) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for a CMMC Status of Level 2 (C3PAO), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(4) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for the CMMC Status of Level 3 (DIBCAC), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(b) As with any solicitation or contract, the DoD may provide specific guidance pertaining to flow-down.

=== § 170.24 CMMC Scoring Methodology. ===

(a) ''General''. This scoring methodology is designed to provide a measurement of an OSA’s implementation status of the NIST SP 800-171 R2 security requirements (incorporated by reference elsewhere in this part, see § 170.2) and the selected NIST SP 800-172 Feb2021 security requirements (incorporated by reference elsewhere in this part, see § 170.2). The CMMC Scoring Methodology is designed to credit partial implementation only in limited cases (''e.g.'', multi-factor authentication IA.L2-3.5.3).

(b) ''Assessment findings''. Each security requirement assessed under the CMMC Scoring Methodology must result in one of three possible assessment findings, as follows:

(1) ''Met''. All applicable objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include but are not limited to working papers, drafts, and unofficial or unapproved policies.

(i) Enduring exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.

(ii) Temporary deficiencies that are appropriately addressed in operational plans of action (''i.e.'', include deficiency reviews and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.

(2) ''Not Met''. One or more applicable objectives for the security requirement is not satisfied. During an assessment, for each security requirement objective marked NOT MET, the assessor will document why the evidence does not conform.

(3) ''Not Applicable (N/A)''. A security requirement and/or objective does not apply at the time of the CMMC assessment. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.

(c) ''Scoring''. At each CMMC Level, security requirements are scored as follows:

(1) ''CMMC Level 1''. All CMMC Level 1 security requirements must be fully implemented to be considered MET. No POA&M is permitted for CMMC Level 1, and self-assessment results are scored as MET or NOT MET in their entirety.

(2) ''CMMC Level 2 Scoring Methodology''. The maximum score achievable for a Level 2 self-assessment or Level 2 certification assessment is equal to the total number of CMMC Level 2 security requirements. If all CMMC Level 2 security requirements are MET, OSAs are awarded the maximum score. For each requirement NOT MET, the associated value of the security requirement is subtracted from the maximum score, which may result in a negative score.

(i) ''Procedures''. (A) Scoring methodology for Level 2 self-assessment and Level 2 certification assessment is based on all CMMC Level 2 security requirement objectives, including those NOT MET.

(B) In the CMMC Level 2 Scoring Methodology, each security requirement has a value (''e.g.'', 1, 3 or 5), which is related to the designation by NIST as basic or derived security requirements. Per NIST SP 800-171 R2, the basic security requirements are obtained from FIPS PUB 200 Mar2006, which provides the high-level and fundamental security requirements for Federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in NIST SP 800-53 R5.

(''1'') For NIST SP 800-171 R2 basic and derived security requirements that, if not implemented, could lead to significant exploitation of the network, or exfiltration of CUI, five (5) points are subtracted from the maximum score. The basic and derived security requirements with a value of five (5) points include:

(''i'') ''Basic security requirements''. AC.L2-3.1.1, AC.L2-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA-L2-3.5.1, IA-L2-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L2-3.8.3, PS.L2-3.9.2, PE.L2-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L2-3.13.1, SC.L2-3.13.2, SI.L2-3.14.1, SI.L2-3.14.2, and SI.L2-3.14.3.

(''ii'') ''Derived security requirements''. AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L2-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L2-3.14.4, and SI.L2-3.14.6.

(''2'') For basic and derived security requirements that, if not implemented, have a specific and confined effect on the security of the network and its data, three (3) points are subtracted from the maximum score. The basic and derived security requirements with a value of three (3) points include:

(''i'') ''Basic security requirements''. AU.L2-3.3.2, MA.L2-3.7.1, MP.L2-3.8.1, MP.L2-3.8.2, PS.L2-3.9.1, RA.L2-3.11.1, and CA.L2-3.12.2.

(''ii'') ''Derived security requirements''. AC.L2-3.1.5, AC.L2-3.1.19, MA.L2-3.7.4, MP.L2-3.8.8, SC.L2-3.13.8, SI.L2-3.14.5, and SI.L2-3.14.7.

(''3'') All remaining derived security requirements, other than the exceptions noted, if not implemented, have a limited or indirect effect on the security of the network and its data. For these, 1 point is subtracted from the maximum score.

(''4'') Two derived security requirements, IA.L2-3.5.3 and SC.L2-3.13.11, can be partially effective even if not completely or properly implemented, and the points deducted may be adjusted depending on how the security requirement is implemented.

(''i'') Multi-factor authentication (MFA) (CMMC Level 2 security requirement IA.L2-3.5.3) is typically implemented first for remote and privileged users (since these users are both limited in number and more critical) and then for the general user, so three (3) points are subtracted from the maximum score if MFA is implemented only for remote and privileged users. Five (5) points are subtracted from the maximum score if MFA is not implemented for any users.

(''ii'') FIPS-validated encryption (CMMC Level 2 security requirement SC.L2-3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS-validated, three (3) points are subtracted from the maximum score; if encryption is not employed; five (5) points are subtracted from the maximum score.

(''5'') OSAs must have a System Security Plan (SSP) (CMMC security requirement CA.L2-3.12.4) in place at the time of assessment to describe each information system within the CMMC Assessment Scope. The absence of an up to date SSP at the time of the assessment would result in a finding that ‘''an assessment could not be completed due to incomplete information and noncompliance with 48 CFR 252.204- 7012.''’

(''6'') For each NOT MET security requirement the OSA must have a POA&M in place. A POA&M addressing NOT MET security requirements is not a substitute for a completed requirement. Security requirements not implemented, whether described in a POA&M or not, is assessed as ‘NOT MET.’

(''7'') Specialized Assets must be evaluated for their asset category per the CMMC scoping guidance for the level in question and handled accordingly as set forth in § 170.19.

(''8'') If an OSC previously received a favorable adjudication from the DoD CIO indicating that a security requirement is not applicable or that an alternative security measure is equally effective (in accordance with 48 CFR 252.204-7008 or 48 CFR 252.204-7012), the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. A security requirement for which implemented security measures have been adjudicated by the DoD CIO as equally effective is assessed as MET if there have been no changes in the environment.

(ii) ''CMMC Level 2 Scoring Table''. CMMC Level 2 scoring has been assigned based on the methodology set forth in table 1 to this paragraph (c)(2)(ii).

==== Table 7 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 7 TO § 170.24(c)(2)(ii) - CMMC LEVEL 2 SCORING TABLE
|-
! style="width: 80%;text-align:left" | CMMC Level 2 requirement categories
! style="width: 20%;text-align:right" | Point value subtracted from maximum score
|-
| colspan="2" | ''Basic Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|-
| colspan="2" | ''Derived Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not completely or properly implemented, could be partially effective and points adjusted depending on how the security requirement is implemented:
:: - Partially effective implementation - 3 points.
:: - Non-effective (not implemented at all) - 5 points.
| style="text-align:right;" | 3 or 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|- style="vertical-align:top;"
|
: If not implemented, has a limited or indirect effect on the security of the network and its data
| style="text-align:right;" | 1
|}

(3) ''CMMC Level 3 assessment scoring methodology''. CMMC Level 3 scoring does not utilize varying values like the scoring for CMMC Level 2. All CMMC Level 3 security requirements use a value of one (1) point for each security requirement. As a result, the maximum score achievable for a Level 3 certification assessment is equivalent to the total number of the selected subset of NIST SP 800-172 Feb2021 security requirements for CMMC Level 3, see § 170.14(c)(4). The maximum score is reduced by one (1) point for each security requirement NOT MET. The CMMC Level 3 scoring methodology reflects the fact that all CMMC Level 2 security requirements must already be MET (for the Level 3 CMMC Assessment Scope). A maximum score on the Level 2 certification assessment is required to be eligible to initiate a Level 3 certification assessment. The Level 3 certification assessment score is equal to the number of CMMC Level 3 security requirements that are assessed as MET.

=== Appendix A to Part 170 - Guidance ===

Guidance documents include:

(a) ‘‘CMMC Model Overview’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(b) ‘‘CMMC Assessment Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(c) ‘‘CMMC Assessment Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(d) ‘‘CMMC Assessment Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(e) ‘‘CMMC Scoping Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(f) ‘‘CMMC Scoping Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(g) ‘‘CMMC Scoping Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(h) ‘‘CMMC Hashing Guide’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

Dated: September 30, 2024.

'''Patricia L. Toppings'', '''OSD Federal Register Liaison Officer, Department of Defense''. [FR Doc. 2024-22905 Filed 10-11-24; 8:45 am]

'''BILLING CODE 6001-FR-P'''

32 CFR Part 170

2025-05-28T22:06:56Z

David: /* § 170.4 Acronyms and definitions. */

'''Source of Reference: The official [https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program Cybersecurity Maturity Model Certification (CMMC) Program] final rule.'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== PART 170 - CYBERSECURITY MATURITY MODEL CERTIFICATION (CMMC) PROGRAM ==

=== Subpart A - General Information ===
Sec.
* 170.1 Purpose.
* 170.2 Incorporation by reference.
* 170.3 Applicability.
* 170.4 Acronyms and definitions.
* 170.5 Policy.

=== Subpart B - Government Roles and Responsibilities ===
* 170.6 CMMC PMO.
* 170.7 DCMA DIBCAC.

=== Subpart C - CMMC Assessment and Certification Ecosystem ===
* 170.8 Accreditation Body.
* 170.9 CMMC Third-Party Assessment Organizations (C3PAOs).
* 170.10 CMMC Assessor and Instructor Certification Organization (CAICO).
* 170.11 CMMC Certified Assessor (CCA).
* 170.12 CMMC Instructor.
* 170.13 CMMC Certified Professional (CCP).

=== Subpart D - Key Elements of the CMMC Program ===
* 170.14 CMMC Model.
* 170.15 CMMC Level 1 self-assessment and affirmation requirements.
* 170.16 CMMC Level 2 self-assessment and affirmation requirements.
* 170.17 CMMC Level 2 certification assessment and affirmation requirements.
* 170.18 CMMC Level 3 certification assessment and affirmation requirements.
* 170.19 CMMC scoping.
* 170.20 Standards acceptance.
* 170.21 Plan of Action and Milestones requirements.
* 170.22 Affirmation.
* 170.23 Application to subcontractors.
* 170.24 CMMC Scoring Methodology.
* Appendix A to Part 170 - Guidance

'''Authority''': 5 U.S.C. 301; Sec. 1648, Pub. L. 116-92, 133 Stat. 1198.

== Subpart A - General Information. ==
=== § 170.1 Purpose. ===
(a) This part describes the Cybersecurity Maturity Model Certification (CMMC) Program of the Department of Defense (DoD) and establishes requirements for defense contractors and subcontractors to implement prescribed cybersecurity standards for safeguarding Federal Contract Information (FCI) and Controlled Unclassified Information (CUI). This part (the CMMC Program) also establishes requirements for conducting an assessment of compliance with the applicable prescribed cybersecurity standard for contractor information systems that: process, store, or transmit FCI or CUI; provide security protections for systems which process, store, or transmit CUI; or are not logically or physically isolated from systems which process, store, or transmit CUI.

(b) The CMMC Program provides DoD with a viable means of conducting the volume of assessments necessary to verify contractor and subcontractor implementation of required cybersecurity requirements.

(c) The CMMC Program is designed to ensure defense contractors are properly safeguarding FCI and CUI that is processed, stored, or transmitted on defense contractor information systems. FCI and CUI must be protected to meet evolving threats and safeguard nonpublic, unclassified information that supports and enables the warfighter. The CMMC Program provides a consistent methodology to assess a defense contractor’s implementation of required cybersecurity requirements. The CMMC Program utilizes the security standards set forth in the 48 CFR 52.204-21; National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, ''Basic Safeguarding of Covered Contractor Information Systems, ''Revision 2, February 2020 (includes updates as of January 28, 2021) (NIST SP 800-171 R2); and selected requirements from the NIST SP 800-172, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, ''February 2021 (NIST SP 800-172 Feb2021), as applicable (see table 1 to § 170.14(c)(4) for requirements, see § 170.2 for availability of NIST publications).

(d) The CMMC Program balances the need to safeguard FCI and CUI and the requirement to share information appropriately with defense contractors in order to develop capabilities for the DoD. The CMMC Program is designed to ensure implementation of cybersecurity practices for defense contractors and to provide DoD with increased assurance that FCI and CUI information will be adequately safeguarded when residing on or transiting contractor information systems.

(e) The CMMC Program creates no right or benefit, substantive or procedural, enforceable by law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.

=== § 170.2 Incorporation by reference. ===

Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. Material approved for incorporation by reference (IBR) is available for inspection at the Department of Defense (DoD) and at the National Archives and Records Administration (NARA). Contact DoD online: ''https://DoDcio.defense.gov/CMMC/''; email: ''osd.mc-alex.DoD-cio.mbx.cmmc-rule@mail.mil''; or phone: (202) 770-9100. For information on the availability of this material at NARA, visit: ''www.archives.gov/federal-register/ cfr/ibr-locations'' or email: ''fr.inspection@nara.gov''. The material may be obtained from the following sources:

(a) National Institute of Standards and Technology, U.S. Department of Commerce, 100 Bureau Drive, Gaithersburg, MD 20899; phone: (301) 975-8443; website: ''https://csrc.nist.gov/ publications/''.

(1) FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006 (FIPS PUB 200 Mar2006); IBR approved for § 170.4(b).

(2) FIPS PUB 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022 (FIPS PUB 201-3 Jan2022); IBR approved for § 170.4(b).

(3) SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, Revision 2, December 2018 (NIST SP 800-37 R2); IBR approved for § 170.4(b).

(4) SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View, March 2011 (NIST SP 800-39 Mar2011); IBR approved for § 170.4(b).

(5) SP 800-53, Security and Privacy Controls for Information Systems and Organizations, Revision 5, September 2020 (includes updates as of December 10, 2020) (NIST SP 800-53 R5); IBR approved for § 170.4(b).

(6) SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023 (NIST SP 800-82r3); IBR approved for § 170.4(b).

(7) SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008 (NIST SP 800-115 Sept2008); IBR approved for § 170.4(b).

(8) SP 800-160, Volume 2, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, Revision 1, December 2021 (NIST SP 800-160 V2R1); IBR approved for § 170.4(b).

(9) SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 2, February 2020 (includes updates as of January 28, 2021), (NIST SP 800-171 R2); IBR approved for §§ 170.4(b) and 170.14(a) through (c).

(10) SP 800-171A, Assessing Security Requirements for Controlled Unclassified Information, June 2018 (NIST SP 800-171A Jun2018); IBR approved for §§ 170.11(a), 170.14(d), 170.15(c), 170.16(c), 170.17(c), and 170.18(c).

(11) SP 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171, February 2021 (NIST SP 800-172 Feb2021); IBR approved for §§ 170.4(b), 170.5(a), and 170.14(a) and (c).

(12) SP 800-172A, Assessing Enhanced Security Requirements for Controlled Unclassified Information, March 2022 (NIST SP 800-172A Mar2022); IBR approved for §§ 170.4(b), 170.14(d), and 170.18(c).

(b) International Organization for Standardization (ISO) Chemin de Blandonnet 8, CP 401 - 1214 Vernier, Geneva, Switzerland; phone: +41 22 749 01 11; website: ''www.iso.org/popular- standards.html''.

(1) ISO/IEC 17011:2017(E), Conformity assessment - Requirements for accreditation bodies accrediting conformity assessment bodies, Second edition, November 2017 (ISO/IEC 17011:2017(E)); IBR approved for §§ 170.8(b)(3), 170.9(b)(13), and 170.10(b)(4).

(2) ISO/IEC 17020:2012(E), Conformity assessment - Requirement for the operation of various types of bodies performing inspection, Second edition, March 1, 2012 (ISO/IEC 17020:2012(E)); IBR approved for §§ 170.8(a), (b)(1), (b)(3) and 170.9(b)(2) and (b)(13).

(3) ISO/IEC 17024:2012(E), Conformity assessment - General requirements for bodies operating certification of persons, second edition, July 1, 2012 (ISO/IEC 17024:2012(E)); IBR approved for §§ 170.8(b)(2) and 170.10(a) and (b)(4), (7), and (8).

'''Note 1 to paragraph (b):''' The ISO/IEC standards incorporated by reference in this part may be viewed at no cost in ‘‘read only’’ format at ''https://ibr.ansi.org''.

=== § 170.3 Applicability. ===

(a) The requirements of this part apply to:

(1) All DoD contract and subcontract awardees that will process, store, or transmit information, in performance of the DoD contract, that meets the standards for FCI or CUI on contractor information systems; and,

(2) Private-sector businesses or other entities comprising the CMMC Assessment and Certification Ecosystem, as specified in subpart C of this part.

(b) The requirements of this part do not apply to Federal information systems operated by contractors or subcontractors on behalf of the Government.

(c) CMMC Program requirements apply to all DoD solicitations and contracts pursuant to which a defense contractor or subcontractor will process, store, or transmit FCI or CUI on unclassified contractor information systems, including those for the acquisition of commercial items (except those exclusively for COTS items) valued at greater than the micro- purchase threshold except under the following circumstances:

(1) The procurement occurs during Implementation Phase 1, 2, or 3 as described in paragraph (e) of this section, in which case CMMC Program requirements apply in accordance with the requirements for the relevant phase- in period; or

(2) Application of CMMC Program requirements to a procurement or class of procurements may be waived in advance of the solicitation at the discretion of DoD in accordance with all applicable policies, procedures, and approval requirements.

(d) DoD Program Managers or requiring activities are responsible for selecting the CMMC Status that will apply for a particular procurement or contract based upon the type of information, FCI or CUI, that will be processed on, stored on, or transmitted through a contractor information system. Application of the CMMC Status for subcontractors will be determined in accordance with § 170.23.

(e) DoD is utilizing a phased approach for the inclusion of CMMC Program requirements in solicitations and contracts. Implementation of CMMC Program requirements will occur over four (4) phases:

(1) ''Phase 1''. Begins on the effective date of the complementary 48 CFR part 204 CMMC Acquisition final rule. DoD intends to include the requirement for CMMC Statuses of Level 1 (Self) or Level 2 (Self) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, include the requirement for CMMC Status of Level 1 (Self) or Level 2 (Self) for applicable DoD solicitations and contracts as a condition to exercise an option period on a contract awarded prior to the effective date. DoD may also, at its discretion, include the requirement for CMMC Status of Level 2 (C3PAO) in place of the Level 2 (Self) CMMC Status for applicable DoD solicitations and contracts.

(2) ''Phase 2''. Begins one calendar year following the start date of Phase 1. In addition to Phase 1 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 2 (C3PAO) to an option period instead of as a condition of contract award. DoD may also, at its discretion, include the requirement for CMMC Status of Level 3 (DIBCAC) for applicable DoD solicitations and contracts.

(3) ''Phase 3''. Begins one calendar year following the start date of Phase 2. In addition to Phase 1 and 2 requirements, DoD intends to include the requirement for CMMC Status of Level 2 (C3PAO) for all applicable DoD solicitations and contracts as a condition of contract award and as a condition to exercise an option period on a contract awarded after the effective date. DoD intends to include the requirement for CMMC Status of Level 3 (DIBCAC) for all applicable DoD solicitations and contracts as a condition of contract award. DoD may, at its discretion, delay the inclusion of requirement for CMMC Status of Level 3 (DIBCAC) to an option period instead of as a condition of contract award.

(4) ''Phase 4, full implementation''. Begins one calendar year following the start date of Phase 3. DoD will include CMMC Program requirements in all applicable DoD solicitations and contracts including option periods on contracts awarded prior to the beginning of Phase 4.

=== § 170.4 Acronyms and definitions. ===

(a) ''Acronyms. ''Unless otherwise noted, the following acronyms and their terms are for the purposes of this part.

AC - Access Control 
APT - Advanced Persistent Threat 
AT - Awareness and Training 
C3PAO - CMMC Third-Party Assessment Organization 
CA - Security Assessment CAICO - CMMC Assessors and Instructors Certification Organization 
CAGE - Commercial and Government Entity 
CCA - CMMC-Certified Assessor 
CCI - CMMC-Certified Instructor 
CCP - CMMC-Certified Professional 
CFR - Code of Federal Regulations 
CIO - Chief Information Officer 
CM - Configuration Management CMMC - Cybersecurity Maturity Model Certification 
CMMC PMO - CMMC Program Management Office 
CNC - Computerized Numerical Control 
CoPC - Code of Professional Conduct 
CSP - Cloud Service Provider 
CUI - Controlled Unclassified Information 
DCMA - Defense Contract Management Agency 
DD - Represents any two-character CMMC Domain acronym 
DFARS - Defense Federal Acquisition Regulation Supplement 
DIB - Defense Industrial Base DIBCAC - DCMA’s Defense Industrial Base Cybersecurity Assessment Center 
DoD - Department of Defense DoDI - Department of Defense Instruction 
eMASS - Enterprise Mission Assurance Support Service 
ESP - External Service Provider 
FAR - Federal Acquisition Regulation 
FCI - Federal Contract Information 
FedRAMP - Federal Risk and Authorization Management Program 
GFE - Government Furnished Equipment 
IA - Identification and Authentication 
ICS - Industrial Control System 
IIoT - Industrial Internet of Things 
IoT - Internet of Things 
IR - Incident Response 
IS - Information System 
IEC - International Electrotechnical Commission 
ISO/IEC - International Organization for Standardization/International Electrotechnical Commission 
IT - Information Technology 
L# - CMMC Level Number 
MA - Maintenance 
MP - Media Protection 
MSSP - Managed Security Service Provider 
NARA - National Archives and Records Administration 
NAICS - North American Industry Classification System 
NIST - National Institute of Standards and Technology 
N/A - Not Applicable 
ODP - Organization-Defined Parameter 
OSA - Organization Seeking Assessment 
OSC - Organization Seeking Certification 
OT - Operational Technology 
PI - Provisional Instructor 
PIEE - Procurement Integrated Enterprise Environment 
PII - Personally Identifiable Information 
PLC - Programmable Logic Controller 
POA&M - Plan of Action and Milestones 
PRA - Paperwork Reduction Act 
RM - Risk Management 
SAM - System of Award Management 
SC - System and Communications Protection 
SCADA - Supervisory Control and Data Acquisition 
SI - System and Information Integrity 
SIEM - Security Information and Event Management 
SP - Special Publication 
SPD - Security Protection Data 
SPRS - Supplier Performance Risk System 
SSP - System Security Plan 

(b) ''Definitions''. Unless otherwise noted, these terms and their definitions are for the purposes of this part.

''Access Control (AC) ''means the process of granting or denying specific requests to obtain and use information and related information processing services; and/or entry to specific physical facilities (''e.g., ''Federal buildings, military establishments, or border crossing entrances), as defined in FIPS PUB 201-3 Jan2002 (incorporated by reference, see § 170.2).

''Accreditation'' means a status pursuant to which a CMMC Assessment and Certification Ecosystem member (person or organization), having met all criteria for the specific role they perform including required ISO/IEC accreditations, may act in that role as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC- custom term)

''Accreditation Body'' is defined in § 170.8 and means the one organization DoD contracts with to be responsible for authorizing and accrediting members of the CMMC Assessment and Certification Ecosystem, as required. The Accreditation Body must be approved by DoD. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program. (CMMC-custom term)

''Advanced Persistent Threat (APT) ''means an adversary that possesses sophisticated levels of expertise and significant resources that allow it to create opportunities to achieve its objectives by using multiple attack vectors (''e.g.'', cyber, physical, and deception). These objectives typically include establishing and extending footholds within the information technology infrastructure of the targeted organizations for purposes of exfiltrating information, undermining or impeding critical aspects of a mission, program, or organization; or positioning itself to carry out these objectives in the future. The advanced persistent threat pursues its objectives repeatedly over an extended period-of-time, adapts to defenders’ efforts to resist it, and is determined to maintain the level of interaction needed to execute its objectives, as is defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Affirming Official'' means the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations. (CMMC-custom term)

''Assessment'' means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in §§ 170.15 through 170.18. (CMMC-custom term)

(i) ''Level 1 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 1 (Self).

(ii) ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).

(iii) ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).

(iv) ''Level 3 certification assessment'' is the term for the activity performed by the DCMA DIBCAC to evaluate the information system of an OSC when seeking a CMMC Status of Level 3 (DIBCAC).

(v) ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).

(vi) ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.

''Assessment Findings Report'' means the final written assessment results by the third-party or government assessment team. The Assessment Findings Report is submitted to the OSC and to the DoD via CMMC eMASS. (CMMC-custom term)

''Assessment objective'' means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) or NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). (CMMC-custom term)

''Assessment Team'' means participants in the Level 2 certification assessment (CMMC Certified Assessors and CMMC Certified Professionals) or the Level 3 certification assessment (DCMA DIBCAC assessors). This does not include the OSC participants preparing for or participating in the assessment. (CMMC-custom term)

''Asset'' means an item of value to stakeholders. An asset may be tangible (''e.g.'', a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (''e.g.'', humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Asset Categories'' means a grouping of assets that process, store or transmit information of similar designation, or provide security protection to those assets. (CMMC-custom term)

''Authentication'' is defined in FIPS PUB 200 Mar2006 (incorporated by reference, see § 170.2).

''Authorized'' means an interim status during which a CMMC Ecosystem member (person or organization), having met all criteria for the specific role they perform other than the required ISO/IEC accreditations, may act in that role for a specified time as set forth in § 170.8 for the Accreditation Body and § 170.9 for C3PAOs. (CMMC-custom term)

''Capability'' means a combination of mutually reinforcing controls implemented by technical means, physical means, and procedural means. Such controls are typically selected to achieve a common information security or privacy purpose, as defined in NIST SP 800-37 R2 (incorporated by reference, see § 170.2).

''Cloud Service Provider (CSP) ''means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable computing resources (''e.g.'', networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This definition is based on the definition for cloud computing in NIST SP 800-145 Sept2011. (CMMC-custom term)

''CMMC Assessment and Certification Ecosystem'' means the people and organizations described in subpart C of this part. This term is sometimes shortened to CMMC Ecosystem. (CMMC-custom term)

''CMMC Assessment Scope'' means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements. (CMMC-custom term)

''CMMC Assessor and Instructor Certification Organization (CAICO) ''is defined in § 170.10 and means the organization responsible for training, testing, authorizing, certifying, and recertifying CMMC certified assessors, certified instructors, and certified professionals. (CMMC-custom term)

''CMMC Instantiation of eMASS'' means a CMMC instance of the Enterprise Mission Assurance Support Service (eMASS), a government owned and operated system. (CMMC-custom term)

''CMMC Security Requirements'' means the 15 Level 1 requirements listed in the 48 CFR 52.204-21(b)(1), the 110 Level 2 requirements from NIST SP 800-171 R2 (incorporated by reference, see § 170.2), and the 24 Level 3 requirements selected from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2).

''CMMC Status'' is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally presented on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC. The potential CMMC Statuses are outlined in the paragraphs that follow. (CMMC-custom term)

(i) ''Final Level 1 (Self) ''is defined in § 170.15(a)(1) and (c)(1). (CMMC-custom term)

(ii) ''Conditional Level 2 (Self) ''is defined in § 170.16(a)(1)(ii). (CMMC- custom term)

(iii) ''Final Level 2 (Self) ''is defined in § 170.16(a)(1)(iii). (CMMC-custom term)

(iv) ''Conditional Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(ii). (CMMC- custom term)

(v) ''Final Level 2 (C3PAO) ''is defined in § 170.17(a)(1)(iii). (CMMC-custom term)

(vi) ''Conditional Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(ii). (CMMC- custom term)

(vii) ''Final Level 3 (DIBCAC) ''is defined in § 170.18(a)(1)(iii). (CMMC-custom term)

''CMMC Status Date'' means the date that the CMMC Status results are submitted to SPRS or the CMMC instantiation of eMASS, as appropriate. The date of the Conditional CMMC Status will remain as the CMMC Status Date after a successful POA&M closeout. A new date is not set for a Final that follows a Conditional. (CMMC-custom term)

''CMMC Third-Party Assessment Organization (C3PAO) ''means an organization that has been authorized or accredited by the Accreditation Body to conduct Level 2 certification assessments and has the roles and responsibilities identified in § 170.9. (CMMC-custom term)

''Contractor'' is defined in 48 CFR 3.502-1.

''Contractor Risk Managed Assets'' are defined in table 3 to § 170.19(c)(1). (CMMC-custom term)

''Controlled Unclassified Information (CUI) ''is defined in 32 CFR 2002.4(h).

''Controlled Unclassified Information (CUI) Assets'' means assets that can process, store, or transmit CUI. (CMMC- custom term)

''DCMA DIBCAC High Assessment'' means an assessment that is conducted by Government personnel in accordance with NIST SP 800-171A Jun2018 and leveraging specific guidance in the DoD Assessment Methodology that:

(i) Consists of: (A) A review of a contractor’s Basic Assessment;

(B) A thorough document review;

(C) Verification, examination, and demonstration of a contractor’s system security plan to validate that NIST SP 800-171 R2 security requirements have been implemented as described in the contractor’s system security plan; and

(D) Discussions with the contractor to obtain additional information or clarification, as needed; and

(ii) Results in a confidence level of ‘‘High’’ in the resulting score. (Source: 48 CFR 252.204-7020).

''Defense Industrial Base (DIB) ''is defined in 32 CFR 236.2.

''DoD Assessment Methodology (DoDAM) ''documents a standard methodology that enables a strategic assessment of a contractor’s implementation of NIST SP 800-171 R2, a requirement for compliance with 48 CFR 252.204-7012. (Source: DoDAM Version 1.2.1)

''Enduring Exception'' means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be enduring exceptions. (CMMC-custom term)

''Enterprise'' means an organization with a defined mission/goal and a defined boundary, using information systems to execute that mission, and with responsibility for managing its own risks and performance. An enterprise may consist of all or some of the following business aspects: acquisition, program management, financial management (''e.g.'', budgets), human resources, security, and information systems, information and mission management, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''External Service Provider (ESP) ''means external people, technology, or facilities that an organization utilizes for provision and management of IT and/or cybersecurity services on behalf of the organization. In the CMMC Program, CUI or Security Protection Data (''e.g.'', log data, configuration data), must be processed, stored, or transmitted on the ESP assets to be considered an ESP. (CMMC-custom term)

''Federal Contract Information (FCI) ''is defined in 48 CFR 4.1901.

''Government Furnished Equipment (GFE) ''has the same meaning as ‘‘government-furnished property’’ as defined in 48 CFR 45.101.

''Industrial Control Systems (ICS) ''means a general term that encompasses several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations that are often found in the industrial sectors and critical infrastructures, such as Programmable Logic Controllers (PLC). An ICS consists of combinations of control components (''e.g.'', electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (''e.g.'', manufacturing, transportation of matter or energy), as defined in NIST SP 800-82r3 (incorporated by reference, see § 170.2).

''Information System (IS) ''is defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

''Internet of Things (IoT) ''means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Operational plan of action'' as used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies (''e.g.'', necessary information system updates, patches, or reconfiguration as threats evolve) in implementation of requirements and documents how they will be mitigated, corrected, or eliminated. The OSA defines the format (''e.g.'', document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment for remediation of deficiencies that must be completed within 180 days. (CMMC- custom term)

''Operational Technology (OT) ''means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms, as defined in NIST SP 800-160 V2R1 (incorporated by reference, see § 170.2).

''Organization-defined'' means as determined by the OSA except as defined in the case of Organization- Defined Parameter (ODP). (CMMC- custom term)

''Organization-Defined Parameters (ODPs) ''means selected enhanced security requirements contain selection and assignment operations to give organizations flexibility in defining variable parts of those requirements, as defined in NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2).

''Note 1 to ODPs:'' The organization defining the parameters is the DoD.

''Organization Seeking Assessment (OSA) ''means the entity seeking to undergo a self-assessment or certification assessment for a given information system for the purposes of achieving and maintaining any CMMC Status. The term OSA includes all Organizations Seeking Certification (OSCs). (CMMC-custom term)

''Organization Seeking Certification (OSC) ''means the entity seeking to undergo a certification assessment for a given information system for the purposes of achieving and maintaining the CMMC Status of Level 2 (C3PAO) or Level 3 (DIBCAC). An OSC is also an OSA. (CMMC-custom term)

''Out-of-Scope Assets'' means assets that cannot process, store, or transmit CUI because they are physically or logically separated from information systems that do process, store, or transmit CUI, or are inherently unable to do so; except for assets that provide security protection for a CUI asset (see the definition for ''Security Protection Assets''). (CMMC- custom term)

''Periodically'' means occurring at a regular interval as determined by the OSA that may not exceed one year. (CMMC-custom term)

''Personally Identifiable Information'' means information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Plan of Action and Milestones (POA&M) ''means a document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in NIST SP 800-115 Sept2008 (incorporated by reference, see § 170.2).

''Prime Contractor'' is defined in 48 CFR 3.502-1.

''Process, store, or transmit'' means data can be used by an asset (''e.g.'', accessed, entered, edited, generated, manipulated, or printed); data is inactive or at rest on an asset (''e.g.'', located on electronic media, in system component memory, or in physical format such as paper documents); or data is being transferred from one asset to another asset (''e.g.'', data in transit using physical or digital transport methods). (CMMC-custom term)

''Restricted Information Systems'' means systems (and associated IT components comprising the system) that are configured based on government requirements (''e.g.'', connected to something that was required to support a functional requirement) and are used to support a contract (''e.g.'', fielded systems, obsolete systems, and product deliverable replicas). (CMMC-custom term)

''Risk'' means a measure of the extent to which an entity is threatened by a potential circumstance or event, and is typically a function of:

(i) The adverse impacts that would arise if the circumstance or event occurs; and

(ii) The likelihood of occurrence, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Risk Assessment'' means the process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system. Risk Assessment is part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis, as defined in NIST SP 800-39 Mar2011 (incorporated by reference, see § 170.2).

''Security Protection Assets (SPA) ''means assets providing security functions or capabilities for the OSA’s CMMC Assessment Scope. (CMMC- custom term)

''Security Protection Data (SPD) ''means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC’s assessed environment. SPD is security relevant information and includes but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment. (CMMC-custom term)

''Specialized Assets'' means types of assets considered specialized assets for CMMC: Government Furnished Equipment, Internet of Things (IoT) or Industrial Internet of Things (IIoT), Operational Technology (OT), Restricted Information Systems, and Test Equipment. (CMMC-custom term)

''Subcontractor'' is defined in 48 CFR 3.502-1.

''Supervisory Control and Data Acquisition (SCADA) ''means a generic name for a computerized system that is capable of gathering and processing data and applying operational controls over long distances. Typical uses include power transmission and distribution and pipeline systems. SCADA was designed for the unique communication challenges (''e.g.'', delays, data integrity) posed by the various media that must be used, such as phone lines, microwave, and satellite. Usually shared rather than dedicated, as defined in NIST SP 800- 82r3 (incorporated by reference, see § 170.2).

''System Security Plan (SSP) ''means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

''Temporary deficiency'' means a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency. (CMMC-custom term)

''Test Equipment'' means hardware and/ or associated IT components used in the testing of products, system components, and contract deliverables. (CMMC- custom term)

''User'' means an individual, or (system) process acting on behalf of an individual, authorized to access a system, as defined in NIST SP 800-53 R5 (incorporated by reference, see § 170.2).

=== § 170.5 Policy. ===

(a) Protection of FCI and CUI on contractor information systems is of paramount importance to the DoD and can directly impact its ability to successfully conduct essential missions and functions. It is DoD policy that defense contractors and subcontractors shall be required to safeguard FCI and CUI that is processed, stored, or transmitted on contractor information systems by applying specified security requirements. In addition, defense contractors and subcontractors may be required to implement additional safeguards defined in NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2), implementing DoD specified parameters to meet CMMC Level 3 security requirements (see table 1 to § 170.14(c)(4)). These additional requirements are necessary to protect CUI being processed, stored, or transmitted in contractor information systems, when designated by a requirement for CMMC Status of Level 3 (DIBCAC) as defined by a DoD program manager or requiring activity. In general, the Department will identify a requirement for a CMMC Status of Level 3 (DIBCAC) for solicitations and resulting contracts supporting its most critical programs and technologies.

(b) Program managers and requiring activities are responsible for identifying the CMMC Status that will apply to a procurement. Selection of the applicable CMMC Status will be based on factors including but not limited to:

(1) Criticality of the associated mission capability;

(2) Type of acquisition program or technology;

(3) Threat of loss of the FCI or CUI to be shared or generated in relation to the effort;

(4) Impacts from exploitation of information security deficiencies; and

(5) Other relevant policies and factors, including Milestone Decision Authority guidance.

(c) In accordance with the implementation plan described in § 170.3, CMMC Program requirements will apply to new DoD solicitations and contracts, and shall flow down to subcontractors who will process, store, or transmit FCI or CUI in performance of the subcontract, as described in § 170.23.

(d) In very limited circumstances, and in accordance with all applicable policies, procedures, and requirements, a Service Acquisition Executive or Component Acquisition Executive in the DoD, or as delegated, may elect to waive inclusion of CMMC Program requirements in a solicitation or contract. In such cases, contractors and subcontractors will remain obligated to comply with all applicable cybersecurity and information security requirements.

(e) The CMMC Program does not alter any separately applicable requirements to protect FCI or CUI, including those requirements in accordance with 48 CFR 52.204-21'', Basic Safeguarding of Covered Contractor Information Systems'', or covered defense information in accordance with 48 CFR 252.204- 7012'', Safeguarding Covered Defense Information and Cyber Incident Reporting'', or any other applicable information protection requirements. The CMMC Program provides a means of verifying implementation of the security requirements set forth in 48 CFR 52.204-21, NIST SP 800-171 R2, and NIST SP 800-172 Feb2021, as applicable.

== Subpart B - Government Roles and Responsibilities. ==
=== § 170.6 CMMC PMO. ===

(a) The Office of the Department of Defense Chief Information Officer (DoD CIO) Office of the Deputy CIO for Cybersecurity (DoD CIO(CS)) provides oversight of the CMMC Program and is responsible for establishing CMMC assessment, accreditation, and training requirements as well as developing and updating CMMC Program policies and implementing guidance.

(b) The CMMC PMO is responsible for monitoring the CMMC AB’s performance of roles assigned in this rule and acting as necessary to address problems pertaining to effective performance.

(c) The CMMC PMO retains, on behalf of the DoD CIO(CS), the prerogative to review decisions of the CMMC Accreditation Body as part of its oversight of the CMMC program and evaluate any alleged conflicts of interest purported to influence the CMMC Accreditation Body’s objectivity.

(d) The CMMC PMO is responsible for sponsoring necessary DCSA activities including FOCI risk assessment and Tier 3 security background investigations for the CMMC Ecosystem members as specified in §§ 170.8(b)(4) and (5), 170.9(b)(3) through (5), 170.11(b)(3) and (4), and 170.13(b)(3) and (4).

(e) The CMMC PMO is responsible for investigating and acting upon indications that an active CMMC Status has been called into question. Indications that may trigger investigative evaluations include, but are not limited to, reports from the CMMC Accreditation Body, a C3PAO, or anyone knowledgeable of the security processes and activities of the OSA. Investigative evaluations include, but are not limited to, reviewing pertinent assessment information, and exercising the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020.

(f) If a subsequent DCMA DIBCAC assessment shows that adherence to the provisions of this rule and the required CMMC Status have not been achieved or maintained, the DIBCAC results will take precedence over any pre-existing CMMC Status recorded in SPRS, or its successor capability. The DoD will update SPRS to reflect that the OSA is out of compliance and does not meet DoD CMMC requirements. If the OSA is working on an active contract requiring CMMC compliance, then standard contractual remedies will apply.

=== § 170.7 DCMA DIBCAC. ===

(a) DCMA DIBCAC assessors in support of the CMMC Program will:

(1) Complete CMMC Level 2 and Level 3 training.

(2) Conduct Level 3 certification assessments and upload assessment results into the CMMC instantiation of eMASS, or its successor capability.

(3) Issue Certificates of CMMC Status resulting from Level 3 certification assessments.

(4) Conduct Level 2 certification assessments of the Accreditation Body and prospective C3PAOs’ information systems that process, store, and/or transmit CUI.

(5) Create and maintain a process for assessors to collect the list of assessment artifacts to include artifact names, their return value of the hashing algorithm, the hashing algorithm used, and upload that data into the CMMC instantiation of eMASS.

(6) As authorized and in accordance with all legal requirements, enter and track, OSC appeals and updated results arising from Level 3 certification assessment activities into the CMMC instantiation of eMASS.

(7) Retain all records in accordance with DCMA-MAN 4501-04.

(8) Conduct an assessment of the OSA, when requested by the CMMC PMO per §§ 170.6(e) and (f), as provided for under the 48 CFR 252.204-7019 and 48 CFR 252.204-7020.

(9) Identify assessments that meet the criteria in § 170.20 and verify that SPRS accurately reflects the CMMC Status.

(b) An OSC, the CMMC AB, or a C3PAO may appeal the outcome of its DCMA DIBCAC conducted assessment within 21 days by submitting a written basis for appeal with the requirements in question for DCMA DIBCAC consideration. Appeals may be submitted for review by visiting ''www.dcma.mil/DIBCAC'' for contact information, and a DCMA DIBCAC Quality Assurance Review Team will provide a written response or request additional supporting documentation.

== Subpart C - CMMC Assessment and Certification Ecosystem. ==
=== § 170.8 Accreditation Body. ===

(a)''Roles and responsibilities''. The Accreditation Body is responsible for authorizing and ensuring the accreditation of CMMC Third-Party Assessment Organizations (C3PAOs) in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and all applicable authorization and accreditation requirements set forth. The Accreditation Body is responsible for establishing the C3PAO authorization requirements and the C3PAO Accreditation Scheme and submitting both for approval by the CMMC PMO. At any given point in time, there will be only one Accreditation Body for the DoD CMMC Program.

(b)''Requirements''. The CMMC Accreditation Body shall:

(1) Be US-based and be and remain a member in good standing of the Inter- American Accreditation Cooperation (IAAC) and become an International Laboratory Accreditation Cooperation (ILAC) Mutual Recognition Arrangement (MRA) signatory, with a signatory status scope of ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2).

(2) Be and remain a member in good standing of the International Accreditation Forum (IAF) with mutual recognition arrangement signatory status scope of ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(3) Achieve and maintain full compliance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2) and complete a peer assessment by other ILAC signatories for competence in accrediting conformity assessment bodies to ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), both within 24 months of DoD approval.

(i) Prior to achieving full compliance as set forth in this paragraph (b)(3), the Accreditation Body shall:

(A) Authorize C3PAOs who meet all requirements set forth in § 170.9 as well as administrative requirements as determined by the Accreditation Body to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the assessment results.

(B) Require all C3PAOs to achieve and maintain the ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) requirements within 27 months of authorization.

(ii) The Accreditation Body shall accredit C3PAOs, in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2), who meet all requirements set forth in § 170.9 to conduct Level 2 certification assessments and issue Certificates of CMMC Status to OSCs based on the results.

(4) Ensure that the Accreditation Body’s Board of Directors, professional staff, Information Technology (IT) staff, accreditation staff, and independent CMMC Certified Assessor staff complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions'') and ]submitted by DoD CIO Security to Washington Headquarters Services (WHS) for coordination for processing by the Defense Counterintelligence and Security Agency (DCSA). These positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing the Standard Form (SF) 328 (''www.gsa.gov/reference/forms/ certificate-pertaining-to-foreign- interests''), ]''Certificate Pertaining to Foreign Interests'', and submit it directly to Defense Counterintelligence and Security Agency (DCSA) and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c). The Accreditation Body must receive a non-disqualifying eligibility determination by the CMMC PMO to be recognized by the Department of Defense.

(ii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the Accreditation Body losing its authorization or accreditation under the CMMC Program.

(iii) Identifying all prospective C3PAOs to the CMMC PMO. The CMMC PMO will sponsor the prospective C3PAO for a FOCI risk assessment conducted by the DCSA using the SF 328 as part of the authorization and accreditation processes.

(iv) Notifying prospective C3PAOs of the CMMC PMO’s eligibility determination resulting from the FOCI risk assessment.

(6) Obtain a Level 2 certification assessment in accordance with the procedures specified in § 170.17(a)(1) and (c). This assessment, conducted by DCMA DIBCAC, shall meet all requirements for a Final Level 2 (C3PAO) but will not result in a CMMC Status of Level 2 (C3PAO). The Level 2 certification assessment process must be performed every three years.

(7) Provide all documentation and records in English.

(8) Establish, maintain, and manage an up-to-date list of authorized and accredited C3PAOs on a single publicly accessible website and provide the list of these entities and their status to the DoD through submission in the CMMC instantiation of eMASS.

(9) Provide the CMMC PMO with current data on C3PAOs, including authorization and accreditation records and status in the CMMC instantiation of eMASS. This data shall include the dates associated with the authorization and accreditation of each C3PAO.

(10) Provide the DoD with information about aggregate statistics pertaining to operations of the CMMC Ecosystem to include the authorization and accreditation status of C3PAOs or other information as requested.

(11) Provide inputs for assessor supplemental guidance to the CMMC PMO. Participate and support coordination of these and other inputs through DoD-led Working Groups.

(12) Ensure that all information about individuals is encrypted and protected in all Accreditation Body information systems and databases.

(13) Provide all plans that are related to potential sources of revenue, to include but not limited to: fees, licensing, processes, membership, and/ or partnerships to the Department’s CMMC PMO.

(14) Ensure that the CMMC Assessors and Instructors Certification Organization (CAICO) is compliant with ISO/IEC 17024:2012(E)

(15) Ensure all training products, instruction, and testing materials are of high quality and subject to CAICO quality control policies and procedures, to include technical accuracy and alignment with all applicable legal, regulatory, and policy requirements.

(16) Develop and maintain an internal appeals process, as required by ISO/IEC 17020:2017(E), and render a final decision on all elevated appeals.

(17) Develop and maintain a comprehensive plan and schedule to comply with all ISO/IEC 17011:2017(E), and DoD requirements for Conflict of Interest, Code of Professional Conduct, and Ethics policies as set forth in the DoD contract. All policies shall apply to the Accreditation Body, and other individuals, entities, and groups within the CMMC Ecosystem who provide Level 2 certification assessments, CMMC instruction, CMMC training materials, or Certificates of CMMC Status on behalf of the Accreditation Body. All policies in this section must be approved by the CMMC PMO prior to effectivity in accordance with the following requirements.

(i) ''Conflict of Interest (CoI) policy.''

The CoI policy shall:

(A) Include a detailed risk mitigation plan for all potential conflicts of interest that may pose a risk to compliance with ISO/IEC 17011:2017(E).

(B) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees to disclose to the CMMC PMO, in writing, as soon as it is known or reasonably should be known, any actual, potential, or perceived conflict of interest with sufficient detail to allow for assessment.

(C) Require employees, Board directors, and members of any accreditation committees or appeals adjudication committees who leave the board or organization to enter a ‘‘cooling off period’’ of one (1) year whereby they are prohibited from working with the Accreditation Body or participating in any and all CMMC activities described in Subpart C.

(D) Require CMMC Ecosystem members to actively avoid participating in any activity, practice, or transaction that could result in an actual or perceived conflict of interest.

(E) Require CMMC Ecosystem members to disclose to Accreditation Body leadership, in writing, any actual or potential conflict of interest as soon as it is known, or reasonably should be known.

(ii) ''Code of Professional Conduct (CoPC) policy.''

The CoPC policy shall:

(A) Describe the performance standards by which the members of the CMMC Ecosystem will be held accountable and the procedures for addressing violations of those performance standards.

(B) Require the Accreditation Body to investigate and resolve any potential violations that are reported or are identified by the DoD.

(C) Require the Accreditation Body to inform the DoD in writing of new investigations within 72 hours.

(D) Require the Accreditation Body to report to the DoD in writing the outcome of completed investigations within 15 business days.

(E) Require CMMC Ecosystem members to represent themselves and their companies accurately; to include not misrepresenting any professional credentials or status, including CMMC authorization or CMMC Status, nor exaggerating the services that they or their company are capable or authorized to deliver.

(F) Require CMMC Ecosystem members to be honest and factual in all CMMC-related activities with colleagues, clients, trainees, and others with whom they interact.

(G) Prohibit CMMC Ecosystem members from participating in the Level 2 certification assessment process for an assessment in which they previously served as a consultant to prepare the organization for any CMMC assessment within 3 years.

(H) Require CMMC Ecosystem members to maintain the confidentiality of customer and government data to preclude unauthorized disclosure.

(I) Require CMMC Ecosystem members to report results and data from Level 2 certification assessments and training objectively, completely, clearly, and accurately.

(J) Prohibit CMMC Ecosystem members from cheating, assisting another in cheating, or allowing cheating on CMMC examinations.

(K) Require CMMC Ecosystem members to utilize official training content developed by a CMMC training organization approved by the CAICO in all CMMC certification courses.

(iii) ''Ethics policy.''

The Ethics policy shall:

(A) Require CMMC Ecosystem members to report to the Accreditation Body within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

(B) Prohibit harassment or discrimination by CMMC Ecosystem members in all interactions with individuals whom they encounter in connection with their roles in the CMMC Ecosystem.

(C) Require CMMC Ecosystem members to have and maintain a satisfactory record of integrity and business ethics.

=== § 170.9 CMMC Third-Party Assessment Organizations (C3PAOs). ===

(a)''Roles and responsibilities''. C3PAOs are organizations that are responsible for conducting Level 2 certification assessments and issuing Certificates of CMMC Status to OSCs based on the results. C3PAOs must be accredited or authorized by the Accreditation Body in accordance with the requirements set forth.

(b)''Requirements''. C3PAOs shall:

(1) Obtain authorization or accreditation from the Accreditation Body in accordance with § 170.8(b)(3)(i) and (ii).

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain compliance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) within 27 months of authorization.

(3) Require all C3PAO company personnel participating in the Level 2 certification assessment process to complete a Tier 3 background investigation resulting in a determination of national security eligibility. This includes the CMMC Assessment Team and the quality assurance individual. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/ reference/forms/questionnaire-for-national-security-positions''). These ]positions are designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Require all C3PAO company personnel participating in the Level 2 certification assessment process who are not eligible to obtain a Tier 3 background investigation to meet the equivalent of a favorably adjudicated Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Comply with Foreign Ownership, Control or Influence (FOCI) by:

(i) Completing and submitting Standard Form (SF) 328 (''www.gsa.gov/ reference/forms/certificate-pertaining-to-foreign-interests''), Certificate Pertaining to Foreign Interests'', upon request from DCSA and undergo a National Security Review with regards to the protection of controlled unclassified information based on the factors identified in 32 CFR 117.11(b) using the procedures outlined in 32 CFR 117.11(c).

(ii) Receiving a non-disqualifying eligibility determination from the CMMC PMO resulting from the FOCI risk assessment in order to proceed to a DCMA DIBCAC CMMC Level 2 assessment, as part of the authorization and accreditation process set forth in paragraph (b)(6) of this section.

(iii) Reporting any change to the information provided on its SF 328 by resubmitting the SF 328 to DCSA within 15 business days of the change being effective. A disqualifying eligibility determination, based on the results of the change, will result in the C3PAO losing its authorization or accreditation.

(6) Undergo a Level 2 certification assessment meeting all requirements for a Final Level 2 (C3PAO) in accordance with the procedures specified in § 170.17(a)(1) and (c), with the following exceptions:

(i) The assessment will be conducted by DCMA DIBCAC.

(ii) The assessment will not result in a CMMC Status of Level 2 (C3PAO) nor receive a Certificate of CMMC Status.

(7) Provide all documentation and records in English.

(8) Submit pre-assessment and planning material, final assessment reports, and CMMC certificates of assessment into the CMMC instantiation of eMASS.

(9) Unless disposition is otherwise authorized by the CMMC PMO, maintain all assessment related records for a period of six (6) years. Such records include any materials generated by the C3PAO in the course of an assessment, any working papers generated from Level 2 certification assessments; and materials relating to monitoring, education, training, technical knowledge, skills, experience, and authorization of all personnel involved in assessment activities; contractual agreements with OSCs; and organizations for whom consulting services were provided.

(10) Provide any requested audit information, including any out-of-cycle from ISO/IEC 17020:2012(E) requirements, to the Accreditation Body.

(11) Ensure that all personally identifiable information (PII) is encrypted and protected in all C3PAO information systems and databases.

(12) Meet the requirements for Assessment Team composition. An Assessment Team must include at least two people: a Lead CCA, as defined in § 170.11(b)(10), and at least one other CCA. Additional CCAs and CCPs may also participate on an Assessment Team.

(13) Implement a quality assurance function that ensures the accuracy and completeness of assessment data prior to upload into the CMMC instantiation of eMASS. Any individual fulfilling the quality assurance function must be a CCA and cannot be a member of an Assessment Team for which they are performing a quality assurance role. A quality assurance individual shall manage the C3PAO’s quality assurance reviews as defined in paragraph (b)(14) of this section and the appeals process as required by paragraphs (b)(19) and (20) of this section and in accordance with ISO/IEC 17020:2012(E) (incorporated by reference, see § 170.2) and ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(14) Conduct quality assurance reviews for each assessment, including observations of the Assessment Team’s conduct and management of CMMC assessment processes.

(15) Ensure that all Level 2 certification assessment activities are performed on the information system within the CMMC Assessment Scope.

(16) Maintain all facilities, personnel, and equipment involved in CMMC activities that are in scope of their Level 2 certification assessment and comply with all security requirements and procedures as prescribed by the Accreditation Body.

(17) Ensure that all assessment data and information uploaded into the CMMC instantiation of eMASS assessment data is compliant with the CMMC assessment data standard as set forth in eMASS CMMC Assessment Import Templates on the CMMC eMASS website: ''https://cmmc.emass.apps.mil''. This system is accessible only to authorized users.

(18) Issue Certificates of CMMC Status to OSCs in accordance with the Level 2 certification assessment requirements set forth in § 170.17, that include, at a minimum, all industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope, the C3PAO name, assessment unique identifier, the OSC name, and the CMMC Status date and level.

(19) Address all OSC appeals arising from Level 2 certification assessment activities. If the OSC or C3PAO is not satisfied with the result of the appeal either the OSC or the C3PAO can elevate the matter to the Accreditation Body for final determination.

(20) Submit assessment appeals, review records, and decision results of assessment appeals to DoD using the CMMC instantiation of eMASS.

=== § 170.10 CMMC Assessor and Instructor Certification Organization (CAICO). ===

(a)''Roles and responsibilities''. The CAICO is responsible for training, testing, authorizing, certifying, and recertifying CMMC assessors, instructors, and related professionals. Only the CAICO may make decisions relating to examination certifications, including the granting, maintaining, recertifying, expanding, and reducing the scope of certification, and suspending or withdrawing certification in accordance with current ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2). At any given point in time, there will be only one CAICO for the DoD CMMC Program.

(b)''Requirements''. The CAICO shall: (1) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17); and achieve and maintain ISO/IEC 17024(E) accreditation within 12 months of December 16, 2024.

(2) Provide all documentation and records in English.

(3) Train, test, and designate PIs in accordance with the requirements of this section. Train, test, certify, and recertify CCPs, CCAs, and CCIs in accordance with the requirements of this section.

(4) Ensure the instructor and assessor certification examinations are certified under ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2), by a recognized US-based accreditor who is not a member of the CMMC Accreditation Body. The US-based accreditor must be a signatory to International Laboratory Accreditation Cooperation (ILAC) or relevant International Accreditation Forum (IAF) Mutual Recognition Arrangement (MRA) and must operate in accordance with ISO/IEC 17011:2017(E) (incorporated by reference, see § 170.2).

(5) Establish quality control policies and procedures for the generation of training products, instruction, and testing materials.

(6) Oversee development, administration, and management pertaining to the quality of training and examination materials for CMMC assessor and instructor certification and recertification.

(7) Establish and publish an authorization and certification appeals process to receive, evaluate, and make decisions on complaints and appeals in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(8) Address all appeals arising from the CCA, CCI, and CCP authorizations and certifications process through use of internal processes in accordance with ISO/IEC 17024:2012(E) (incorporated by reference, see § 170.2).

(9) Maintain records for a period of six (6) years of all procedures, processes, and actions related to fulfillment of the requirements set forth in this section and provide the Accreditation Body access to those records.

(10) Provide the Accreditation Body information about the authorization and accreditation status of assessors, instructors, training community, and publishing partners.

(11) Ensure separation of duties between individuals involved in testing activities, training activities, and certification activities.

(12) Safeguard and require any CAICO training support service providers, as applicable, to safeguard the confidentiality of applicant, candidate, and certificate-holder information and ensure the overall security of the certification process.

(13) Ensure that all PII is encrypted and protected in all CAICO information systems and databases and those of any CAICO training support service providers.

(14) Ensure the security of assessor and instructor examinations and the fair and credible administration of examinations.

(15) Neither disclose nor allow any CAICO training support service providers, as applicable, to disclose CMMC data or metrics related to authorization or certification activities to any entity other than the Accreditation Body and DoD, except as required by law.

(16) Require retraining and redesignation of PIs upon significant change to DoD’s CMMC Program requirements. Require retraining and recertification of CCPs, CCAs, and CCIs upon significant change to DoD’s CMMC Program requirements, as determined by the DoD or the CAICO.

(17) Require CMMC Ecosystem members to report to the CAICO within 30 days of convictions, guilty pleas, or no contest pleas to crimes of fraud, larceny, embezzlement, misappropriation of funds, misrepresentation, perjury, false swearing, conspiracy to conceal, or a similar offense in any legal proceeding, civil or criminal, whether or not in connection with activities that relate to carrying out their role in the CMMC Ecosystem.

=== § 170.11 CMMC Certified Assessor (CCA). ===

(a)''Roles and responsibilities''. CCAs, in support of a C3PAO, conduct Level 2 certification assessments of OSCs in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2), the assessment processes defined in § 170.17, and the scoping requirements defined in § 170.19(c). CCAs must meet all of the requirements set forth in paragraph (b) of this section. A CCA may conduct Level 2 certification assessments and participate on a C3PAO Assessment Team.

(b)''Requirements''. CCAs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/ questionnaire-for-national-security- positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible for a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Be a CCP who has at least 3 years of cybersecurity experience, at least 1 year of assessment or audit experience, and at least one foundational qualification, aligned to at least the Intermediate Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program'' (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at ''https://public.cyber.mil/dcwf-work-role/security-control-assessor/''.

(7) Only use IT, cloud, cybersecurity services, and end-point devices provided by the authorized/accredited C3PAO that has been engaged to perform that OSA’s Level 2 certification assessment and which has undergone a Level 2 certification assessment by DCMA DIBCAC (or higher) for all assessment activities. Individual assessors are prohibited from using any other IT, including IT that is personally owned, to include internal and external cloud services and end-point devices, to process, store, or transmit CMMC assessment reports or any other CMMC assessment-related information. The evaluation of assessment evidence within the OSC environment, using OSC tools, is permitted.

(8) Immediately notify the responsible C3PAO of any breach or potential breach of security to any CMMC-related assessment materials under the assessors’ purview.

(9) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

(10) Qualify as a Lead CCA by having at least 5 years of cybersecurity experience, 5 years of management experience, 3 years of assessment or audit experience, and at least one foundational qualification aligned to Advanced Proficiency Level of the DoD Cyberspace Workforce Framework’s Security Control Assessor (612) Work Role, from DoD Manual 8140.03, ''Cyberspace Workforce Qualification and Management Program (https://dodcio.defense.gov/Portals/0/ Documents/Library/DoDM-8140-03.pdf)''. Information on the Work Role 612 can be found at '' https://public.cyber.mil/dcwf-work-role/security-control-assessor/.''

=== § 170.12 CMMC Instructor. ===

(a) ''CMMC Provisional Instructor (PI) roles and responsibilities''. A CMMC Provisional Instructor (PI) teaches CCA and CCP candidates during the transitional period that ends 18 months after December 16, 2024. A PI is trained, tested, and designated to perform CMMC instructional duties by the CAICO to teach CCP and CCA candidates. PIs are designated by the CAICO after successful completion of the PI training and testing requirements set forth by the CAICO. A PI with a valid CCP certification may instruct CCP candidates, while a PI with a valid CCA certification may instruct CCP and CCA candidates. PIs are required to meet requirements in (c) of this section.

(b) ''CMMC Certified Instructor (CCI) roles and responsibilities''. A CMMC Certified Instructor (CCI) teaches CCP, CCA, and CCI candidates and performs CMMC instructional duties. Candidate CCIs are certified by the CAICO after successful completion of the CCI training and testing requirements. A CCI is required to obtain and maintain assessor and instructor certifications from the CAICO in accordance with the requirements set forth in § 170.10 and in paragraph (c) of this section. A CCI with a valid CCP certification may instruct CCP candidates, while a CCI with a valid CCA certification may instruct CCP, CCA, and CCI candidates. Certifications are valid for 3 years from the date of issuance. CCIs are required to meet requirements in paragraph (c) of this section.

(c)''Requirements''. CMMC Instructors shall:

(1) Obtain and maintain instructor designation or certification, as appropriate, from the CAICO in accordance with the requirements set forth in § 170.10.

(2) Obtain and maintain CCP or CCA certification to deliver CCP training.

(3) Obtain and maintain a CCA certification to deliver CCA training.

(4) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics set forth in § 170.8(b)(17).

(5) Provide all documentation and records in English.

(6) Provide the Accreditation Body and the CAICO annually with accurate information detailing their qualifications, training experience, professional affiliations, and certifications, and, upon reasonable request, submit documentation verifying this information.

(7) Not provide CMMC consulting services while serving as a CMMC instructor; however, subject to the Code of Professional Conduct and Conflict of Interest policies, can serve on an assessment team.

(8) Not participate in the development of exam objectives and/or exam content or act as an exam proctor while at the same time serving as a CCI.

(9) Keep confidential all information obtained or created during the performance of CMMC training activities, including trainee records, except as required by law.

(10) Not disclose any CMMC-related data or metrics that is PII, FCI, or CUI to anyone without prior coordination with and approval from DoD.

(11) Notify the Accreditation Body or the CAICO if required by law or authorized by contractual commitments to release confidential information.

(12) Not share with anyone any CMMC training-related information not previously publicly disclosed.

=== § 170.13 CMMC Certified Professional (CCP). ===

(a)''Roles and responsibilities''. A CMMC Certified Professional (CCP) completes rigorous training on CMMC and the assessment process to provide advice, consulting, and recommendations to their OSA clients. Candidate CCPs are certified by the CAICO after successful completion of the CCP training and testing requirements set forth in paragraph (b) of this section. CCPs are eligible to become CMMC Certified Assessors and can participate as a CCP on Level 2 certification assessments with CCA oversight where the CCA makes all final determinations.

(b)''Requirements''. CCPs shall: (1) Obtain and maintain certification from the CAICO in accordance with the requirements set forth in § 170.10. Certification is valid for 3 years from the date of issuance.

(2) Comply with the Accreditation Body policies for Conflict of Interest, Code of Professional Conduct, and Ethics as set forth in § 170.8(b)(17).

(3) Complete a Tier 3 background investigation resulting in a determination of national security eligibility. This Tier 3 background investigation will not result in a security clearance and is not being executed for the purpose of government employment. The Tier 3 background investigation is initiated using the Standard Form (SF) 86 (''www.gsa.gov/reference/forms/questionnaire-for-national-security-positions''). These positions are ]designated as non-critical sensitive with a risk designation of ‘‘Moderate Risk’’ in accordance with 5 CFR 1400.201(b) and (d) and the investigative requirements of 5 CFR 731.106(c)(2).

(4) Meet the equivalent of a favorably adjudicated Tier 3 background investigation when not eligible to obtain a Tier 3 background investigation. DoD will determine the Tier 3 background investigation equivalence for use with the CMMC Program only.

(5) Provide all documentation and records in English.

(6) Not share any information about an OSC obtained during CMMC pre- assessment and assessment activities with any person not involved with that specific assessment, except as otherwise required by law.

== Subpart D - Key Elements of the CMMC Program ==
=== § 170.14 CMMC Model. ===

(a)''Overview''. The CMMC Model incorporates the security requirements from:

(1) 48 CFR 52.204-21, ''Basic Safeguarding of Covered Contractor Information Systems;''

(2) NIST SP 800-171 R2'', Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations'' (incorporated by reference, see § 170.2); and

(3) Selected security requirements from NIST SP 800-172 Feb2021, ''Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171'' (incorporated by reference, see § 170.2).

(b) ''CMMC domains''. The CMMC Model consists of domains that map to the Security Requirement Families defined in NIST SP 800-171 R2 (incorporated by reference, see § 170.2).

(c) ''CMMC level requirements''. CMMC Levels 1-3 utilize the safeguarding requirements and security requirements specified in 48 CFR 52.204-21 (for Level 1), NIST SP 800-171 R2 (incorporated by reference, see § 170.2) (for Level 2), and selected security requirements from NIST SP 800-172 Feb2021 (incorporated by reference, see § 170.2) (for Level 3). This paragraph discusses the numbering scheme and the security requirements for each level.

(1)''Numbering''. Each security requirement has an identification number in the format - DD.L#-REQ - where:

(i) DD is the two-letter domain abbreviation;

(ii) L# is the CMMC level number; and

(iii) REQ is the 48 CFR 52.204-21 paragraph number, NIST SP 800-171 R2 requirement number, or NIST SP 800- 172 Feb2021 requirement number.

(2) ''CMMC Level 1 security requirements''. The security requirements in CMMC Level 1 are those set forth in 48 CFR 52.204-21(b)(1)(i) through (xv).

(3) ''CMMC Level 2 security requirements''. The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.

(4) ''CMMC Level 3 security requirements''. The security requirements in CMMC Level 3 are selected from NIST SP 800-172 Feb2021, and where applicable, Organization-Defined Parameters (ODPs) are assigned. Table 1 to this paragraph identifies the selected requirements and applicable ODPs that represent the CMMC Level 3 security requirements. ODPs for the NIST SP 800-172 Feb2021 requirements are italicized, where applicable:

==== Table 1 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 1 TO § 170.14(c)(4)
|-
! style="width: 25%;text-align:center" | Security requirement No.*
! style="width: 75%;text-align:center" | CMMC Level 3 security requirements (selected NIST SP 800-172 Feb2021 security requirement with DoD ODPs italicized)
|-
|(i) AC.L3-3.1.2e
|Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization.
|-
|(ii) AC.L3-3.1.3e
|Employ ''secure information transfer solutions'' to control information flows between security domains on con-nected systems.
|-
|(iii) AT.L3-3.2.1e
|Provide awareness training ''upon initial hire, following a significant cyber event, and at least annually'', focused on recognizing and responding to threats from social engineering, advanced persistent threat actors, breaches, and suspicious behaviors; update the training ''at least annually'' or when there are significant changes to the threat.
|-
|(iv) AT.L3-3.2.2e
|Include practical exercises in awareness training for ''all users, tailored by roles, to include general users, users with specialized roles, and privileged users'', that are aligned with current threat scenarios and provide feed-back to individuals involved in the training and their supervisors.
|-
|(v) CM.L3-3.4.1e
|Establish and maintain an authoritative source and repository to provide a trusted source and accountability for approved and implemented system components.
|-
|(vi) CM.L3-3.4.2e
|Employ automated mechanisms to detect misconfigured or unauthorized system components; after detection, ''remove the components or place the components in a quarantine or remediation network'' to facilitate patching, re-configuration, or other mitigations.
|-
|(vii) CM.L3-3.4.3e
|Employ automated discovery and management tools to maintain an up-to-date, complete, accurate, and readily available inventory of system components.
|-
|(viii) IA.L3-3.5.1e
|Identify and authenticate ''systems and system components, where possible'', before establishing a network con-nection using bidirectional authentication that is cryptographically based and replay resistant.
|-
|(ix) IA.L3-3.5.3e
|Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.
|-
|(x) IR.L3-3.6.1e
|Establish and maintain a security operations center capability that operates ''24/7, with allowance for remote/on-call staff''.
|-
|(xi) IR.L3-3.6.2e
|Establish and maintain a cyber-incident response team that can be deployed by the organization within ''24 hours''.
|-
|(xii) PS.L3-3.9.2e
|Ensure that organizational systems are protected if adverse information develops or is obtained about individuals with access to CUI.
|-
|(xiii) RA.L3-3.11.1e
|Employ ''threat intelligence, at a minimum from open or commercial sources, and any DoD-provided sources'', as part of a risk assessment to guide and inform the development of organizational systems, security architec-tures, selection of security solutions, monitoring, threat hunting, and response and recovery activities.
|-
|(xiv) RA.L3-3.11.2e
|Conduct cyber threat hunting activities ''on an on-going aperiodic basis or when indications warrant'', to search for indicators of compromise in'' organizational systems'' and detect, track, and disrupt threats that evade exist-ing controls.
|-
|(xv) RA.L3-3.11.3e
|Employ advanced automation and analytics capabilities in support of analysts to predict and identify risks to organizations, systems, and system components.
|-
|(xvi) RA.L3-3.11.4e
|Document or reference in the system security plan the security solution selected, the rationale for the security solution, and the risk determination.
|-
|(xvii) RA.L3-3.11.5e
|Assess the effectiveness of security solutions ''at least annually or upon receipt of relevant cyber threat information, or in response to a relevant cyber incident'', to address anticipated risk to organizational systems and the organization based on current and accumulated threat intelligence.
|-
|(xviii) RA.L3-3.11.6e
|Assess, respond to, and monitor supply chain risks associated with organizational systems and system components.
|-
|(xix) RA.L3-3.11.7e
|Develop a plan for managing supply chain risks associated with organizational systems and system components; update the plan ''at least annually, and upon receipt of relevant cyber threat information, or in response to a relevant cyber incident''.
|-
|(xx) CA.L3-3.12.1e
|Conduct penetration testing ''at least annually or when significant security changes are made to the system'', leveraging automated scanning tools and ad hoc tests using subject matter experts.
|-
|(xxi) SC.L3-3.13.4e
|Employ ''physical isolation techniques or logical isolation techniques or both'' in organizational systems and system components.
|-
|(xxii) SI.L3-3.14.1e
|Verify the integrity of ''security critical and essential software'' using root of trust mechanisms or cryptographic signatures.
|-
|(xxiii) SI.L3-3.14.3e
|Ensure that ''specialized assets including IoT, IIoT, OT, GFE, Restricted Information Systems, and test equipment'' are included in the scope of the specified enhanced security requirements or are segregated in pur-pose-specific networks.
|-
|(xxiv) SI.L3-3.14.6e
|Use threat indicator information and effective mitigations obtained from'', at a minimum, open or commercial sources, and any DoD-provided sources'', to guide and inform intrusion detection and threat hunting.
|-
|colspan="2"|* Roman numerals in parentheses before the Security Requirement are for numbering purposes only. The numerals are not part of the naming convention for the requirement.
|}

(d) ''Implementation''. Assessment of security requirements is prescribed by NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2). Descriptive text in these documents support OSA implementation of the security requirements and use the terms organization-defined and periodically. Except where referring to Organization- Defined Parameters (ODPs), organization-defined means as determined by the OSA. Periodically means occurring at regular intervals. As used in many requirements within CMMC, the interval length is organization-defined to provided contractor flexibility, with an interval length of no more than one year.

=== § 170.15 CMMC Level 1 self-assessment and affirmation requirements. ===

(a) ''Level 1 self-assessment''. To comply with CMMC Level 1 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 1 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of Final Level 1 (Self).

(1) ''Level 1 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(2) to achieve the CMMC Status of Final Level 1 (Self). No POA&Ms are permitted for CMMC Level 1. The OSA must conduct a self-assessment in accordance with the procedures set forth in § 170.15(c)(1) and submit assessment results in SPRS. To maintain compliance with the requirements for the CMMC Status of Final Level 1 (Self), the OSA must conduct a Level 1 self- assessment on an annual basis and submit the results in SPRS, or its successor capability.

(i) ''Inputs to SPRS''. The Level 1 self-assessment results in the Supplier Performance Risk System (SPRS) shall include, at minimum, the following items:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Compliance result.

(ii) [Reserved]

(2) ''Affirmation''. Affirmation of the Level 1 (Self) CMMC Status is required for all Level 1 self-assessments. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 1 (Self), OSAs must both achieve a CMMC Status of Level 1 (Self) and have submitted an affirmation of compliance into SPRS for all information systems within the CMMC Assessment Scope.

(c) ''Procedures - (1) Level 1 self-assessment''. The OSA must conduct a Level 1 self-assessment scored in accordance with the CMMC Scoring Methodology described in § 170.24. The Level 1 self-assessment must be performed in accordance with the CMMC Level 1 scope requirements set forth in § 170.19(a) and (b) and the following:

(i) The Level 1 self-assessment must be performed using the objectives defined in NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) for the security requirement that maps to the CMMC Level 1 security requirement as specified in table 1 to paragraph (c)(1)(ii) of this section. In any case where an objective addresses CUI, FCI should be substituted for CUI in the objective.

(ii) Mapping table for CMMC Level 1 security requirements to the NIST SP 800-171A Jun2018 objectives.

==== Table 2 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 2 TO § 170.15(c)(1)(ii) - CMMC LEVEL 1 SECURITY REQUIREMENTS MAPPED TO NIST SP 800-171A JUN2018
|-
! style="width: 65%;text-align:left" | CMMC Level 1 security requirements as set forth in § 170.14(c)(2)
! style="width: 35%;text-align:right" | NIST SP 800-171A Jun2018
|-
|AC.L1-b.1.i
| style="text-align:right" | 3.1.1
|-
|AC.L1-b.1.ii
| style="text-align:right" | 3.1.2
|-
|AC.L1-b.1.iii
| style="text-align:right" | 3.1.20
|-
|AC.L1-b.1.iv
| style="text-align:right" | 3.1.22
|-
|IA.L1-b.1.v
| style="text-align:right" | 3.5.1
|-
|IA.L1-b.1.vi
| style="text-align:right" | 3.5.2
|-
|MP.L1-b.1.vii
| style="text-align:right" | 3.8.3
|-
|PE.L1-b.1.viii
| style="text-align:right" | 3.10.1
|-
|First phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.3
|-
|Second phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.4
|-
|Third phrase of PE.L1-b.1.ix (FAR b.1.ix *)
| style="text-align:right" | 3.10.5
|-
|SC.L1-b.1.x
| style="text-align:right" | 3.13.1
|-
|SC.L1-b.1.xi
| style="text-align:right" | 3.13.5
|-
|SI.L1-b.1.xii
| style="text-align:right" | 3.14.1
|-
|SI.L1-b.1.xiii
| style="text-align:right" | 3.14.2
|-
|SI.L1-b.1.xiv
| style="text-align:right" | 3.14.4
|-
|SI.L1-b.1.xv
| style="text-align:right" | 3.14.5
|-
|colspan="2"|* Three of the 48 CFR 52.204-21 requirements were broken apart by ‘‘phrase’’ when NIST SP 800-171 R2 was developed.
|}

(iii) Additional guidance can be found in the guidance document listed in paragraph (b) of appendix A to this part.

(2) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.16 CMMC Level 2 self-assessment and affirmation requirements. ===

(a) ''Level 2 self-assessment''. To comply with Level 2 self-assessment requirements, the OSA must meet the requirements detailed in paragraphs (a)(1) and (2) of this section. An OSA conducts a Level 2 self-assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (Self). Achieving a CMMC Status of Level 2 (Self) also satisfies the requirements for a CMMC Status of Level 1 (Self) detailed in § 170.15 for the same CMMC Assessment Scope.

(1) ''Level 2 self-assessment requirements''. The OSA must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (Self). The OSA must conduct a self- assessment in accordance with the procedures set forth in paragraph (c)(1) of this section and submit assessment results in Supplier Performance Risk System (SPRS). To maintain compliance with the requirements for a CMMC Status of Level 2 (Self), the OSA must conduct a Level 2 self-assessment every three years and submit the results in SPRS, within three years of the CMMC Status Date associated with the Conditional Level 2 (Self).

(i) ''Inputs to SPRS''. The Level 2 self-assessment results in the SPRS shall include, at minimum, the following information:

(A) CMMC Level. 
(B) CMMC Status Date. 
(C) CMMC Assessment Scope. 
(D) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(E) Overall Level 2 self-assessment score (''e.g''., 105 out of 110). 
(F) POA&M usage and compliance status, if applicable.

(ii) ''Conditional Level 2 (Self)''. The OSA has achieved the CMMC Status of Conditional Level 2 (Self) if the Level 2 self-assessment results in a POA&M and the POA&M meets all the CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSA must remediate any NOT MET requirements, must perform a POA&M closeout self- assessment, and must post compliance results to SPRS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (Self). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (Self) CMMC Status for the information system will expire. If Conditional Level 2 (Self) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSA will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (Self)''. The OSA has achieved the CMMC Status of Final Level 2 (Self) if the Level 2 self- assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial self-assessment or as the result of a POA&M closeout self- assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSA, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSA will be ineligible for additional awards with CMMC Status requirement of Level 2 (Self), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (Self) CMMC Status is required for all Level 2 self-assessments at the time of each assessment, and annually thereafter. Affirmation procedures are set forth in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 2 (Self), the following two requirements must be met:

(1) The OSA must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (Self) or Final Level 2 (Self).

(2) The OSA must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 self-assessment of the OSA''. The OSA must conduct a Level 2 self-assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in §§ 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 self-assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the OSA must upload the results into SPRS. If a POA&M exists, a POA&M closeout self-assessment must be performed by the OSA when all NOT MET requirements have been remediated. The POA&M closeout self- assessment must be performed within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in the guidance document listed in paragraph (c) of appendix A to this part.

(2) ''Level 2 self-assessment with the use of Cloud Service Provider (CSP)''. An OSA may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the Customer Responsibility Matrix (CRM) must be documented or referred to in the OSA’s System Security Plan (SSP).

(3) ''Level 2 self-assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (Self) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and CRM.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

(4) ''Artifact retention''. The artifacts used as evidence for the assessment must be retained by the OSA for six (6) years from the CMMC Status Date.

=== § 170.17 CMMC Level 2 certification assessment and affirmation requirements. ===

(a) ''Level 2 certification assessment''. To comply with Level 2 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 2 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 2 (C3PAO). Achieving a CMMC Status of Level 2 (C3PAO) also satisfies the requirements for a CMMC Statuses of Level 1 (Self) and Level 2 (Self) set forth in §§ 170.15 and 170.16 respectively for the same CMMC Assessment Scope.

(1) ''Level 2 certification assessment requirements''. The OSC must complete and achieve a MET result for all security requirements specified in § 170.14(c)(3) to achieve the CMMC Status of Level 2 (C3PAO). The OSC must obtain a Level 2 certification assessment from an authorized or accredited C3PAO following the procedures outlined in paragraph (c) of this section. The C3PAO must submit the Level 2 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 2 (C3PAO), the Level 2 certification assessment must be completed within three years of the CMMC Status Date associated with the Conditional Level 2 (C3PAO).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 2 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following information:

(A) Date and level of the assessment. 
(B) C3PAO name. 
(C) Assessment unique identifier. 
(D) For each Assessor conducting the assessment, name and business contact information. 
(E) All industry CAGE codes associated with the information systems addressed by the CMMC Assessment Scope. 
(F) The name, date, and version of the SSP. 
(G) CMMC Status Date. 
(H) Assessment result for each requirement objective. 
(I) POA&M usage and compliance, as applicable. 
(J) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Conditional Level 2 (C3PAO) if the Level 2 certification assessment results in a POA&M and the POA&M meets all CMMC Level 2 POA&M requirements listed in § 170.21(a)(2).

(A) ''Plan of Action and Milestones''. A Level 2 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from a C3PAO, and the C3PAO must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 2 (C3PAO). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 2 (C3PAO) CMMC Status for the information system will expire. If Conditional Level 2 (C3PAO) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 2 (C3PAO)''. The OSC has achieved the CMMC Status of Final Level 2 (C3PAO) if the Level 2 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 2 (C3PAO), or higher requirement, for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 2 (C3PAO) CMMC Status is required for all Level 2 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 2 certification assessment of the OSC''. An authorized or accredited C3PAO must perform a Level 2 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and the CMMC Level 2 scoping requirements set forth in § 170.19(a) and (c) for the information systems within the CMMC Assessment Scope. The Level 2 certification assessment must be scored in accordance with the CMMC Scoring Methodology described in § 170.24 and the C3PAO must upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 2 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) Cannot change or limit the effectiveness of other requirements that have been scored MET; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment must be performed by a C3PAO within 180-days of the Conditional CMMC Status Date. Additional guidance can be found in § 170.21 and in the guidance document listed in paragraph (c) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. The OSC must provide the C3PAO with a list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm for upload into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 2 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The CSP product or service offering is FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline in accordance with the FedRAMP Marketplace; or

(ii) The CSP product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline but meets security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline. FedRAMP Moderate or FedRAMP Moderate equivalent is in accordance with DoD Policy.

(iii) In accordance with § 170.19(c)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 2 certification assessment with the use of an External Service Provider (ESP), not a CSP''. An OSA may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 2 (C3PAO) under the following circumstances:

(i) The use of the ESP, its relationship to the OSA, and the services provided are documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSA requirements are assessed within the scope of the OSA’s assessment against all Level 2 security requirements.

(iii) In accordance with § 170.19(c)(2), the OSA’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSA’s SSP.

=== § 170.18 CMMC Level 3 certification assessment and affirmation requirements. ===

(a) ''Level 3 certification assessment''. To comply with Level 3 certification assessment requirements, the OSC must meet the requirements set forth in paragraphs (a)(1) and (2) of this section. An OSC undergoes a Level 3 certification assessment as detailed in paragraph (c) of this section to achieve a CMMC Status of either Conditional or Final Level 3 (DIBCAC). A CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope is a prerequisite to undergo a Level 3 certification assessment. CMMC Level 3 recertification also has a prerequisite for a new CMMC Level 2 assessment. Achieving a CMMC Status of Level 3 (DIBCAC) also satisfies the requirements for CMMC Statuses of Level 1 (Self), Level 2 (Self), and Level 2 (C3PAO) set forth in §§ 170.15 through 170.17 respectively for the same CMMC Assessment Scope.

(1) ''Level 3 certification assessment requirements''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) on the Level 3 CMMC Assessment Scope, as defined in § 170.19(d), prior to initiating a Level 3 certification assessment, which will be performed by DCMA DIBCAC (''www.dcma.mil/DIBCAC'') on behalf of the DoD. The OSC ]must complete and achieve a MET result for all security requirements specified in table 1 to § 170.14(c)(4) to achieve the CMMC Status of Level 3 (DIBCAC). DCMA DIBCAC will submit the Level 3 certification assessment results into the CMMC instantiation of eMASS, which then provides automated transmission to SPRS. To maintain compliance with the requirements for a CMMC Status of Level 3 (DIBCAC), the Level 3 certification assessment must be performed every three years for all information systems within the Level 3 CMMC Assessment Scope. In addition, given that compliance with Level 2 requirements is a prerequisite for applying for CMMC Level 3, a Level 2 (C3PAO) certification assessment must also be conducted every three years to maintain CMMC Level 3 (DIBCAC) status. Level 3 certification assessment must be completed within three years of the CMMC Status Date associated with the Final Level 3 (DIBCAC) or, if there was a POA&M, then within three years of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC).

(i) ''Inputs into the CMMC instantiation of eMASS''. The Level 3 certification assessment results input into the CMMC instantiation of eMASS shall include, at minimum, the following items:

(A) Date and level of the assessment. 
(B) For each Assessor(s) conducting the assessment, name and government organization information. 
(C) All industry CAGE code(s) associated with the information system(s) addressed by the CMMC Assessment Scope. 
(D) The name, date, and version of the system security plan(s) (SSP). 
(E) CMMC Status Date. (F) Result for each security requirement objective. 
(G) POA&M usage and compliance, as applicable. 
(H) List of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used.

(ii) ''Conditional Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Conditional Level 3 (DIBCAC) if the Level 3 certification assessment results in a POA&M and the POA&M meets all CMMC Level 3 POA&M requirements listed in § 170.21(a)(3).

(A) ''Plan of Action and Milestones''. A Level 3 POA&M is allowed only in accordance with the CMMC POA&M requirements listed in § 170.21.

(B) ''POA&M closeout''. The OSC must remediate any NOT MET requirements, must undergo a POA&M closeout certification assessment from DCMA DIBCAC, and DCMA DIBCAC must post compliance results into the CMMC instantiation of eMASS within 180 days of the CMMC Status Date associated with the Conditional Level 3 (DIBCAC). If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional Level 3 (DIBAC) CMMC Status for the information system will expire. If Conditional Level 3 (DIBCAC) CMMC Status expires within the period of performance of a contract, standard contractual remedies will apply, and the OSC will be ineligible for additional awards with a requirement for the CMMC Status of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(iii) ''Final Level 3 (DIBCAC)''. The OSC has achieved the CMMC Status of Final Level 3 (DIBCAC) if the Level 3 certification assessment results in a passing score as defined in § 170.24. This score may be achieved upon initial certification assessment or as the result of a POA&M closeout certification assessment, as applicable.

(iv) ''CMMC Status investigation''. The DoD reserves the right to conduct a DCMA DIBCAC assessment of the OSC, as provided for under the 48 CFR 252.204-7020. If the investigative results of a subsequent DCMA DIBCAC assessment show that adherence to the provisions of this part have not been achieved or maintained, these DCMA DIBCAC results will take precedence over any pre-existing CMMC Status. At that time, standard contractual remedies will be available and the OSC will be ineligible for additional awards with CMMC Status requirement of Level 3 (DIBCAC) for the information system within the CMMC Assessment Scope until such time as a new CMMC Status is achieved.

(2) ''Affirmation''. Affirmation of the Level 3 (DIBCAC) CMMC Status is required for all Level 3 certification assessments at the time of each assessment, and annually thereafter. Affirmation procedures are provided in § 170.22.

(b) ''Contract eligibility''. Prior to award of any contract or subcontract with requirement for CMMC Status of Level 3 (DIBCAC), the following two requirements must be met:

(1) The OSC must achieve, as specified in paragraph (a)(1) of this section, a CMMC Status of either Conditional Level 3 (DIBCAC) or Final Level 3 (DIBCAC).

(2) The OSC must submit an affirmation of compliance into SPRS, as specified in paragraph (a)(2) of this section.

(c) ''Procedures - (1) Level 3 certification assessment of the OSC''. The CMMC Level 3 certification assessment process includes:

(i) ''Final Level 2 (C3PAO)''. The OSC must achieve a CMMC Status of Final Level 2 (C3PAO) for information systems within the Level 3 CMMC Assessment Scope prior to the CMMC Level 3 certification assessment. The CMMC Assessment Scope for the Level 3 certification assessment must be equal to, or a subset of, the CMMC Assessment Scope associated with the OSC’s Final Level 2 (C3PAO). Asset requirements differ for each CMMC Level. Scoping differences are set forth in § 170.19.

(ii) ''Initiating the Final Level 3 (DIBCAC)''. The OSC (including ESPs that voluntarily elect to undergo a Level 3 certification assessment) initiates a Level 3 certification assessment by emailing a request to DCMA DIBCAC point of contact found at ''www.dcma.mil/DIBCAC''. The request ]must include the Level 2 certification assessment unique identifier. DCMA DIBCAC will validate the OSC has achieved a CMMC Status of Level 2 (C3PAO) and will contact the OSC to schedule their Level 3 certification assessment.

(iii) ''Conducting the Final Level 3 (DIBCAC)''. DCMA DIBCAC will perform a Level 3 certification assessment in accordance with NIST SP 800-171A Jun2018 (incorporated by reference, see § 170.2) and NIST SP 800-172A Mar2022 (incorporated by reference, see § 170.2) and the CMMC Level 3 scoping requirements set forth in § 170.19(d) for the information systems within the CMMC Assessment Scope. The Level 3 certification assessment will be scored in accordance with the CMMC Scoring Methodology set forth in § 170.24 and DCMA DIBCAC will upload the results into the CMMC instantiation of eMASS. Final results are communicated to the OSC through a CMMC Assessment Findings Report. For assets that changed asset category (''i.e''., CRMA to CUI Asset) or assessment requirements (''i.e''., Specialized Assets) between the Level 2 and Level 3 certification assessments, DCMA DIBCAC will perform limited checks of Level 2 security requirements. If the OSC had these upgraded asset categories included in their Level 2 certification assessment, then DCMA DIBCAC may still perform limited checks for compliance. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated.

(2) ''Security requirement re-evaluation''. A security requirement that is NOT MET (as defined in § 170.24) may be re-evaluated during the course of the Level 3 certification assessment and for 10 business days following the active assessment period if all of the following conditions exist:

(i) Additional evidence is available to demonstrate the security requirement has been MET;

(ii) The additional evidence does not materially impact previously assessed security requirements; and

(iii) The CMMC Assessment Findings Report has not been delivered.

(3) ''POA&M''. If a POA&M exists, a POA&M closeout certification assessment will be performed by DCMA DIBCAC within 180-days of the Conditional CMMC Status Date. Additional guidance is located in § 170.21 and in the guidance document listed in paragraph (d) of appendix A to this part.

(4) ''Artifact retention and integrity''. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. The hashed artifacts used as evidence for the assessment must be retained by the OSC for six (6) years from the CMMC Status Date. To ensure that the artifacts have not been altered, the OSC must hash the artifact files using a NIST-approved hashing algorithm. Assessors will collect the list of the artifact names, the return value of the hashing algorithm, and the hashing algorithm used and upload that data into the CMMC instantiation of eMASS. Additional guidance for hashing artifacts can be found in the guidance document listed in paragraph (h) of appendix A to this part.

(5) ''Level 3 certification assessment with the use of Cloud Service Provider (CSP)''. An OSC may use a cloud environment to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The OSC may utilize a CSP product or service offering that meets the FedRAMP Moderate (or higher) baseline. If the CSP’s product or service offering is not FedRAMP Authorized at the FedRAMP Moderate (or higher) baseline, the product or service offering must meet security requirements equivalent to those established by the FedRAMP Moderate (or higher) baseline in accordance with DoD Policy.

(ii) Use of a CSP does not relieve an OSC of its obligation to implement the 24 Level 3 security requirements. These 24 requirements apply to every environment where the CUI data is processed, stored, or transmitted, when Level 3 (DIBCAC) is the designated CMMC Status. If any of these 24 requirements are inherited from a CSP, the OSC must demonstrate that protection during a Level 3 certification assessment via a Customer Implementation Summary/Customer Responsibility Matrix (CIS/CRM) and associated Body of Evidence (BOE). The BOE must clearly indicate whether the OSC or the CSP is responsible for meeting each requirement and which requirements are implemented by the OSC versus inherited from the CSP.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the CSP’s product or service offering is part of the CMMC Assessment Scope. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

(6) ''Level 3 certification assessment with the use of an ESP, not a CSP''. An OSC may use an ESP that is not a CSP to process, store, or transmit CUI in performance of a contract or subcontract with a requirement for the CMMC Status of Level 3 (DIBCAC) under the following circumstances:

(i) The use of the ESP, its relationship to the OSC, and the services provided are documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix.

(ii) The ESP services used to meet OSC requirements are assessed within the scope of the OSC’s assessment against all Level 2 and Level 3 security requirements.

(iii) In accordance with § 170.19(d)(2), the OSC’s on-premises infrastructure connecting to the ESP’s product or service offering is part of the CMMC Assessment Scope, which will also be assessed. As such, the security requirements from the CRM must be documented or referred to in the OSC’s SSP.

=== § 170.19 CMMC scoping. ===

(a) ''Scoping requirement''. (1) The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of this section. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

(2) The requirements for defining the CMMC Assessment Scope for CMMC Levels 1, 2, and 3 are set forth in this section. Additional guidance regarding scoping can be found in the guidance documents listed in paragraphs (e) through (g) of appendix A to this part.

(b) ''CMMC Level 1 scoping''. Prior to performing a Level 1 self-assessment, the OSA must specify the CMMC Assessment Scope.

(1) ''Assets in scope for Level 1 self-assessment''. OSA information systems which process, store, or transmit FCI are in scope for CMMC Level 1 and must be self-assessed against applicable CMMC security requirements.

(2) ''Assets not in scope for Level 1 self-assessment'' - (i) ''Out-of-Scope Assets''. OSA information systems which do not process, store, or transmit FCI are outside the scope for CMMC Level 1. An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of FCI beyond the Keyboard/Video/Mouse sent to the VDI client is considered out-of-scope. There are no documentation requirements for out-of-scope assets.

(ii) ''Specialized Assets''. Specialized Assets are those assets that can process, store, or transmit FCI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment. Specialized Assets are not part of the Level 1 CMMC Assessment Scope and are not assessed against CMMC security requirements.

(3) ''Level 1 self-assessment scoping considerations''. To scope a Level 1 self-assessment, OSAs should consider the people, technology, facilities, and External Service Providers (ESP) within its environment that process, store, or transmit FCI.

(c) ''CMMC Level 2 Scoping''. Prior to performing a Level 2 self-assessment or Level 2 certification assessment, the OSA must specify the CMMC Assessment Scope.

(1) The CMMC Assessment Scope for CMMC Level 2 is based on the specification of asset categories and their respective requirements as defined in table 3 to this paragraph (c)(1). Additional information is available in the guidance document listed in paragraph (f) of appendix A to this part.

==== Table 3 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 3 TO § 170.19(c)(1) - CMMC LEVEL 2 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against all Level 2 security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSA’s CMMC As-sessment Scope.
|
* Document in the asset inventory
* Document asset treatment in SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Assess against Level 2 security requirements that are relevant to the ca-pabilities provided.
|- style="vertical-align:top;"
| Contractor Risk Managed Assets.
|
* Assets that can, but are not intended to, process, store, or transmit CUI be-cause of security policy, procedures, and practices in place.
* Assets are not required to be physically or logically separated from CUI assets.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 security requirements.
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC secu-rity requirements, except as noted.
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies.
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost.
** The limited check(s) will be assessed against CMMC security re-quirements.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Show these assets are managed using the contractor’s risk-based security poli-cies, procedures, and practices.
* Document in the network diagram of the CMMC Assessment Scope.
|
* Review the SSP.
* Do not assess against other CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|- style="vertical-align:top;"
|Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 4 to this paragraph (c)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 4 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 4 TO § 170.19(c)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum assessment type for the ESP is dictated by the OSA’s DoD contract requirement.

(d) ''CMMC Level 3 scoping''. Prior to performing a Level 3 certification assessment, the CMMC Assessment Scope must be specified.

(1) The CMMC Assessment Scope for Level 3 is based on the specification of asset categories and their respective requirements as set forth in table 5 to this paragraph (d)(1). Additional information is available in the guidance document listed in paragraph (g) of appendix A to this part.

==== Table 5 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 5 TO § 170.19(d)(1) - CMMC LEVEL 3 ASSET CATEGORIES AND ASSOCIATED REQUIREMENTS
|-
! style="width: 25%;text-align:left" | Asset category
! style="width: 25%;text-align:left" | Asset description
! style="width: 25%;text-align:left" | OSA requirements
! style="width: 25%;text-align:left" | CMMC assessment requirements
|-
| colspan="4" style="text-align:center;" | '''Assets that are in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Controlled Unclassified Information (CUI) Assets.
|
* Assets that process, store, or transmit CUI.
|
* Assets that can, but are not intended to, process, store, or transmit CUI (de-fined as Contractor Risk Managed As-sets in table 1 to paragraph (c)(1) of this section CMMC Scoping).
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP).
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
|- style="vertical-align:top;"
| Security Protection Assets
|
* Assets that provide security functions or capabilities to the OSC’s CMMC As-sessment Scope, irrespective of wheth-er or not these assets process, store, or transmit CUI.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements that are relevant to the capabilities provided.
|- style="vertical-align:top;"
| Specialized Assets
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Fur-nished Equipment (GFE), Restricted In-formation Systems, and Test Equip-ment.
|
* Document in the asset inventory
* Document asset treatment in the SSP.
* Document in the network diagram of the CMMC Assessment Scope.
* Prepare to be assessed against CMMC Level 2 and Level 3 security require-ments.
|
* Limited check against Level 2 and assess against all Level 3 CMMC security requirements.
* Intermediary devices are permitted to provide the capability for the special-ized asset to meet one or more CMMC security requirements.
|-
| colspan="4" style="text-align:center;" | '''Assets that are not in the Level 3 CMMC Assessment Scope'''
|- style="vertical-align:top;"
| Out-of-Scope Assets
|
* Assets that cannot process, store, or transmit CUI; and do not provide secu-rity protections for CUI Assets.
* Assets that are physically or logically separated from CUI assets.
* Assets that fall into any in-scope asset category cannot be considered an Out- of-Scope Asset.
* An endpoint hosting a VDI client configured to not allow any processing, stor-age, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset.
|
* Prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.
|
* None.
|}

(2)(i) Table 6 to this paragraph (d)(2)(i) defines the requirements to be met when utilizing an External Service Provider (ESP). The OSA must consider whether the ESP is a Cloud Service Provider (CSP) and whether the ESP processes, stores, or transmits CUI and/ or Security Protection Data (SPD).

==== Table 6 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 6 TO § 170.19(d)(2)(i) - ESP SCOPING REQUIREMENTS
|-
! style="width: 30%;text-align:left" | When the ESP processes, stores, or transmits:
! style="width: 35%;text-align:left" | When utilizing an ESP that is a CSP
! style="width: 35%;text-align:left" | When utilizing an ESP that is not a CSP
|- style="vertical-align:top;"
| CUI (with or without SPD)
| The CSP shall meet the FedRAMP requirements in 48 CFR 252.204-7012.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as part of the OSA’s assessment.
|- style="vertical-align:top;"
| SPD (without CUI)
| The services provided by the CSP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
| The services provided by the ESP are in the OSA’s assessment scope and shall be assessed as Security Protection Assets.
|- style="vertical-align:top;"
| Neither CUI nor SPD
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
| A service provider that does not process CUI or SPD does not meet the CMMC definition of an ESP.
|}

(ii) The use of an ESP, its relationship to the OSC, and the services provided need to be documented in the OSC’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSC and ESP with respect to the services provided. Note that the ESP may voluntarily undergo a CMMC certification assessment to reduce the ESP’s effort required during the OSA’s assessment. The minimum. The minimum assessment type for the ESP is dictated by the OSC’s DoD contract requirement.

(e) ''Relationship between Level 2 and Level 3 CMMC Assessment Scope''. The Level 3 CMMC Assessment Scope must be equal to or a subset of the Level 2 CMMC Assessment Scope in accordance with § 170.18(a) (''e.g.'', a Level 3 data enclave with greater restrictions and protections within a Level 2 data enclave). Any Level 2 POA&M items must be closed prior to the initiation of the Level 3 certification assessment. DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset. If DCMA DIBCAC identifies that a Level 2 security requirement is NOT MET, the Level 3 assessment process may be paused to allow for remediation, placed on hold, or immediately terminated. For further information regarding scoping of CMMC Level 3 assessments please contact DCMA DIBCAC at ''www.dcma.mil/DIBCAC/''.

=== § 170.20 Standards acceptance. ===

(a) ''NIST SP 800-171 R2 DoD assessments''. In order to avoid duplication of efforts, thereby reducing the aggregate cost to industry and the Department, OSCs that have completed a DCMA DIBCAC High Assessment aligned with CMMC Level 2 Scoping will be given the CMMC Status of Final Level 2 (C3PAO) under the following conditions:

(1) ''DCMA DIBCAC High Assessment''. An OSC that achieved a perfect score with no open POA&M from a DCMA DIBCAC High Assessment conducted prior to the effective date of this rule, will be given a CMMC Status of Level 2 Final (C3PAO) with a validity period of three (3) years from the date of the original DCMA DIBCAC High Assessment. DCMA DIBCAC will identify assessments that meet these criteria and verify that SPRS accurately reflects the CMMC Status. Eligible DCMA DIBCAC High Assessments include ones conducted with Joint Surveillance in accordance with the DCMA Manual 2302-01 Surveillance. The scope of the Level 2 certification assessment is identical to the scope of the DCMA DIBCAC High Assessment. In accordance with § 170.17(a)(2), the OSC must also submit an affirmation in SPRS and annually thereafter to achieve contractual eligibility.

(2) [Reserved]. 
(b) [Reserved]. 

=== § 170.21 Plan of Action and Milestones requirements. ===

(a) ''POA&M''. For purposes of achieving a Conditional CMMC Status, an OSA is only permitted to have a POA&M for select requirements scored as NOT MET during the CMMC assessment and only under the following conditions:

(1) ''Level 1 self-assessment''. A POA&M is not permitted at any time for Level 1 self-assessments.

(2) ''Level 2 self-assessment and Level 2 certification assessment''. An OSA is only permitted to achieve the CMMC Status of Conditional Level 2 (Self) or Conditional Level 2 (C3PAO), as appropriate, if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 2 security requirements is greater than or equal to 0.8;

(ii) None of the security requirements included in the POA&M have a point value of greater than 1 as specified in the CMMC Scoring Methodology set forth in § 170.24, except SC.L2-3.13.11 CUI Encryption may be included on a POA&M if encryption is employed but it is not FIPS-validated, which would result in a point value of 3; and

(iii) None of the following security requirements are included in the POA&M:

(A) AC.L2-3.1.20 External Connections (CUI Data). 
(B) AC.L2-3.1.22 Control Public Information (CUI Data). 
(C) CA.L2-3.12.4 System Security Plan. 
(D) PE.L2-3.10.3 Escort Visitors (CUI Data). 
(E) PE.L2-3.10.4 Physical Access Logs (CUI Data). 
(F) PE.L2-3.10.5 Manage Physical Access (CUI Data). 

(3) ''Level 3 certification assessment''. An OSC is only permitted to achieve the CMMC Status of Conditional Level 3 (DIBCAC) if all the following conditions are met:

(i) The assessment score divided by the total number of CMMC Level 3 security requirements is greater than or equal to 0.8; and

(ii) The POA&M does not include any of following security requirements:

(A) IR.L3-3.6.1e Security Operations Center. 
(B) IR.L3-3.6.2e Cyber Incident Response Team. 
(C) RA.L3-3.11.1e Threat-Informed Risk Assessment. 
(D) RA.L3-3.11.6e Supply Chain Risk Response. 
(E) RA.L3-3.11.7e Supply Chain Risk Plan. 
(F) RA.L3-3.11.4e Security Solution Rationale. 
(G) SI.L3-3.14.3e Specialized Asset Security. 

(b) ''POA&M closeout assessment''. A POA&M closeout assessment is a CMMC assessment that assesses only the NOT MET requirements that were identified with POA&M in the initial assessment. The closing of a POA&M must be confirmed by a POA&M closeout assessment within 180-days of the Conditional CMMC Status Date. If the POA&M is not successfully closed out within the 180-day timeframe, the Conditional CMMC Status for the information system will expire.

(1) ''Level 2 self-assessment''. For a Level 2 self-assessment, the POA&M closeout self-assessment shall be performed by the OSA in the same manner as the initial self-assessment.

(2) ''Level 2 certification assessment''. For Level 2 certification assessment, the POA&M closeout certification assessment must be performed by an authorized or accredited C3PAO.

(3) ''Level 3 certification assessment''. For Level 3 certification assessment, DCMA DIBCAC will perform the POA&M closeout certification assessment.

=== § 170.22 Affirmation. ===

(a) ''General''. The OSA must affirm continuing compliance with the appropriate level self-assessment or certification assessment. An Affirming Official from each OSA, whether a prime or subcontractor, must affirm the continuing compliance of their respective organizations with the specified security requirement after every assessment, including POA&M closeout, and annually thereafter. Affirmations are entered electronically in SPRS. The affirmation shall be submitted in accordance with the following requirements:

(1) ''Affirming Official''. The Affirming Official is the senior level representative from within each Organization Seeking Assessment (OSA) who is responsible for ensuring the OSA’s compliance with the CMMC Program requirements and has the authority to affirm the OSA’s continuing compliance with the specified security requirements for their respective organizations.

(2) ''Affirmation content''. Each CMMC affirmation shall include the following information:

(i) Name, title, and contact information for the Affirming Official; and

(ii) Affirmation statement attesting that the OSA has implemented and will maintain implementation of all applicable CMMC security requirements to their CMMC Status for all information systems within the relevant CMMC Assessment Scope.

(3) ''Affirmation submission''. The Affirming Official shall submit a CMMC affirmation in the following instances:

(i) Upon achievement of a Conditional CMMC Status, as applicable;

(ii) Upon achievement of a Final CMMC Status;

(iii) Annually following a Final CMMC Status Date; and

(iv) Following a POA&M closeout assessment, as applicable.

(b) ''Submission procedures''. All affirmations shall be completed in SPRS. The Department will verify submission of the affirmation in SPRS to ensure compliance with CMMC solicitation or contract requirements.

(1) ''Level 1 self-assessment''. At the

completion of a Level 1 self-assessment and annually thereafter, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 1 (Self).

(2) ''Level 2 self-assessment''. At the

completion of a Level 2 self-assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (Self). An affirmation shall also be submitted at the completion of a POA&M closeout self-assessment.

(3) ''Level 2 certification assessment''. At

the completion of a Level 2 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 2 (C3PAO). An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

(4) ''Level 3 certification assessment''. At

the completion of a Level 3 certification assessment and annually following a Final CMMC Status Date, the Affirming Official shall submit a CMMC affirmation attesting to continuing compliance with all requirements of the CMMC Status Level 3 (DIBCAC). Because C3PAOs and DCMA DIBCAC check for compliance with different requirements in their respective assessments, OSCs must annually affirm their CMMC Status of Level 2 (C3PAO) in addition to their CMMC Status of Level 3 (DIBCAC) to maintain eligibility for contracts requiring compliance with Level 3. An affirmation shall also be submitted at the completion of a POA&M closeout certification assessment.

=== § 170.23 Application to subcontractors. ===

(a) CMMC requirements apply to prime contractors and subcontractors throughout the supply chain at all tiers that will process, store, or transmit any FCI or CUI on contractor information systems in the performance of the DoD contract or subcontract. Prime contractors shall comply and shall require subcontractors to comply with and to flow down CMMC requirements, such that compliance will be required throughout the supply chain at all tiers with the applicable CMMC level and assessment type for each subcontract as follows:

(1) If a subcontractor will only process, store, or transmit FCI (and not CUI) in performance of the subcontract, then a CMMC Status of Level 1 (Self) is required for the subcontractor.

(2) If a subcontractor will process, store, or transmit CUI in performance of the subcontract, then a CMMC Status of Level 2 (Self) is the minimum requirement for the subcontractor.

(3) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for a CMMC Status of Level 2 (C3PAO), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(4) If a subcontractor will process, store, or transmit CUI in performance of the subcontract and the associated prime contract has a requirement for the CMMC Status of Level 3 (DIBCAC), then the CMMC Status of Level 2 (C3PAO) is the minimum requirement for the subcontractor.

(b) As with any solicitation or contract, the DoD may provide specific guidance pertaining to flow-down.

=== § 170.24 CMMC Scoring Methodology. ===

(a) ''General''. This scoring methodology is designed to provide a measurement of an OSA’s implementation status of the NIST SP 800-171 R2 security requirements (incorporated by reference elsewhere in this part, see § 170.2) and the selected NIST SP 800-172 Feb2021 security requirements (incorporated by reference elsewhere in this part, see § 170.2). The CMMC Scoring Methodology is designed to credit partial implementation only in limited cases (''e.g.'', multi-factor authentication IA.L2-3.5.3).

(b) ''Assessment findings''. Each security requirement assessed under the CMMC Scoring Methodology must result in one of three possible assessment findings, as follows:

(1) ''Met''. All applicable objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include but are not limited to working papers, drafts, and unofficial or unapproved policies.

(i) Enduring exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.

(ii) Temporary deficiencies that are appropriately addressed in operational plans of action (''i.e.'', include deficiency reviews and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.

(2) ''Not Met''. One or more applicable objectives for the security requirement is not satisfied. During an assessment, for each security requirement objective marked NOT MET, the assessor will document why the evidence does not conform.

(3) ''Not Applicable (N/A)''. A security requirement and/or objective does not apply at the time of the CMMC assessment. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.

(c) ''Scoring''. At each CMMC Level, security requirements are scored as follows:

(1) ''CMMC Level 1''. All CMMC Level 1 security requirements must be fully implemented to be considered MET. No POA&M is permitted for CMMC Level 1, and self-assessment results are scored as MET or NOT MET in their entirety.

(2) ''CMMC Level 2 Scoring Methodology''. The maximum score achievable for a Level 2 self-assessment or Level 2 certification assessment is equal to the total number of CMMC Level 2 security requirements. If all CMMC Level 2 security requirements are MET, OSAs are awarded the maximum score. For each requirement NOT MET, the associated value of the security requirement is subtracted from the maximum score, which may result in a negative score.

(i) ''Procedures''. (A) Scoring methodology for Level 2 self-assessment and Level 2 certification assessment is based on all CMMC Level 2 security requirement objectives, including those NOT MET.

(B) In the CMMC Level 2 Scoring Methodology, each security requirement has a value (''e.g.'', 1, 3 or 5), which is related to the designation by NIST as basic or derived security requirements. Per NIST SP 800-171 R2, the basic security requirements are obtained from FIPS PUB 200 Mar2006, which provides the high-level and fundamental security requirements for Federal information and systems. The derived security requirements, which supplement the basic security requirements, are taken from the security controls in NIST SP 800-53 R5.

(''1'') For NIST SP 800-171 R2 basic and derived security requirements that, if not implemented, could lead to significant exploitation of the network, or exfiltration of CUI, five (5) points are subtracted from the maximum score. The basic and derived security requirements with a value of five (5) points include:

(''i'') ''Basic security requirements''. AC.L2-3.1.1, AC.L2-3.1.2, AT.L2-3.2.1, AT.L2-3.2.2, AU.L2-3.3.1, CM.L2-3.4.1, CM.L2-3.4.2, IA-L2-3.5.1, IA-L2-3.5.2, IR.L2-3.6.1, IR.L2-3.6.2, MA.L2-3.7.2, MP.L2-3.8.3, PS.L2-3.9.2, PE.L2-3.10.1, PE.L2-3.10.2, CA.L2-3.12.1, CA.L2-3.12.3, SC.L2-3.13.1, SC.L2-3.13.2, SI.L2-3.14.1, SI.L2-3.14.2, and SI.L2-3.14.3.

(''ii'') ''Derived security requirements''. AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.16, AC.L2-3.1.17, AC.L2-3.1.18, AU.L2-3.3.5, CM.L2-3.4.5, CM.L2-3.4.6, CM.L2-3.4.7, CM.L2-3.4.8, IA.L2-3.5.10, MA.L2-3.7.5, MP.L2-3.8.7, RA.L2-3.11.2, SC.L2-3.13.5, SC.L2-3.13.6, SC.L2-3.13.15, SI.L2-3.14.4, and SI.L2-3.14.6.

(''2'') For basic and derived security requirements that, if not implemented, have a specific and confined effect on the security of the network and its data, three (3) points are subtracted from the maximum score. The basic and derived security requirements with a value of three (3) points include:

(''i'') ''Basic security requirements''. AU.L2-3.3.2, MA.L2-3.7.1, MP.L2-3.8.1, MP.L2-3.8.2, PS.L2-3.9.1, RA.L2-3.11.1, and CA.L2-3.12.2.

(''ii'') ''Derived security requirements''. AC.L2-3.1.5, AC.L2-3.1.19, MA.L2-3.7.4, MP.L2-3.8.8, SC.L2-3.13.8, SI.L2-3.14.5, and SI.L2-3.14.7.

(''3'') All remaining derived security requirements, other than the exceptions noted, if not implemented, have a limited or indirect effect on the security of the network and its data. For these, 1 point is subtracted from the maximum score.

(''4'') Two derived security requirements, IA.L2-3.5.3 and SC.L2-3.13.11, can be partially effective even if not completely or properly implemented, and the points deducted may be adjusted depending on how the security requirement is implemented.

(''i'') Multi-factor authentication (MFA) (CMMC Level 2 security requirement IA.L2-3.5.3) is typically implemented first for remote and privileged users (since these users are both limited in number and more critical) and then for the general user, so three (3) points are subtracted from the maximum score if MFA is implemented only for remote and privileged users. Five (5) points are subtracted from the maximum score if MFA is not implemented for any users.

(''ii'') FIPS-validated encryption (CMMC Level 2 security requirement SC.L2-3.13.11) is required to protect the confidentiality of CUI. If encryption is employed, but is not FIPS-validated, three (3) points are subtracted from the maximum score; if encryption is not employed; five (5) points are subtracted from the maximum score.

(''5'') OSAs must have a System Security Plan (SSP) (CMMC security requirement CA.L2-3.12.4) in place at the time of assessment to describe each information system within the CMMC Assessment Scope. The absence of an up to date SSP at the time of the assessment would result in a finding that ‘''an assessment could not be completed due to incomplete information and noncompliance with 48 CFR 252.204- 7012.''’

(''6'') For each NOT MET security requirement the OSA must have a POA&M in place. A POA&M addressing NOT MET security requirements is not a substitute for a completed requirement. Security requirements not implemented, whether described in a POA&M or not, is assessed as ‘NOT MET.’

(''7'') Specialized Assets must be evaluated for their asset category per the CMMC scoping guidance for the level in question and handled accordingly as set forth in § 170.19.

(''8'') If an OSC previously received a favorable adjudication from the DoD CIO indicating that a security requirement is not applicable or that an alternative security measure is equally effective (in accordance with 48 CFR 252.204-7008 or 48 CFR 252.204-7012), the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. A security requirement for which implemented security measures have been adjudicated by the DoD CIO as equally effective is assessed as MET if there have been no changes in the environment.

(ii) ''CMMC Level 2 Scoring Table''. CMMC Level 2 scoring has been assigned based on the methodology set forth in table 1 to this paragraph (c)(2)(ii).

==== Table 7 ====
{| class="wikitable" style="margin:auto"
|+ TABLE 7 TO § 170.24(c)(2)(ii) - CMMC LEVEL 2 SCORING TABLE
|-
! style="width: 80%;text-align:left" | CMMC Level 2 requirement categories
! style="width: 20%;text-align:right" | Point value subtracted from maximum score
|-
| colspan="2" | ''Basic Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|-
| colspan="2" | ''Derived Security Requirements:''
|- style="vertical-align:top;"
|
: If not implemented, could lead to significant exploitation of the network, or exfiltration of CUI
| style="text-align:right;" | 5
|- style="vertical-align:top;"
|
: If not completely or properly implemented, could be partially effective and points adjusted depending on how the security requirement is implemented:
:: - Partially effective implementation - 3 points.
:: - Non-effective (not implemented at all) - 5 points.
| style="text-align:right;" | 3 or 5
|- style="vertical-align:top;"
|
: If not implemented, has specific and confined effect on the security of the network and its data
| style="text-align:right;" | 3
|- style="vertical-align:top;"
|
: If not implemented, has a limited or indirect effect on the security of the network and its data
| style="text-align:right;" | 1
|}

(3) ''CMMC Level 3 assessment scoring methodology''. CMMC Level 3 scoring does not utilize varying values like the scoring for CMMC Level 2. All CMMC Level 3 security requirements use a value of one (1) point for each security requirement. As a result, the maximum score achievable for a Level 3 certification assessment is equivalent to the total number of the selected subset of NIST SP 800-172 Feb2021 security requirements for CMMC Level 3, see § 170.14(c)(4). The maximum score is reduced by one (1) point for each security requirement NOT MET. The CMMC Level 3 scoring methodology reflects the fact that all CMMC Level 2 security requirements must already be MET (for the Level 3 CMMC Assessment Scope). A maximum score on the Level 2 certification assessment is required to be eligible to initiate a Level 3 certification assessment. The Level 3 certification assessment score is equal to the number of CMMC Level 3 security requirements that are assessed as MET.

=== Appendix A to Part 170 - Guidance ===

Guidance documents include:

(a) ‘‘CMMC Model Overview’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(b) ‘‘CMMC Assessment Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(c) ‘‘CMMC Assessment Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(d) ‘‘CMMC Assessment Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(e) ‘‘CMMC Scoping Guide - Level 1’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(f) ‘‘CMMC Scoping Guide - Level 2’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(g) ‘‘CMMC Scoping Guide - Level 3’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

(h) ‘‘CMMC Hashing Guide’’ available at [https://DoDcio.defense.gov/CMMC/ ''https://DoDcio.defense.gov/CMMC/''.]

Dated: September 30, 2024.

'''Patricia L. Toppings'', '''OSD Federal Register Liaison Officer, Department of Defense''. [FR Doc. 2024-22905 Filed 10-11-24; 8:45 am]

'''BILLING CODE 6001-FR-P'''

Level 2 Scoping Guidance

2025-05-27T18:20:40Z

David: /* External Service Provider Considerations */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us].Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.This document is intended only to provide clarity to the public
regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A.Approved for public release.Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 2 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR).Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document.Guidance for scoping a Level 3 certification assessment can be
found in the ''CMMC Scoping Guide – Level 3'' document.More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 2 self-assessment in accordance with 32 CFR § 170.16, Organizations Seeking Certification (OSCs) that will be obtaining a Level 2 certification assessment in accordance with 32 CFR § 170.17, and the professionals or companies that will support them in those
efforts.The security requirements for a Level 2 self-assessment and a Level 2 certification assessment are the same, the only difference in these assessments is whether it is conducted by the OSA or by an independent C3PAO.

OSCs are a subset of OSAs as all organizations will participate in an assessment, but self-assessment cannot result in a certification.

=== Identifying the CMMC Assessment Scope ===
An ''Assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment.The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a CMMC assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(c).The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the assessment.

Because the scoping of a Level 2 assessment is not the same as the scoping of a Level 3 assessment, before determining the CMMC Assessment Scope it is important to first consider if the organization will seek a CMMC Status of Final Level 3 (DIBCAC).If the intent is to obtain a CMMC Status of Final Level 3 (DIBCAC), the OSC should also consider the guidance provided in the ''CMMC Scoping Guide – Level 3'' document.The OSC must closeout any Level 2 Plan of Action and Milestones (POA&M) and achieve a CMMC Status of Final Level 2 (C3PAO) prior to initiating a Level 3 certification assessment.

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment
Scope. OSCs may choose to designate them as CUI Assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment.During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC certification assessment.

== CMMC Asset Categories ==
For a Level 2 assessment, assets are mapped into one of five categories defined in 32 CFR § 170.19(c)(1) Table 3. This table describes each asset category and its corresponding OSA requirements and CMMC assessment requirements.Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="width: 85%;"
|+ Table 1. CMMC Asset Categories and Associated Requirements Overview
! style="width: 16%"| '''Asset Category'''
! style="width: 28%"| '''Asset Description'''
! style="width: 28%"| '''OSA Requirements'''
! style="width: 28%"| '''CMMC Assessment Requirements'''
|-
| colspan="4" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against all Level 2 security requirements
|-
| '''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope
|
* Document in the asset inventory
* Document asset treatment in SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against Level 2 security requirements that are relevant to the capabilities provided
|-
| '''Contractor Risk Managed Assets'''
|
* Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
* Assets are not required to be physically or logically separated from CUI assets
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC security requirements, except as noted
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost
** The limited check(s) will be assessed against CMMC security requirements
|-
|'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
** Show these assets are managed using the contractor's risk-based security policies
* Document in the network diagram of the CMMC Assessment Scope
|
* Review the SSP
* Do not assess against other CMMC security requirements
|-
| colspan="4" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|-
| '''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUIassets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 2 Scoping ==
The OSA is required to document all asset categories that are part of the Level 2 self-assessment or certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets process, store, or transmit CUI as follows:
* '''Process''' – CUI can be used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – CUI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the System Security Plan (SSP);
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSA’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against Level 2 security requirements that are relevant to the capabilities provided.For example, an External Service Provider (ESP), defined in 32 CFR §170.4, that provides a security information and event management (SIEM) service may be separated logically and may not process CUI, but the SIEM does contribute to meeting the CMMC requirements within the OSA’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system.It includes, but is not limited to:
* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Contractor Risk Managed Assets ===
Contractor Risk Managed Assets are not intended to, but are capable of processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

Contractor Risk Managed Assets are part of the Level 2 CMMC Assessment Scope. These assets are managed using the OSA’s risk-based information security policy, procedures, and practices. Furthermore, the assets must be assessed against CMMC requirements if insufficiently documented in the SSP or if the OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets.In these cases, the assessor can conduct a limited check to identify deficiencies.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

Assessment requirements for Contractor Risk Managed Asset are detailed in Table 1.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 2 assessment when documented in accordance with Table 1 (reprinted from 32 CFR § 170.19(c)(1) Table 3). Note that a Specialized Asset may be eligible for an Enduring Exception.

* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSA-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the CMMC Assessment Scope.In accordance with 32 CFR § 170.19(c)(1) Table 3, the OSA shall document these assets in the SSP and detail how they are managed using the OSA’s risk-based information security policy, procedures, and practices.

In addition, the OSA is required to:
* document each asset in asset inventory; there is no requirement to embed every asset in the SSP;
* document these assets in the SSP to show they are managed using the OSA’s risk-based security policies, procedures, and practices; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

An assessor will review the SSP to verify that specialized assets are managed using the OSA’s risk-based information security policy, procedures, and practices, and accounted for within the OSA’s CMMC Assessment Scope.The assessor will not retain a copy of the SSP.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(c)(1), Out-of-Scope Assets are not part of a Level 2 self-assessment or certification assessment.There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSA then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSA’s environment that will be assessed in accordance with Table 1. OSAs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor.Details about required documentation for each asset category can be found in the [[Level_2_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 2 CMMC Assessment Scope:
* CUI Assets
* Security Protection Assets
* Contractor Risk Managed Assets
* Specialized Assets

=== Separation Techniques ===
Separation is a system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI. Effective separation involves logically or physically separating assets and is required only for Out-of-Scope Assets.By separating assets, the CMMC Assessment Scope can be limited. Effective separation for CMMC follows the guidance in NIST SP 800-171 Rev 2, which states:

''If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms).Security domains may employ physical separation, logical separation, or a combination of both.This approach can provide adequate security for the CUI and avoid increasing the organization’s security posture to a level beyond that which it requires for protecting its missions, operations, and assets.''

'''Logical separation''' occurs when data transfer between physically connected assets (wired or wireless) is prevented by non-physical means such as software or network assets (e.g., firewall, routers, VPNs, VLANs).

'''Physical separation''' occurs when assets have no connection (wired or wireless). Data can only be transferred manually (e.g., USB drive).

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping.A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP, do not require a new assessment, but rather may be covered by annual affirmations to the continuing compliance with requirements.

=== External Service Provider Considerations ===
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI Asset and/or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(c)(2). Special considerations for an OSA using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security requirement objectives that are the provider’s responsibility and security requirement objectives that are the OSA’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSA’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012.Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a C3PAO assessment, and a C3PAO may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2, as applicable, against their on-premise infrastructure connecting to the CSP.As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

=== Use Cases ===
'''FCI and CUI in the Same Assessment Scope'''

A Level 2 self-assessment or Level 2 certification assessment satisfies the Level 1 self-assessment requirements for the same CMMC Assessment Scope.If FCI is processed, stored, or transmitted within the same scope as CUI in the Level 2 scope, then the methods to implement the Level 2 security requirements apply towards meeting the Level 1 assessment objectives. The OSA is responsible for ensuring that only authorized users and processes have access to data regardless of its designation.

'''FCI and CUI in Different Assessment Scopes'''

If FCI and CUI do not share an environment, the two assessments would be conducted independently and methods to implement security requirements in one scope would not apply to the other scope.

'''Use of Enclaves'''

Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise.This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope.For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool.Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope.

Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way.

There is no established metric for inherited implementations from an enterprise to any defined enclaves.The OSA determines the architecture that best meets its business needs and complies with CMMC requirements.

'''Security Protection Data'''

Security Protection Data (SPD) can be created by or used by a Security Protection Asset (SPA).Aggregated logs in a SIEM are one example of SPD and the SIEM is considered the SPA. The SIEM is part of the assessment scope.Because of the wide range of SIEM tools available, (on-premise hardware appliance; on-premise virtual appliance; or cloud based), methods of assessing the SIEM will also vary. If the SIEM and/or associated log data is hosted or maintained by an ESP, then the portion of the ESP that is used to provide the SIEM service or log storage is part of the OSA’s assessment scope.SIEM logs are typically available in hot storage for some period of time as part of the SIEM deployment.In this case, the SPD is collocated with the SPA.Cold storage of logs for a longer period of time is typically done offline or in cloud storage.The method used and the location of the cold storage are also in the OSA’s assessment scope.

== Notes ==
<references />

Level 2 Scoping Guidance

2025-05-27T18:14:29Z

David: /* External Service Provider Considerations */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Scoping Guidance Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us].Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way.This document is intended only to provide clarity to the public
regarding existing CMMC requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A.Approved for public release.Distribution is unlimited.

== Introduction ==
This document provides scoping guidance for Level 2 of the Cybersecurity Maturity Model Certification (CMMC) as set forth in section 170.19 of title 32, Code of Federal Regulations (CFR).Guidance for scoping a Level 1 self-assessment can be found in the ''CMMC Scoping Guide – Level 1'' document.Guidance for scoping a Level 3 certification assessment can be
found in the ''CMMC Scoping Guide – Level 3'' document.More details on the CMMC Model can be found in the ''CMMC Model Overview'' document.

=== Purpose and Audience ===
This guide is intended for Organizations Seeking Assessment (OSAs) that will be conducting a Level 2 self-assessment in accordance with 32 CFR § 170.16, Organizations Seeking Certification (OSCs) that will be obtaining a Level 2 certification assessment in accordance with 32 CFR § 170.17, and the professionals or companies that will support them in those
efforts.The security requirements for a Level 2 self-assessment and a Level 2 certification assessment are the same, the only difference in these assessments is whether it is conducted by the OSA or by an independent C3PAO.

OSCs are a subset of OSAs as all organizations will participate in an assessment, but self-assessment cannot result in a certification.

=== Identifying the CMMC Assessment Scope ===
An ''Assessment'', as defined in 32 CFR § 170.4, means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization.

This document should help the reader understand the categorization of assets that, in turn, inform the specification of the boundary for a CMMC assessment.The scope of the CMMC Program does not include classified assets, even if they contain applicable Controlled Unclassified Information (CUI).

Prior to conducting a CMMC assessment, the OSA must specify the CMMC Assessment Scope as defined in 32 CFR § 170.19(c).The CMMC Assessment Scope defines which assets within the OSA’s environment will be assessed and the details of the assessment.

Because the scoping of a Level 2 assessment is not the same as the scoping of a Level 3 assessment, before determining the CMMC Assessment Scope it is important to first consider if the organization will seek a CMMC Status of Final Level 3 (DIBCAC).If the intent is to obtain a CMMC Status of Final Level 3 (DIBCAC), the OSC should also consider the guidance provided in the ''CMMC Scoping Guide – Level 3'' document.The OSC must closeout any Level 2 Plan of Action and Milestones (POA&M) and achieve a CMMC Status of Final Level 2 (C3PAO) prior to initiating a Level 3 certification assessment.

Assets designated as Contractor Risk Managed Assets (CRMAs) in the Level 2 CMMC Assessment Scope are treated as CUI assets if they fall within the Level 3 CMMC Assessment
Scope. OSCs may choose to designate them as CUI Assets for the Level 2 certification assessment and have them assessed by a C3PAO.

Since the assessment requirements for Specialized Assets differ between Level 2 and Level 3, the OSC may choose to have them assessed by a C3PAO during the Level 2 certification assessment.During a Level 3 certification assessment, DCMA DIBCAC may check any Level 2 security requirement of any in-scope asset.

CRMAs and Specialized Assets not assessed to the Level 3 scoping requirements by a C3PAO during the Level 2 certification assessment will undergo limited checks for compliance with Level 2 security requirements during the DCMA DIBCAC certification assessment.

== CMMC Asset Categories ==
For a Level 2 assessment, assets are mapped into one of five categories defined in 32 CFR § 170.19(c)(1) Table 3. This table describes each asset category and its corresponding OSA requirements and CMMC assessment requirements.Additional information about each asset category is provided in the ensuing sections.

{| class="wikitable" style="width: 85%;"
|+ Table 1. CMMC Asset Categories and Associated Requirements Overview
! style="width: 16%"| '''Asset Category'''
! style="width: 28%"| '''Asset Description'''
! style="width: 28%"| '''OSA Requirements'''
! style="width: 28%"| '''CMMC Assessment Requirements'''
|-
| colspan="4" | '''Assets that are in the Level 2 CMMC Assessment Scope'''
|-
| '''Controlled Unclassified Information (CUI) Assets'''
|
* Assets that process, store, or transmit CUI
|
* Document in the asset inventory
* Document asset treatment in the System Security Plan (SSP)
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against all Level 2 security requirements
|-
| '''Security Protection Assets'''
|
* Assets that provide security functions or capabilities to the OSA's CMMC Assessment Scope
|
* Document in the asset inventory
* Document asset treatment in SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Assess against Level 2 security requirements that are relevant to the capabilities provided
|-
| '''Contractor Risk Managed Assets'''
|
* Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures, and practices in place
* Assets are not required to be physically or logically separated from CUI assets
|
* Document in the asset inventory
* Document asset treatment in the SSP
* Document in the network diagram of the CMMC Assessment Scope
* Prepare to be assessed against CMMC Level 2 security requirements
|
* Review the SSP:
** If sufficiently documented, do not assess against other CMMC security requirements, except as noted
** If OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets, the assessor can conduct a limited check to identify deficiencies
** The limited check(s) shall not materially increase the assessment duration nor the assessment cost
** The limited check(s) will be assessed against CMMC security requirements
|-
|'''Specialized Assets'''
|
* Assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment
|
* Document in the asset inventory
* Document asset treatment in the SSP
** Show these assets are managed using the contractor's risk-based security policies
* Document in the network diagram of the CMMC Assessment Scope
|
* Review the SSP
* Do not assess against other CMMC security requirements
|-
| colspan="4" | '''Assets that are not in the Level 2 CMMC Assessment Scope'''
|-
| '''Out-of-Scope Assets'''
|
* Assets that cannot process, store, or transmit CUI; and do not provide security protections for CUIassets
* Assets that are physically or logically separated from CUI assets
* Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset
* An endpoint hosting a VDI client configured to not allow any processing, storage, or transmission of CUI beyond the Keyboard/Video/Mouse sent to the VDI client is considered an Out-of-Scope Asset
|
* Prepare to justify the inability of an Out-of-Scope Asset to store, process, or transmit CUI
|
* None
|}

== Additional Guidance on Level 2 Scoping ==
The OSA is required to document all asset categories that are part of the Level 2 self-assessment or certification assessment in an asset inventory and provide a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities.

=== CUI Assets ===
CUI Assets process, store, or transmit CUI as follows:
* '''Process''' – CUI can be used by an asset (e.g., accessed, entered, edited, generated, manipulated, or printed).
* '''Store''' – CUI is inactive or at rest on an asset (e.g., located on electronic media, in system component memory, or in physical format such as paper documents).
* '''Transmit''' – CUI is being transferred from one asset to another asset (e.g., data in transit using physical or digital transport methods).

CUI Assets are part of the CMMC Assessment Scope and are assessed against all CMMC requirements.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the System Security Plan (SSP);
* document the treatment of these assets in the SSP;
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Security Protection Assets/Security Protection Data ===
Security Protection Assets provide security functions or capabilities within the OSA’s CMMC Assessment Scope.

Security Protection Assets are part of the CMMC Assessment Scope and are assessed against Level 2 security requirements that are relevant to the capabilities provided.For example, an External Service Provider (ESP), defined in 32 CFR §170.4, that provides a security information and event management (SIEM) service may be separated logically and may not process CUI, but the SIEM does contribute to meeting the CMMC requirements within the OSA’s CMMC Assessment Scope. Table 2 provides examples of Security Protection Assets.

Security Protection Data means data stored or processed by Security Protection Assets that are used to protect an OSA's assessed environment.

Security Protection Data is security-relevant information which, if disclosed, could aid an attacker in the compromise of the system.It includes, but is not limited to:
* configuration data required to operate a security protection asset,
* log files generated by or ingested by a security protection asset,
* data related to the configuration or vulnerability status of in-scope assets, and
* passwords that grant access to the in-scope environment.

{| class="wikitable" style="margin:auto"
|+ '''Table 2. Security Protection Asset Examples'''
|-
! Asset Type !! Security Protection Asset Examples
|-
| '''People'''
|
* Consultants who provide cybersecurity services
* Managed service provider personnel who implement system maintenance
* Enterprise network administrators
|-
|
'''Technology'''
|
* Cloud-based security solutions
* Hosted Virtual Private Network (VPN) services
* SIEM solutions
|-
|
'''Facilities'''
|
* Co-located data centers
* Security Operations Centers (SOCs)
* OSC office buildings
|}

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

=== Contractor Risk Managed Assets ===
Contractor Risk Managed Assets are not intended to, but are capable of processing, storing, or transmitting CUI because of the security policy, procedures, and practices in place. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

Contractor Risk Managed Assets are part of the Level 2 CMMC Assessment Scope. These assets are managed using the OSA’s risk-based information security policy, procedures, and practices. Furthermore, the assets must be assessed against CMMC requirements if insufficiently documented in the SSP or if the OSA’s risk-based security policies, procedures, and practices documentation or other findings raise questions about these assets.In these cases, the assessor can conduct a limited check to identify deficiencies.

In addition, the OSA is required to:
* document each asset in an asset inventory; there is no requirement to embed each asset in the SSP;
* document the treatment of these assets in the SSP; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

Assessment requirements for Contractor Risk Managed Asset are detailed in Table 1.

=== Specialized Assets ===
The following are considered Specialized Assets for a Level 2 assessment when documented in accordance with Table 1 (reprinted from 32 CFR § 170.19(c)(1) Table 3). Note that a Specialized Asset may be eligible for an Enduring Exception.

* '''Government Furnished Equipment (GFE)''' is all equipment owned or leased by the government and includes OSA-acquired equipment that is based on government required specifications and/or configurations. Government Furnished Equipment does not include intellectual property or software [Reference: Federal Acquisition Regulation (FAR) 52.245-1].
* '''Internet of Things (IoT) or Industrial Internet of Things (IIoT)''' means the network of devices that contain the hardware, software, firmware, and actuators which allow the devices to connect, interact, and freely exchange data and information, as defined in NIST SP 800-172A. They are interconnected devices having physical or virtual representation in the digital world, sensing/actuation capability, and programmability features. They are uniquely identifiable and may include smart electric grids, lighting, heating, air conditioning, and fire and smoke detectors.
* '''Operational Technology (OT)'''<ref>OT includes hardware and software that use direct monitoring and control of industrial equipment to detect or cause a change.</ref> means programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems or devices detect or cause a direct change through the monitoring or control of devices, processes, and events. Examples include industrial control systems, building management systems, fire control systems, and physical access control mechanisms. [Source: as defined in NIST SP 800-160v2 Rev 1 (incorporated by reference, see 32 CFR § 170.2.)]. NOTE: Operational Technology (OT) specifically includes Supervisory Control and Data Acquisition (SCADA); this is a rapidly evolving field. [Source: DRAFT, NIST SP 800-82r3] is used in manufacturing systems, industrial control systems (ICS), or supervisory control and data acquisition (SCADA) systems.
* '''Restricted Information Systems''' means systems [and associated Information Technology (IT) components comprising the system] that are configured based on government security requirements (i.e., connected to something that was required to support a functional requirement) and are used to support a contract (e.g., fielded systems, obsolete systems, and product deliverable replicas).
* '''Test Equipment''' means hardware and/or associated IT components used in the testing of products, system components, and contract deliverables. It can include hardware and/or associated IT components used in the testing of products, system components, and contract deliverables (e.g., oscilloscopes, spectrum analyzers, power meters, and special test equipment).

Specialized Assets are part of the CMMC Assessment Scope.In accordance with 32 CFR § 170.19(c)(1) Table 3, the OSA shall document these assets in the SSP and detail how they are managed using the OSA’s risk-based information security policy, procedures, and practices.

In addition, the OSA is required to:
* document each asset in asset inventory; there is no requirement to embed every asset in the SSP;
* document these assets in the SSP to show they are managed using the OSA’s risk-based security policies, procedures, and practices; and
* provide a network diagram of the CMMC Assessment Scope (to include these assets) to facilitate scoping discussions during the pre-assessment.

An assessor will review the SSP to verify that specialized assets are managed using the OSA’s risk-based information security policy, procedures, and practices, and accounted for within the OSA’s CMMC Assessment Scope.The assessor will not retain a copy of the SSP.

=== Out-of-Scope Assets ===
Out-of-Scope Assets cannot process, store, or transmit CUI, and do not provide security protections for CUI Assets. Assets that are physically or logically separated from CUI Assets and do not provide security protections for CUI Assets are also Out-of-Scope Assets. Assets that fall into any in-scope asset category cannot be considered an Out-of-Scope Asset.

In accordance with 32 CFR § 170.19(c)(1), Out-of-Scope Assets are not part of a Level 2 self-assessment or certification assessment.There are no documentation requirements for Out-of-Scope Assets.

=== Defining the CMMC Assessment Scope ===
After categorizing its assets, the OSA then specifies the CMMC Assessment Scope.

The CMMC Assessment Scope includes all assets in the OSA’s environment that will be assessed in accordance with Table 1. OSAs will be required to provide documentation that specifies the CMMC Assessment Scope to the assessor.Details about required documentation for each asset category can be found in the [[Level_2_Scoping_Guidance#CMMC Asset Categories|CMMC Asset Categories]] section above.

The following asset categories are part of the Level 2 CMMC Assessment Scope:
* CUI Assets
* Security Protection Assets
* Contractor Risk Managed Assets
* Specialized Assets

=== Separation Techniques ===
Separation is a system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI. Effective separation involves logically or physically separating assets and is required only for Out-of-Scope Assets.By separating assets, the CMMC Assessment Scope can be limited. Effective separation for CMMC follows the guidance in NIST SP 800-171 Rev 2, which states:

''If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms).Security domains may employ physical separation, logical separation, or a combination of both.This approach can provide adequate security for the CUI and avoid increasing the organization’s security posture to a level beyond that which it requires for protecting its missions, operations, and assets.''

'''Logical separation''' occurs when data transfer between physically connected assets (wired or wireless) is prevented by non-physical means such as software or network assets (e.g., firewall, routers, VPNs, VLANs).

'''Physical separation''' occurs when assets have no connection (wired or wireless). Data can only be transferred manually (e.g., USB drive).

Self-assessments and certification assessments may be valid for a defined CMMC Assessment Scope as outlined in 32 CFR § 170.19 CMMC Scoping.A new assessment is required if there are significant architectural or boundary changes to the previous CMMC Assessment Scope. Examples include, but are not limited to, expansions of networks or mergers and acquisitions. Operational changes within a CMMC Assessment Scope, such as adding or subtracting resources within the existing assessment boundary that follow the existing SSP, do not require a new assessment, but rather may be covered by annual affirmations to the continuing compliance with requirements.

=== External Service Provider Considerations ===
An External Service Provider (ESP) can be within the OSA’s scope of CMMC requirements if it meets CUI Asset and/or Security Protection Asset criteria. '''To be considered an ESP, data (specifically CUI or Security Protection Data, e.g., log data, configuration data) must reside on the ESP assets''' as set forth in 32 CFR § 170.19(c)(2). Special considerations for an OSA using an ESP include the following:
* The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA’s SSP and described in the ESP’s service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
* Evaluate the ESP’s CRM where the provider identifies security requirement objectives that are the provider’s responsibility and security requirement objectives that are the OSA’s responsibility.
* Consider the agreements in place with the ESP, such as service-level agreements, memoranda of understanding, and contracts that support the OSA’s information security objectives.
* ESPs that are CSPs,
** and store, process, or transmit CUI, must meet the FedRAMP requirements in DFARS clause 252.204-7012.
** and do NOT store, process, or transmit CUI, are not required to meet FedRAMP requirements in DFARS clause 252.204-7012.Services provided by an ESP are in the OSA’s assessment scope.
* ESPs that are not a CSP,
** and store, process, or transmit CUI, require assessment. The ESP services used to meet OSA requirements are within the scope of the OSA’s CMMC assessment.
** and do NOT store, process, or transmit CUI, do not require their own CMMC assessment. Services provided by an ESP are in the OSA’s assessment scope.
** may voluntarily request a C3PAO assessment, and a C3PAO may conduct such an assessment, if the ESP makes that business decision.
* OSAs shall also be assessed at Level 2, as applicable, against their on-premise infrastructure connecting to the CSP.As part of the CMMC Assessment Scope, the security requirements from the CRM must be documented or referred to in the OSA’s SSP, which will also be assessed.
* ESPs can be part of the same corporate/organizational structure but still be external to the OSA such as a centralized SOC or NOC which supports multiple business units. The same requirements apply and are based on whether or not the ESP provides cloud services and whether or not the ESP processes, stores, or transmits CUI on their systems.
* An ESP that is used as staff augmentation and the OSA provides all processes, technology, and facilities does not need CMMC assessment.
* When ESPs are assessed as part of an OSAs assessment, the type of the assessment is dictated by the OSA's DoD solicitation and contract requirement.

Cloud Service Provider (CSP) means an external company that provides cloud services based on cloud computing. Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction .An ESP would be considered a CSP when it provides its own cloud services based on a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing that can be rapidly provisioned and released with minimal management effort or service provider interaction.

An ESP (not a CSP) that provides technical support services to its clients would be considered a Managed Service Provider. It does not host its own cloud platform offering. An ESP may utilize cloud offerings to deliver services to clients without being a CSP.

An ESP that manages a third-party cloud service on behalf of an OSA would not be considered a CSP.

Not all companies that provide services to an OSA should be considered an ESP. Cloud based services such as human resource and accounting SaaS applications typically do not contribute to the security of the OSA’s environment; process or store SPD; or process, store, or transmit CUI. The OSA must determine if the company providing the service should be considered an ESP based on the services provided and if CUI is processed, stored, or transmitted.

=== Use Cases ===
'''FCI and CUI in the Same Assessment Scope'''

A Level 2 self-assessment or Level 2 certification assessment satisfies the Level 1 self-assessment requirements for the same CMMC Assessment Scope.If FCI is processed, stored, or transmitted within the same scope as CUI in the Level 2 scope, then the methods to implement the Level 2 security requirements apply towards meeting the Level 1 assessment objectives. The OSA is responsible for ensuring that only authorized users and processes have access to data regardless of its designation.

'''FCI and CUI in Different Assessment Scopes'''

If FCI and CUI do not share an environment, the two assessments would be conducted independently and methods to implement security requirements in one scope would not apply to the other scope.

'''Use of Enclaves'''

Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise.This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope.For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool.Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope.

Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way.

There is no established metric for inherited implementations from an enterprise to any defined enclaves.The OSA determines the architecture that best meets its business needs and complies with CMMC requirements.

'''Security Protection Data'''

Security Protection Data (SPD) can be created by or used by a Security Protection Asset (SPA).Aggregated logs in a SIEM are one example of SPD and the SIEM is considered the SPA. The SIEM is part of the assessment scope.Because of the wide range of SIEM tools available, (on-premise hardware appliance; on-premise virtual appliance; or cloud based), methods of assessing the SIEM will also vary. If the SIEM and/or associated log data is hosted or maintained by an ESP, then the portion of the ESP that is used to provide the SIEM service or log storage is part of the OSA’s assessment scope.SIEM logs are typically available in hot storage for some period of time as part of the SIEM deployment.In this case, the SPD is collocated with the SPA.Cold storage of logs for a longer period of time is typically done offline or in cloud storage.The method used and the location of the cold storage are also in the OSA’s assessment scope.

== Notes ==
<references />

Main Page

2025-05-21T14:02:00Z

David: /* Site Update Notices */

'''This website contains information about the Cybersecurity Maturity Model Certification (CMMC) program of the U.S. Department of Defense (DoD).

The wiki aims to provide educational references for those who are interested in learning more about the framework.'''

Primary Source of Reference: The official [https://dodcio.defense.gov/CMMC/ CMMC Home Page] from the Department of Defense Chief Information Officer (DoD CIO).

Additional References: The [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Resources & Documentation] page contains a variety of links to CMMC resources throughout the DoD.

Basic information on FedRAMP and Cybersecurity Framework are also available on this website. Select one of the menu items on the Sidebar.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Site Update Notices ==
The CMMCWiki site is currently undergoing a comprehensive update to align with the latest content on the official CMMC website. For the most up-to-date information on our progress and recent changes, please refer to the following table.

{| class="wikitable" style="margin:auto"
|+ Update Status as of March 27, 2025
|-
! Page Name !! Status
|-
| Model Overview || Update completed on March 16, 2025
|-
| 32 CFR Part 170 Rule || Update completed on March 3, 2025
|-
| Level 1 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 1 Self-Assessment Guide || Update completed on March 16, 2025
|-
| Level 2 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 2 Assessment Guide || Update completed on March 20, 2025
|-
| Level 3 Scoping Guidance || Update completed on February 24, 2025
|-
| Level 3 Assessment Guide || Update completed on March 27, 2025
|-
| CMMC Hashing Guide || Update completed on March 16, 2025
|-
| CMMC Assessment Process (CAP) by CyberAB || Update completed on February 24, 2025
|-
| DoD Assessment Methodology || Update completed on March 18, 2025
|-
| 110 L1 & L2 Security Requirements || Update completed on March 16, 2025
|-
| 24 L3 Security Requirements || Update completed on March 27, 2025
|-
| Commonly Accepted & Practiced CMMC Operation Matrix || Under Construction
|-
| FedRAMP Information || Update Pending
|-
| Cybersecurity Framework Information || Update Pending
|}

Main Page

2025-05-21T14:01:42Z

David: /* Site Update Notices */

'''This website contains information about the Cybersecurity Maturity Model Certification (CMMC) program of the U.S. Department of Defense (DoD).

The wiki aims to provide educational references for those who are interested in learning more about the framework.'''

Primary Source of Reference: The official [https://dodcio.defense.gov/CMMC/ CMMC Home Page] from the Department of Defense Chief Information Officer (DoD CIO).

Additional References: The [https://dodcio.defense.gov/cmmc/Resources-Documentation/ CMMC Resources & Documentation] page contains a variety of links to CMMC resources throughout the DoD.

Basic information on FedRAMP and Cybersecurity Framework are also available on this website. Select one of the menu items on the Sidebar.

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== Site Update Notices ==
The CMMCWiki site is currently undergoing a comprehensive update to align with the latest content on the official CMMC website. For the most up-to-date information on our progress and recent changes, please refer to the following table.

{| class="wikitable" style="margin:auto"
|+ Update Status as of March 27, 2025
|-
! Page Name !! Status
|-
| Model Overview || Update completed on March 16, 2025
|-
| 32 CFR Part 170 Rule || Update completed on March 3, 2025
|-
| Level 1 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 1 Self-Assessment Guide || Update completed on March 16, 2025
|-
| Level 2 Scoping Guidance || Update completed on February 25, 2025
|-
| Level 2 Assessment Guide || Update completed on March 20, 2025
|-
| Level 3 Scoping Guidance || Update completed on February 24, 2025
|-
| Level 3 Assessment Guide || Update completed on March 27, 2025
|-
| CMMC Hashing Guide || Update completed on March 16, 2025
|-
| CMMC Assessment Process (CAP) by CyberAB || Update completed on February 24, 2025
|-
| DoD Assessment Methodology || Update completed on March 18, 2025
|-
| 110 L1 & L2 Security Requirements || Update completed on March 16, 2025
|-
| 24 L3 Security Requirements || Update completed on March 27, 2025
|-
| Commonly Accepted & Practiced CMMC Operation Matrix || Under Revision
|-
| FedRAMP Information || Update Pending
|-
| Cybersecurity Framework Information || Update Pending
|}

Level 2 Assessment Guide

2025-05-14T16:02:08Z

David: /* AT.L2-3.2.2 – Role-Based Training */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified and [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is
prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Level 2 Assessment Guide

2025-05-13T22:48:23Z

David: /* SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified and [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is
prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

Level 2 Assessment Guide

2025-05-10T00:35:10Z

David: /* CA.L2-3.12.4 – System Security Plan = */

'''Source of Reference: The official [https://dodcio.defense.gov/CMMC/Resources-Documentation/ CMMC Level 2 Assessment Guide Version 2.13, September 2024] from the Department of Defense Chief Information Officer (DoD CIO).'''

For inquiries and reporting errors on this wiki, please [mailto:support@cmmctoolkit.org contact us]. Thank you.

== NOTICES ==
The contents of this document do not have the force and effect of law and are not meant to bind the public in any way. This document is intended only to provide clarity to the public regarding existing requirements under the law or departmental policies.

DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited.

== Introduction ==
This document provides guidance in the preparation for and conduct of a Level 2 self-assessment or Level 2 certification assessment under the Cybersecurity Maturity Model Certification (CMMC) Program as set forth in section 170.16 of title 32, Code of Federal Regulations (CFR) and 32 CFR § 170.17 respectively. Certification at each CMMC level occurs independently. Guidance for conducting a Level 1 self-assessment can be found in ''CMMC Assessment Guide – Level 1''. Guidance for conducting a Level 3 certification assessment can be found in ''CMMC'' ''Assessment Guide – Level 3''. More details on the model can be found in the ''CMMC Model Overview'' document.

An ''Assessment'' as defined in 32 CFR § 170.4 means ''the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization as defined in 32 CFR § 170.15 to 32 CFR § 170.18''.

For Level 2 there are two types of assessments:
* A ''self-assessment'' is the term for the activity performed by an entity to evaluate its own CMMC Level, as applied to Level 1 and some Level 2.
* A ''Level 2 certification assessment'' is the term for the activity performed by a Certified Third-Party Assessment Organization (C3PAO)to evaluate the CMMC level of an OSC.

32 CFR § 170.16(b) describes contract or subcontract eligibility for any contract with a Level 2 self-assessment requirement, and 32 CFR § 170.17(b) describes contract or subcontract eligibility for any contract with a Level 2 certification assessment requirement. Level 2 certification assessment requires the Organization Seeking Assessment (OSA) achieve the CMMC Status of either Conditional Level 2 (C3PAO) or Final Level 2 (C3PAO), as described in 32 § CFR 170.4, obtained through an assessment by an accredited C3PAO.

=== Level 2 Description ===
Level 2 incorporates the security requirements specified in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, ''Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations''.

Level 2 addresses the protection of Controlled Unclassified Information (CUI), as defined in 32 CFR § 2002.4(h):

: ''Information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. However, CUI does not include classified information (see paragraph (e) of this section) or information a non-executive branch entity possesses and maintains in its own systems that did not come from, or was not created or possessed by or for, an executive branch agency or an entity acting for an agency. Law, regulation, or Government-wide policy may require or permit safeguarding or dissemination controls in three ways: Requiring or permitting agencies to control or protect the information but providing no specific controls, which makes the information CUI Basic; requiring or permitting agencies to control or protect the information and providing specific controls for doing so, which makes the information CUI Specified; or requiring or permitting agencies to control the information and specifying only some of those controls, which makes the information CUI Specified, but with CUI Basic controls where the authority does not specify.''

Level 2 certification assessments provides increased assurance to the DoD that an OSA can adequately protect CUI at a level commensurate with the adversarial risk, including protecting information flow with subcontractors in a multi-tier supply chain.

=== Purpose and Audience ===
This guide is intended for assessors, OSAs, cybersecurity professionals, and individuals and companies that support CMMC efforts. This document can be used as part of preparation for and conducting a Level 2 self-assessment or a Level 2 certification assessment. The term Level 2 assessment encompasses both Level 2 self-assessment and Level 2 certification assessment.

=== Document Organization ===
This document is organized into the following sections:
* '''Assessment and Certification:''' provides an overview of the Level 2 self-assessment processes set forth in 32 CFR §170.16 as well as the Level 2 certification assessment processes set forth in 32 CFR § 170.17. It provides guidance regarding the scope requirements set forth in 32 CFR § 170.19(c).
* '''CMMC-Custom Terms:''' incorporates definitions from 32 CFR § 170.4 and definitions included by reference from 32 CFR § 170.2, and provides clarification of the intent and scope of custom terms as used in the context of CMMC.
* '''Assessment Criteria and Methodology:''' provides guidance on the criteria and methodology (i.e., ''interview'', ''examine'', and ''test'') to be employed during a Level 2 assessment, as well as on assessment findings.
* '''Requirement Descriptions:''' provides guidance specific to each Level 2 security requirement.

== Assessment and Certification ==
Certified Assessors as described in 32 CFR § 170.11 will use the assessment methods defined in NIST SP 800-171A<ref>NIST SP 800-171A, June 2018</ref>, ''Assessing Security Requirements for Controlled Unclassified Information'', along with the supplemental information in this guide, to conduct Level 2 certification assessments. Certified Assessors will review information and evidence to verify that an OSC meets the stated assessment objectives for all of the requirements.

An OSC can obtain a Level 2 certification assessment for an entire enterprise network or for a specific enclave(s), depending upon how the CMMC Assessment Scope is defined in accordance with 32 CFR § 170.19(c).

OSAs conducting self-assessments in accordance with 32 CFR § 170.16 are expected to evaluate their compliance with CMMC requirements using the same criteria established in NIST SP 800-171A and this assessment guide and used for third-party assessments.

=== Assessment Scope ===
The CMMC Assessment Scope must be specified prior to assessment in accordance with the requirements of 32 CFR § 170.19. The CMMC Assessment Scope is the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.

Because the scoping of a Level 2 certification assessment is not the same as the scoping of a Level 3 certification assessment, before determining the CMMC Assessment Scope it is important to first consider whether the goal is a Level 2 or Level 3 CMMC Status. If the intent is not to achieve a CMMC Status of Final Level 3 (DIBCAC) as defined in 32 CFR § 170.18, refer to the guidance provided in the ''CMMC Scoping Guide – Level 2'' document which summarizes 32 CFR § 170.19(c). If the intent is to achieve a CMMC Status of Final Level 3 (DIBCAC), refer to the guidance provided in the ''CMMC Scoping Guide – Level 3'' document which summarizes 32 CFR § 170.19(d). Both documents are available on the official CMMC documentation site at https://dodcio.defense.gov/CMMC/Documentation/.

== CMMC-Custom Terms ==
The CMMC Program has custom terms that align with program requirements. Although some terms may have other definitions in open forums, it is important to understand these terms as they apply to the CMMC Program.

The specific terms as associated with Level 2 are:
* '''Assessment:''' As defined in 32 CFR § 170.4 means the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization, as defined in 32 CFR § 170.15 to 32 CFR § 170.18.
** ''Level 2 self-assessment'' is the term for the activity performed by an OSA to evaluate its own information system when seeking a CMMC Status of Level 2 (Self).
** ''Level 2 certification assessment'' is the term for the activity performed by a C3PAO to evaluate the information system of an OSC when seeking a CMMC Status of Level 2 (C3PAO).
** ''POA&M closeout self-assessment'' is the term for the activity performed by an OSA to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (Self).
** ''POA&M closeout certification assessment'' is the term for the activity performed by a C3PAO or DCMA DIBCAC to evaluate only the NOT MET requirements that were identified with POA&M during the initial assessment, when seeking a CMMC Status of Final Level 2 (C3PAO) or Final Level 3 (DIBCAC) respectively.
* '''Assessment Objective:''' As defined in 32 CFR § 170.4 means a set of determination statements that, taken together, expresses the desired outcome for the assessment of a security requirement. Successful implementation of the corresponding CMMC security requirement requires meeting all applicable assessment objectives defined in NIST SP 800–171A or NIST SP 800-172A.
* '''Asset:''' An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns, as defined in NIST SP 800-160 Rev 1.
* '''CMMC Assessment Scope:''' As defined in 32 CFR § 170.4 means the set of all assets in the OSA’s environment that will be assessed against CMMC security requirements.
* '''CMMC Status:''' As defined in 32 CFR § 170.4 is the result of meeting or exceeding the minimum required score for the corresponding assessment. The CMMC Status of an OSA information system is officially stored in SPRS and additionally issued on a Certificate of CMMC Status, if the assessment was conducted by a C3PAO or DCMA DIBCAC.
** ''Conditional Level 2 (Self)'' is defined in § 170.16(a)(1)(ii). The OSA has conducted a Level 2 self-assessment, submitted compliance results in the Supplier Performance Risk System (SPRS), and created a CMMC POA&M that meets all CMMC POA&M requirements listed in 32 CFR §170.16(a)(1)(ii).
** ''Final Level 2 (Self)'' is defined in § 170.16(a)(1)(iii). The OSA will achieve a CMMC Status of Final Level 2 (Self) for the information system(s) within the CMMC Assessment Scope upon implementation of all security requirements and close out of the POA&M, as applicable.
** ''Conditional Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(ii). The OSC will achieve a CMMC Status of Conditional Level 2 (C3PAO) if a POA&M exists upon completion of the assessment and the POA&M meets all Level 2 POA&M requirements listed in 32 CFR § 170.21(a)(2).
** ''Final Level 2 (C3PAO)'' is defined in § 170.17(a)(1)(iii). The OSC will achieve a CMMC Status of Final Level 2 (C3PAO) for the information systems within the CMMC Assessment Scope upon implementation of all security requirements and as applicable, a POA&M closeout assessment conducted by the C3PAO within 180 days. Additional guidance can be found in 32 CFR § 170.21.
* '''Component:''' A discrete identifiable information technology ''asset'' that represents a building block of a system and may include hardware, software, and firmware<ref>NIST SP 800-171 Rev 2, p 59 under system component</ref>. A ''component'' is one type of ''asset''.
* '''Enduring Exception:''' As defined in 32 CFR § 170.4 means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of ‘fielded’ systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be Enduring Exceptions.
* '''Event:''' Any observable occurrence in a system<ref>NIST SP 800-53 Rev. 5, p. 402</ref>. As described in NIST SP 800-171A<ref>NIST SP 800-171A, p. v</ref>, the terms “information system” and “system” can be used interchangeably. ''Events'' sometimes provide indication that an ''incident'' is occurring.
* '''Incident:''' An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.<ref>NIST SP 800-171 Rev. 2, Appendix B, p. 54 (adapted)</ref>
* '''Information System (IS):''' As defined in 32 CFR § 170.4 means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. An ''IS'' is one type of ''asset''.
* '''Monitoring:''' The act of continually checking, supervising, critically observing, or determining the status in order to identify change from the performance level required or expected at an ''organization-defined'' frequency and rate.<ref>NIST SP 800-160 Vol. 1 R1, Engineering Trustworthy Secure Systems, 2022, Appendix B., p. 55</ref>
* '''Operational plan of action:''' As used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies in implementation of requirements and documents how and when they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action is not the same as a POA&M associated with an assessment.
* '''Organization-defined:''' As determined by the OSA being assessed except as defined in the case of Organization-Defined Parameter (ODP). This can be applied to a frequency or rate at which something occurs within a given time period, or it could be associated with describing the configuration of an OSA’s solution.
* '''Periodically:''' Occurring at a regular interval as determined by the OSA that may not exceed one year. As used in many requirements within CMMC, the interval length is ''organization-defined'' to provide OSA flexibility, with an interval length of no more than one year.
* '''Security Protection Data (SPD):''' As defined in 32 CFR § 170.4 means data stored or processed by Security Protection Assets (SPA) that are used to protect an OSC's assessed environment. SPD is security relevant information and includes, but is not limited to: configuration data required to operate an SPA, log files generated by or ingested by an SPA, data related to the configuration or vulnerability status of in-scope assets, and passwords that grant access to the in-scope environment.
* '''System Security Plan (SSP):''' As defined in 32 CFR § 170.4 means the formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or planned for meeting those requirements. The system security plan describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems, as defined in NIST SP 800-53 Rev 5.
* '''Temporary deficiency:''' As defined in 32 CFR § 170.4 means a condition where remediation of a discovered deficiency is feasible and a known fix is available or is in process. The deficiency must be documented in an operational plan of action. A temporary deficiency is not based on an ‘in progress’ initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed. There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency.

== Assessment Criteria and Methodology ==
The ''CMMC Assessment Guide – Level 2'' leverages the assessment procedure described in NIST SP 800-171A Section 2.1<ref>NIST SP 800-171A, ''Assessing Security Requirements for Controlled Unclassified Information'', June 2018, pp. 4-5</ref>:
: ''An assessment procedure consists of an assessment objective and a set of potential assessment methods and assessment objects that can be used to conduct the assessment. Each assessment objective includes a determination statement related to the requirement that is the subject of the assessment. The determination statements are linked to the content of the requirement to ensure traceability of the assessment results to the requirements. The application of an assessment procedure to a requirement produces assessment findings. These findings reflect, or are subsequently used, to help determine if the requirement has been satisfied.

: Assessment objects identify the specific items being assessed and can include specifications, mechanisms, activities, and individuals.
: * ''Specifications are the document-based artifacts (e.g., policies, procedures, security plans, security requirements, functional specifications, architectural designs) associated with a system.''
: * ''Mechanisms are the specific hardware, software, or firmware safeguards employed within a system.''
: * ''Activities are the protection-related actions supporting a system that involve people (e.g., conducting system backup operations, exercising a contingency plan, and monitoring network traffic).''
: * ''Individuals, or groups of individuals, are people applying the specifications, mechanisms, or activities described above.''

: ''The assessment methods define the nature and the extent of the assessor’s actions. The methods include ''examine'', ''interview'', and ''test.
: * ''The ''examine'' method is the process of reviewing, inspecting, observing, studying, or analyzing assessment objects (i.e., specifications, mechanisms, activities). The purpose of the ''examine'' method is to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''The ''interview'' method is the process of holding discussions with individuals or groups of individuals to facilitate understanding, achieve clarification, or obtain evidence.''
: * ''And finally, the ''test'' method is the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior.''

: ''In all three assessment methods, the results are used in making specific determinations called for in the determination statements and thereby achieving the objectives for the assessment procedure.''

=== Criteria ===
Assessment objectives are provided for each requirement and are based on existing criteria from NIST SP 800-171A. The criteria are authoritative and provide a basis for the assessment of a requirement.

=== Methodology ===
To verify and validate that an OSA is meeting CMMC requirements, evidence needs to exist demonstrating that the OSA has fulfilled the objectives of the Level 2 requirements. Because different assessment objectives can be met in different ways (e.g., through documentation, computer configuration, network configuration, or training), a variety of techniques may be used to determine if the OSA meets the Level 2 requirements, including any of the three assessment methods from NIST SP 800-171A.

The assessor will follow the guidance in NIST SP 800-171A when determining which assessment methods to use:

: ''Organizations [Certified Assessors] are not expected to employ ''all'' assessment methods and objects contained within the assessment procedures identified in this publication. Rather, organizations [Certified Assessors] have the flexibility to determine the level of effort needed and the assurance required for an assessment (e.g., which assessment methods and assessment objects are deemed to be the most useful in obtaining the desired results). This determination is made based on how the organization [contractor] can accomplish the assessment objectives in the most cost-effective manner and with sufficient confidence to support the determination that the CUI requirements have been satisfied.<ref>NIST SP 800-171A, p. 5.</ref>''

The primary deliverable of an assessment is a compliance score and accompanying report that contains the findings associated with each requirement. For more detailed information on assessment methods, see Appendix D of NIST SP 800-171A, incorporated by reference per 32 CFR § 170.2.

==== Who Is Interviewed ====
Interviews of applicable staff (possibly at different organizational levels) may provide information to help an assessor determine if security requirements have been implemented, as well as if adequate resourcing, training, and planning have occurred for individuals to perform the requirements.

==== What Is Examined ====
Examination includes reviewing, inspecting, observing, studying, or analyzing assessment objects. The objects can be documents, mechanisms, or activities.

For some security requirements, review of documentation may assist assessors in determining if the assessment objectives have been met. Interviews with staff may help identify relevant documents. Documents need to be in their final forms; drafts of policies or documentation are not eligible to be used as evidence because they are not yet official and still subject to change. Common types of documents that may be used as evidence include:
* policy, process, and procedure documents;
* training materials;
* plans and planning documents; and
* system, network, and data flow diagrams.

This list of documents is not exhaustive or prescriptive. An OSA may not have these specific documents, and other documents may be reviewed.
In other cases, the security requirement is best self-assessed by observing that safeguards are in place by viewing hardware, associated configuration information, or observing staff following a process.

==== What Is Tested ====
Testing is an important part of the self-assessment process. Interviews provide information about what the OSA staff believe to be true, documentation provides evidence of implementing policies and procedures, and testing demonstrates what has or has not been done. For example, OSA staff may talk about how users are identified, documentation may provide details on how users are identified, but seeing a demonstration of identifying users provides evidence that the requirement is met. The assessor will determine which requirements or objectives within a requirement need demonstration or testing. Most objectives will require testing.

=== Assessment Findings ===
The assessment of a CMMC requirement results in one of three possible findings: MET, NOT MET, or NOT APPLICABLE as defined in 32 CFR § 170.24. To achieve a Final Level 2 (Self) or Final Level 2 (C3PAO) CMMC Status, the OSA will need a finding of MET or NOT APPLICABLE on all Level 2 security requirements.
* '''MET''': All applicable assessment objectives for the security requirement are satisfied based on evidence. All evidence must be in final form and not draft. Unacceptable forms of evidence include working papers, drafts, and unofficial or unapproved policies. For each security requirement marked MET, it is best practice to record statements that indicate the response conforms to all objectives and document the appropriate evidence to support the response.
** Enduring Exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
** Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews, milestones, and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.
* '''NOT MET''': One or more objectives for the security requirement is not satisfied. For each security requirement marked NOT MET, it is best practice to record statements that explain why and document the appropriate evidence showing that the OSA does not conform fully to all of the objectives. During Level 2 certification assessments, for each requirement objective marked NOT MET, the assessor will document why the evidence does not conform.
* '''NOT APPLICABLE (N/A)''': A security requirement and/or objective does not apply at the time of the assessment. For each security requirement marked N/A, it is best practice to record a statement that explains why the requirement does not apply to the OSA. For example, Public-Access System Separation (SC.L2-3.13.5) might be N/A if there are no publicly accessible systems within the CMMC Assessment Scope. During an assessment, an assessment objective assessed as N/A is equivalent to the same assessment objective being assessed as MET.
: If an OSC previously received a favorable adjudication from the DoD CIO indicating that a requirement is not applicable or that an alternative security measure is equally effective, the DoD CIO adjudication must be included in the system security plan to receive consideration during an assessment. Implemented security measures adjudicated by the DoD CIO as equally effective are assessed as MET if there have been no changes in the environment.
: Each assessment objective in NIST SP 800-171A must yield a finding of MET or NOT APPLICABLE in order for the overall security requirement to be scored as MET. Assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding.
: CMMC assessments are conducted and results are captured at the assessment objective level. One NOT MET assessment objective results in a failure of the entire security requirement.
: A security requirement can be applicable even when assessment objectives included in the security requirement are scored as N/A. The security requirement is NOT MET when one or more applicable assessment objectives is NOT MET.
: Satisfaction of security requirements may be accomplished by other parts of the enterprise or an External Service Provider (ESP), as defined in 32 CFR § 170.4. A security requirement is considered MET if adequate evidence is provided that the enterprise or External Service Provider (ESP), implements the requirement objectives. An ESP may be external people, technology, or facilities that the OSA uses, including cloud service providers, managed service providers, managed security service providers, or cybersecurity-as-a-service providers.

== Requirement Descriptions ==
=== Introduction ===
This section provides detailed information and guidance for assessing each Level 2 security requirement. The section is organized first by domain and then by individual security requirement. Each requirement description contains the following elements as described in 32 CFR § 170.14(c):
* '''Requirement Number, Name, and Statement:''' Headed by the requirement identification number in the format, DD.L#-REQ (e.g., AC.L2-3.1.1); followed by the requirement short name identifier, meant to be used for quick reference only; and finally followed by the complete CMMC security requirement statement.
* '''Assessment Objectives [NIST SP 800-171A]:''' Identifies the specific set of objectives that must be met to receive MET for the requirement as defined in NIST SP 800-171A.<ref>NIST SP 800-171A, p. 4.</ref>
* '''Potential Assessment Methods and Objects [NIST SP 800-171A]:''' Describes the nature and the extent of the assessment actions as set forth in NIST SP 800-171A. The methods include ''examine'', ''interview'', and ''test''. Assessment objects identify the items being assessed and can include specifications, mechanisms, activities, and individuals.<ref>NIST SP 800-171A, pp. 4-5.</ref>
* '''Discussion [NIST SP 800-171 Rev. 2]:''' Contains discussion from the associated NIST SP 800-171 security requirement.
* '''Further Discussion:'''
** Expands upon the NIST SP 800-171 Rev. 2 discussion content to provide additional guidance.
** Contains examples illustrating application of the requirements. These examples are intended to provide insight but are not prescriptive of how the requirement must be implemented, nor are they comprehensive of all assessment objectives necessary to achieve the requirement. The assessment objectives met within the example are referenced by letter in a bracket (e.g., [a, d] for objectives “a” and “d”) within the text.
** Examples are written from the perspective of an organization or an employee of an organization implementing solutions or researching approaches to satisfy CMMC requirements. The objective is to put the reader into the role of implementing or maintaining alternatives to satisfy security requirements. Examples are not all-inclusive or prescriptive and do not imply any personal responsibility for complying with CMMC requirements.
** Provides potential assessment considerations. These may include common considerations for assessing the requirement and potential questions that may be asked when assessing the objectives.
* '''Key References:''' Lists the basic safeguarding requirement from NIST SP 800-171 Rev. 2.

== Access Control (AC) ==
=== AC.L2-3.1.1 – Authorized Access Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized users are identified;
: [b] processes acting on behalf of authorized users are identified;
: [c] devices (and other systems) authorized to connect to the system are identified;
: [d] system access is limited to authorized users;
: [e] system access is limited to processes acting on behalf of authorized users; and
: [f] system access is limited to authorized devices (including other systems).
|-
|[[Practice_AC.L2-3.1.1_Details|More Practice Details...]]
|}

=== AC.L2-3.1.2 – Transaction & Function Control [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the types of transactions and functions that authorized users are permitted to execute are defined; and
: [b] system access is limited to the defined types of transactions and functions for authorized users.
|-
|[[Practice_AC.L2-3.1.2_Details|More Practice Details...]]
|}

=== AC.L2-3.1.3 – Control CUI Flow ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the flow of CUI in accordance with approved authorizations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information flow control policies are defined;
: [b] methods and enforcement mechanisms for controlling the flow of CUI are defined;
: [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified;
: [d] authorizations for controlling the flow of CUI are defined; and
: [e] approved authorizations for controlling the flow of CUI are enforced.
|-
|[[Practice_AC.L2-3.1.3_Details|More Practice Details...]]
|}

=== AC.L2-3.1.4 – Separation of Duties ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the duties of individuals requiring separation are defined;
: [b] responsibilities for duties that require separation are assigned to separate individuals; and
: [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.
|-
|[[Practice_AC.L2-3.1.4_Details|More Practice Details...]]
|}

=== AC.L2-3.1.5 – Least Privilege ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least privilege, including for specific security functions and privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] access to privileged accounts is authorized in accordance with the principle of least privilege;
: [c] security functions are identified; and
: [d] access to security functions is authorized in accordance with the principle of least privilege.
|-
|[[Practice_AC.L2-3.1.5_Details|More Practice Details...]]
|}

=== AC.L2-3.1.6 – Non-Privileged Account Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] nonsecurity functions are identified; and
: [b] users are required to use non-privileged accounts or roles when accessing nonsecurity functions.
|-
|[[Practice_AC.L2-3.1.6_Details|More Practice Details...]]
|}

=== AC.L2-3.1.7 – Privileged Functions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged functions are defined;
: [b] non-privileged users are defined;
: [c] non-privileged users are prevented from executing privileged functions; and
: [d] the execution of privileged functions is captured in audit logs.
|-
|[[Practice_AC.L2-3.1.7_Details|More Practice Details...]]
|}

=== AC.L2-3.1.8 – Unsuccessful Logon Attempts ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit unsuccessful logon attempts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the means of limiting unsuccessful logon attempts is defined; and
: [b] the defined means of limiting unsuccessful logon attempts is implemented.
|-
|[[Practice_AC.L2-3.1.8_Details|More Practice Details...]]
|}

=== AC.L2-3.1.9 – Privacy & Security Notices ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide privacy and security notices consistent with applicable CUI rules.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category; and
: [b] privacy and security notices are displayed.
|-
|[[Practice_AC.L2-3.1.9_Details|More Practice Details...]]
|}

=== AC.L2-3.1.10 – Session Lock ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the period of inactivity after which the system initiates a session lock is defined;
: [b] access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity; and
: [c] previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.
|-
|[[Practice_AC.L2-3.1.10_Details|More Practice Details...]]
|}

=== AC.L2-3.1.11 – Session Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate (automatically) a user session after a defined condition.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] conditions requiring a user session to terminate are defined; and
: [b] a user session is automatically terminated after any of the defined conditions
|-
|[[Practice_AC.L2-3.1.11_Details|More Practice Details...]]
|}

=== AC.L2-3.1.12 – Control Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor and control remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote access sessions are permitted;
: [b] the types of permitted remote access are identified;
: [c] remote access sessions are controlled; and
: [d] remote access sessions are monitored.
|-
|[[Practice_AC.L2-3.1.12_Details|More Practice Details...]]
|}

=== AC.L2-3.1.13 – Remote Access Confidentiality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms to protect the confidentiality of remote access sessions are identified; and
: [b] cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.
|-
|[[Practice_AC.L2-3.1.13_Details|More Practice Details...]]
|}

=== AC.L2-3.1.14 – Remote Access Routing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Route remote access via managed access control points.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] managed access control points are identified and implemented; and
: [b] remote access is routed through managed network access control points.
|-
|[[Practice_AC.L2-3.1.14_Details|More Practice Details...]]
|}

=== AC.L2-3.1.15 – Privileged Remote Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize remote execution of privileged commands and remote access to security-relevant information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged commands authorized for remote execution are identified;
: [b] security-relevant information authorized to be accessed remotely is identified;
: [c] the execution of the identified privileged commands via remote access is authorized; and
: [d] access to the identified security-relevant information via remote access is authorized.
|-
|[[Practice_AC.L2-3.1.15_Details|More Practice Details...]]
|}

=== AC.L2-3.1.16 – Wireless Access Authorization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authorize wireless access prior to allowing such connections.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access points are identified; and
: [b] wireless access is authorized prior to allowing such connections.
|-
|[[Practice_AC.L2-3.1.16_Details|More Practice Details...]]
|}

=== AC.L2-3.1.17 – Wireless Access Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect wireless access using authentication and encryption.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] wireless access to the system is protected using authentication; and
: [b] wireless access to the system is protected using encryption.
|-
|[[Practice_AC.L2-3.1.17_Details|More Practice Details...]]
|}

=== AC.L2-3.1.18 – Mobile Device Connection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control connection of mobile devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices that process, store, or transmit CUI are identified;
: [b] mobile device connections are authorized; and
: [c] mobile device connections are monitored and logged.
|-
|[[Practice_AC.L2-3.1.18_Details|More Practice Details...]]
|}

=== AC.L2-3.1.19 – Encrypt CUI on Mobile ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Encrypt CUI on mobile devices and mobile computing platforms.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] mobile devices and mobile computing platforms that process, store, or transmit CUI are identified; and
: [b] encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.
|-
|[[Practice_AC.L2-3.1.19_Details|More Practice Details...]]
|}

=== AC.L2-3.1.20 – External Connections [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Verify and control/limit connections to and use of external information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] connections to external systems are identified;
: [b] the use of external systems is identified;
: [c] connections to external systems are verified;
: [d] the use of external systems is verified;
: [e] connections to external systems are controlled/limited; and
: [f] the use of external systems is controlled/limited.
|-
|[[Practice_AC.L2-3.1.20_Details|More Practice Details...]]
|}

=== AC.L2-3.1.21 – Portable Storage Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit use of portable storage devices on external systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices containing CUI on external systems is identified and documented;
: [b] limits on the use of portable storage devices containing CUI on external systems are defined; and
: [c] the use of portable storage devices containing CUI on external systems is limited as defined.
|-
|[[Practice_AC.L2-3.1.21_Details|More Practice Details...]]
|}

=== AC.L2-3.1.22 – Control Public Information [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control information posted or processed on publicly accessible information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals authorized to post or process information on publicly accessible systems are identified;
: [b] procedures to ensure CUI is not posted or processed on publicly accessible systems are identified;
: [c] a review process is in place prior to posting of any content to publicly accessible systems;
: [d] content on publicly accessible systems is reviewed to ensure that it does not include CUI; and
: [e] mechanisms are in place to remove and address improper posting of CUI.
|-
|[[Practice_AC.L2-3.1.22_Details|More Practice Details...]]
|}

== Awareness and Training (AT) ==
=== AT.L2-3.2.1 – Role-Based Risk Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security risks associated with organizational activities involving CUI are identified;
: [b] policies, standards, and procedures related to the security of the system are identified;
: [c] managers, systems administrators, and users of the system are made aware of the security risks associated with their activities; and
: [d] managers, systems administrators, and users of the system are made aware of the applicable policies, standards, and procedures related to the security of the system.
|-
|[[Practice_AT.L2-3.2.1_Details|More Practice Details...]]
|}

=== AT.L2-3.2.2 – Role-Based Training ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.|-
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] information security-related duties, roles, and responsibilities are defined;
: [b] information security-related duties, roles, and responsibilities are assigned to designated personnel; and
: [c] personnel are adequately trained to carry out their assigned information security-related duties, roles, and responsibilities.
|-
|[[Practice_AT.L2-3.2.2_Details|More Practice Details...]]
|}

=== AT.L2-3.2.3 – Insider Threat Awareness ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide security awareness training on recognizing and reporting potential indicators of insider threat.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] potential indicators associated with insider threats are identified; and
: [b] security awareness training on recognizing and reporting potential indicators of insider threat is provided to managers and employees.
|-
|[[Practice_AT.L2-3.2.3_Details|More Practice Details...]]
|}

== Audit and Accountability (AU) ==
=== AU.L2-3.3.1 – System Auditing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs needed (i.e., event types to be logged) to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;
: [b] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;
: [c] audit records are created (generated);
: [d] audit records, once created, contain the defined content;
: [e] retention requirements for audit records are defined; and
: [f] audit records are retained as defined.
|-
|[[Practice_AU.L2-3.3.1_Details|More Practice Details...]]
|}

=== AU.L2-3.3.2 – User Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
: [b] audit records, once created, contain the defined content.
|-
|[[Practice_AU.L2-3.3.2_Details|More Practice Details...]]
|}

=== AU.L2-3.3.3 – Event Review ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Review and update logged events.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a process for determining when to review logged events is defined;
: [b] event types being logged are reviewed in accordance with the defined review process; and
: [c] event types being logged are updated based on the review.
|-
|[[Practice_AU.L2-3.3.3_Details|More Practice Details...]]
|}

=== AU.L2-3.3.4 – Audit Failure Alerting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Alert in the event of an audit logging process failure.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] personnel or roles to be alerted in the event of an audit logging process failure are identified;
: [b] types of audit logging process failures for which alert will be generated are defined; and
: [c] identified personnel or roles are alerted in the event of an audit logging process failure.
|-
|[[Practice_AU.L2-3.3.4_Details|More Practice Details...]]
|}

=== AU.L2-3.3.5 – Audit Correlation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined; and
: [b] defined audit record review, analysis, and reporting processes are correlated.
|-
|[[Practice_AU.L2-3.3.5_Details|More Practice Details...]]
|}

=== AU.L2-3.3.6 – Reduction & Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide audit record reduction and report generation to support on-demand analysis and reporting.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an audit record reduction capability that supports on-demand analysis is provided; and
: [b] a report generation capability that supports on-demand reporting is provided.
|-
|[[Practice_AU.L2-3.3.6_Details|More Practice Details...]]
|}

=== AU.L2-3.3.7 – Authoritative Time Source ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] internal system clocks are used to generate time stamps for audit records;
: [b] an authoritative source with which to compare and synchronize internal system clocks is specified; and
: [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source.
|-
|[[Practice_AU.L2-3.3.7_Details|More Practice Details...]]
|}

=== AU.L2-3.3.8 – Audit Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit information is protected from unauthorized access;
: [b] audit information is protected from unauthorized modification;
: [c] audit information is protected from unauthorized deletion;
: [d] audit logging tools are protected from unauthorized access;
: [e] audit logging tools are protected from unauthorized modification; and
: [f] audit logging tools are protected from unauthorized deletion.
|-
|[[Practice_AU.L2-3.3.8_Details|More Practice Details...]]
|}

=== AU.L2-3.3.9 – Audit Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit management of audit logging functionality to a subset of privileged users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a subset of privileged users granted access to manage audit logging functionality is defined; and
: [b] management of audit logging functionality is limited to the defined subset of privileged users.
|-
|[[Practice_AU.L2-3.3.9_Details|More Practice Details...]]
|}

== Configuration Management (CM) ==
=== CM.L2-3.4.1 – System Baselining ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a baseline configuration is established;
: [b] the baseline configuration includes hardware, software, firmware, and documentation;
: [c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;
: [d] a system inventory is established;
: [e] the system inventory includes hardware, software, firmware, and documentation; and
: [f] the inventory is maintained (reviewed and updated) throughout the system development life cycle.
|-
|[[Practice_CM.L2-3.4.1_Details|More Practice Details...]]
|}

=== CM.L2-3.4.2 – Security Configuration Enforcement ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and enforce security configuration settings for information technology products employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
: [b] security configuration settings for information technology products employed in the system are enforced.
|-
|[[Practice_CM.L2-3.4.2_Details|More Practice Details...]]
|}

=== CM.L2-3.4.3 – System Change Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, review, approve or disapprove, and log changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] changes to the system are tracked;
: [b] changes to the system are reviewed;
: [c] changes to the system are approved or disapproved; and
: [d] changes to the system are logged.
|-
|[[Practice_CM.L2-3.4.3_Details|More Practice Details...]]
|}

=== CM.L2-3.4.4 – Security Impact Analysis ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Analyze the security impact of changes prior to implementation.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the security impact of changes to the system is analyzed prior to implementation.
|-
|[[Practice_CM.L2-3.4.4_Details|More Practice Details...]]
|}

=== CM.L2-3.4.5 – Access Restrictions for Change ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access restrictions associated with changes to the system are defined;
: [b] physical access restrictions associated with changes to the system are documented;
: [c] physical access restrictions associated with changes to the system are approved;
: [d] physical access restrictions associated with changes to the system are enforced;
: [e] logical access restrictions associated with changes to the system are defined;
: [f] logical access restrictions associated with changes to the system are documented;
: [g] logical access restrictions associated with changes to the system are approved; and
: [h] logical access restrictions associated with changes to the system are enforced.
|-
|[[Practice_CM.L2-3.4.5_Details|More Practice Details...]]
|}

=== CM.L2-3.4.6 – Least Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential system capabilities are defined based on the principle of least functionality; and
: [b] the system is configured to provide only the defined essential capabilities.
|-
|[[Practice_CM.L2-3.4.6_Details|More Practice Details...]]
|}

=== CM.L2-3.4.7 – Nonessential Functionality ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] essential programs are defined;
: [b] the use of nonessential programs is defined;
: [c] the use of nonessential programs is restricted, disabled, or prevented as defined;
: [d] essential functions are defined;
: [e] the use of nonessential functions is defined;
: [f] the use of nonessential functions is restricted, disabled, or prevented as defined;
: [g] essential ports are defined;
: [h] the use of nonessential ports is defined;
: [i] the use of nonessential ports is restricted, disabled, or prevented as defined;
: [j] essential protocols are defined;
: [k] the use of nonessential protocols is defined;
: [l] the use of nonessential protocols is restricted, disabled, or prevented as defined;
: [m] essential services are defined;
: [n] the use of nonessential services is defined; and
: [o] the use of nonessential services is restricted, disabled, or prevented as defined.
|-
|[[Practice_CM.L2-3.4.7_Details|More Practice Details...]]
|}

=== CM.L2-3.4.8 – Application Execution Policy ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified;
: [b] the software allowed to execute under whitelisting or denied use under blacklisting is specified; and
: [c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
|-
|[[Practice_CM.L2-3.4.8_Details|More Practice Details...]]
|}

=== CM.L2-3.4.9 – User-Installed Software ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor user-installed software.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy for controlling the installation of software by users is established;
: [b] installation of software by users is controlled based on the established policy; and
: [c] installation of software by users is monitored.
|-
|[[Practice_CM.L2-3.4.9_Details|More Practice Details...]]
|}

== Identification and Authentication (IA) ==
=== IA.L2-3.5.1 – Identification [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify information system users, processes acting on behalf of users, or devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system users are identified;
: [b] processes acting on behalf of users are identified; and
: [c] devices accessing the system are identified.
|-
|[[Practice_IA.L2-3.5.1_Details|More Practice Details...]]
|}

=== IA.L2-3.5.2 – Authentication [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the identity of each user is authenticated or verified as a prerequisite to system access;
: [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; and
: [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
|-
|[[Practice_IA.L2-3.5.2_Details|More Practice Details...]]
|}

=== IA.L2-3.5.3 – Multifactor Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] privileged accounts are identified;
: [b] multifactor authentication is implemented for local access to privileged accounts;
: [c] multifactor authentication is implemented for network access to privileged accounts; and
: [d] multifactor authentication is implemented for network access to non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.3_Details|More Practice Details...]]
|}

=== IA.L2-3.5.4 – Replay-Resistant Authentication ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
|-
|[[Practice_IA.L2-3.5.4_Details|More Practice Details...]]
|}

=== IA.L2-3.5.5 – Identifier Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent reuse of identifiers for a defined period.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period within which identifiers cannot be reused is defined; and
: [b] reuse of identifiers is prevented within the defined period.
|-
|[[Practice_IA.L2-3.5.5_Details|More Practice Details...]]
|}

=== IA.L2-3.5.6 – Identifier Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Disable identifiers after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity after which an identifier is disabled is defined; and
: [b] identifiers are disabled after the defined period of inactivity.
|-
|[[Practice_IA.L2-3.5.6_Details|More Practice Details...]]
|}

=== IA.L2-3.5.7 – Password Complexity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce a minimum password complexity and change of characters when new passwords are created.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] password complexity requirements are defined;
: [b] password change of character requirements are defined;
: [c] minimum password complexity requirements as defined are enforced when new passwords are created; and
: [d] minimum password change of character requirements as defined are enforced when new passwords are created.
|-
|[[Practice_IA.L2-3.5.7_Details|More Practice Details...]]
|}

=== IA.L2-3.5.8 – Password Reuse ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit password reuse for a specified number of generations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the number of generations during which a password cannot be reused is specified and [b] reuse of passwords is prohibited during the specified number of generations.
|-
|[[Practice_IA.L2-3.5.8_Details|More Practice Details...]]
|}

=== IA.L2-3.5.9 – Temporary Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Allow temporary password use for system logons with an immediate change to a permanent password.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an immediate change to a permanent password is required when a temporary password is used for system logon.
|-
|[[Practice_IA.L2-3.5.9_Details|More Practice Details...]]
|}

=== IA.L2-3.5.10 – Cryptographically-Protected Passwords ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Store and transmit only cryptographically-protected passwords.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] passwords are cryptographically protected in storage; and
: [b] passwords are cryptographically protected in transit.
|-
|[[Practice_IA.L2-3.5.10_Details|More Practice Details...]]
|}

=== IA.L2-3.5.11 – Obscure Feedback ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Obscure feedback of authentication information.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authentication information is obscured during the authentication process.
|-
|[[Practice_IA.L2-3.5.11_Details|More Practice Details...]]
|}

== Incident Response (IR) ==
=== IR.L2-3.6.1 – Incident Handling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] an operational incident-handling capability is established;
: [b] the operational incident-handling capability includes preparation;
: [c] the operational incident-handling capability includes detection;
: [d] the operational incident-handling capability includes analysis;
: [e] the operational incident-handling capability includes containment;
: [f] the operational incident-handling capability includes recovery; and
: [g] the operational incident-handling capability includes user response
|-
|[[Practice_IR.L2-3.6.1_Details|More Practice Details...]]
|}

=== IR.L2-3.6.2 – Incident Reporting ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] incidents are tracked;
: [b] incidents are documented;
: [c] authorities to whom incidents are to be reported are identified;
: [d] organizational officials to whom incidents are to be reported are identified;
: [e] identified authorities are notified of incidents; and
: [f] identified organizational officials are notified of incidents.
|-
|[[Practice_IR.L2-3.6.2_Details|More Practice Details...]]
|}

=== IR.L2-3.6.3 – Incident Response Testing ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Test the organizational incident response capability.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the incident response capability is tested.
|-
|[[Practice_IR.L2-3.6.3_Details|More Practice Details...]]
|}

== Maintenance (MA) ==
=== MA.L2-3.7.1 – Perform Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform maintenance on organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system maintenance is performed.
|-
|[[Practice_MA.L2-3.7.1_Details|More Practice Details...]]
|}

=== MA.L2-3.7.2 – System Maintenance Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] tools used to conduct system maintenance are controlled;
: [b] techniques used to conduct system maintenance are controlled;
: [c] mechanisms used to conduct system maintenance are controlled; and
: [d] personnel used to conduct system maintenance are controlled.
|-
|[[Practice_MA.L2-3.7.2_Details|More Practice Details...]]
|}

=== MA.L2-3.7.3 – Equipment Sanitization ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure equipment removed for off-site maintenance is sanitized of any CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] equipment to be removed from organizational spaces for off-site maintenance is sanitized of any CUI.
|-
|[[Practice_MA.L2-3.7.3_Details|More Practice Details...]]
|}

=== MA.L2-3.7.4 – Media Inspection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing diagnostic and test programs are checked for malicious code before being used in organizational systems that process, store, or transmit CUI.
|-
|[[Practice_MA.L2-3.7.4_Details|More Practice Details...]]
|}

=== MA.L2-3.7.5 – Nonlocal Maintenance ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and
: [b] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.
|-
|[[Practice_MA.L2-3.7.5_Details|More Practice Details...]]
|}

=== MA.L2-3.7.6 – Maintenance Personnel ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Supervise the maintenance activities of maintenance personnel without required access authorization.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] maintenance personnel without required access authorization are supervised during maintenance activities.
|-
|[[Practice_MA.L2-3.7.6_Details|More Practice Details...]]
|}

== Media Protection (MP) ==
=== MP.L2-3.8.1 – Media Protection ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] paper media containing CUI is physically controlled;
: [b] digital media containing CUI is physically controlled;
: [c] paper media containing CUI is securely stored; and
: [d] digital media containing CUI is securely stored.
|-
|[[Practice_MP.L2-3.8.1_Details|More Practice Details...]]
|}

=== MP.L2-3.8.2 – Media Access ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit access to CUI on system media to authorized users.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to CUI on system media is limited to authorized users.
|-
|[[Practice_MP.L2-3.8.2_Details|More Practice Details...]]
|}

=== MP.L2-3.8.3 – Media Disposal [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] system media containing CUI is sanitized or destroyed before disposal; and
: [b] system media containing CUI is sanitized before it is released for reuse.
|-
|[[Practice_MP.L2-3.8.3_Details|More Practice Details...]]
|}

=== MP.L2-3.8.4 – Media Markings ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Mark media with necessary CUI markings and distribution limitations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] media containing CUI is marked with applicable CUI markings; and
: [b] media containing CUI is marked with distribution limitations.
|-
|[[Practice_MP.L2-3.8.4_Details|More Practice Details...]]
|}

=== MP.L2-3.8.5 – Media Accountability ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] access to media containing CUI is controlled; and
: [b] accountability for media containing CUI is maintained during transport outside of controlled areas.
|-
|[[Practice_MP.L2-3.8.5_Details|More Practice Details...]]
|}

=== MP.L2-3.8.6 – Portable Storage Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI stored on digital media is protected during transport using cryptographic mechanisms or alternative physical safeguards.
|-
|[[Practice_MP.L2-3.8.6_Details|More Practice Details...]]
|}

=== MP.L2-3.8.7 – Removable Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control the use of removable media on system components.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of removable media on system components is controlled.
|-
|[[Practice_MP.L2-3.8.7_Details|More Practice Details...]]
|}

=== MP.L2-3.8.8 – Shared Media ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit the use of portable storage devices when such devices have no identifiable owner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.
|-
|[[Practice_MP.L2-3.8.8_Details|More Practice Details...]]
|}

=== MP.L2-3.8.9 – Protect Backups ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of backup CUI at storage locations.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of backup CUI is protected at storage locations.
|-
|[[Practice_MP.L2-3.8.9_Details|More Practice Details...]]
|}

== Personnel Security (PS) ==
=== PS.L2-3.9.1 – Screen Individuals ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Screen individuals prior to authorizing access to organizational systems containing CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] individuals are screened prior to authorizing access to organizational systems containing CUI.
|-
|[[Practice_PS.L2-3.9.1_Details|More Practice Details...]]
|}

=== PS.L2-3.9.2 – Personnel Actions ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;
: [b] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and
: [c] the system is protected during and after personnel transfer actions.
|-
|[[Practice_PS.L2-3.9.2_Details|More Practice Details...]]
|}

== Physical Protection (PE) ==
=== PE.L2-3.10.1 – Limit Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized individuals allowed physical access are identified;
: [b] physical access to organizational systems is limited to authorized individuals;
: [c] physical access to equipment is limited to authorized individuals; and
: [d] physical access to operating environments is limited to authorized.
|-
|[[Practice_PE.L2-3.10.1_Details|More Practice Details...]]
|}

=== PE.L2-3.10.2 – Monitor Facility ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect and monitor the physical facility and support infrastructure for organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the physical facility where organizational systems reside is protected;
: [b] the support infrastructure for organizational systems is protected;
: [c] the physical facility where organizational systems reside is monitored; and
: [d] the support infrastructure for organizational systems is monitored.
|-
|[[Practice_PE.L2-3.10.2_Details|More Practice Details...]]
|}

=== PE.L2-3.10.3 – Escort Visitors [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Escort visitors and monitor visitor activity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] visitors are escorted; and
: [b] visitor activity is monitored.
|-
|[[Practice_PE.L2-3.10.3_Details|More Practice Details...]]
|}

=== PE.L2-3.10.4 – Physical Access Logs [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Maintain audit logs of physical access.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] audit logs of physical access are maintained.
|-
|[[Practice_PE.L2-3.10.4_Details|More Practice Details...]]
|}

=== PE.L2-3.10.5 – Manage Physical Access [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and manage physical access devices.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] physical access devices are identified;
: [b] physical access devices are controlled; and
: [c] physical access devices are managed.
|-
|[[Practice_PE.L2-3.10.5_Details|More Practice Details...]]
|}

=== PE.L2-3.10.6 – Alternative Work Sites ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Enforce safeguarding measures for CUI at alternate work sites.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] safeguarding measures for CUI are defined for alternate work sites; and
: [b] safeguarding measures for CUI are enforced for alternate work sites.
|-
|[[Practice_PE.L2-3.10.6_Details|More Practice Details...]]
|}

== Risk Assessment (RA) ==
=== RA.L2-3.11.1 – Risk Assessments ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to assess risk to organizational operations, organizational assets, and individuals is defined; and
: [b] risk to organizational operations, organizational assets, and individuals resulting from the operation of an organizational system that processes, stores, or transmits CUI is assessed with the defined frequency.
|-
|[[Practice_RA.L2-3.11.1_Details|More Practice Details...]]
|}

=== RA.L2-3.11.2 – Vulnerability Scan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency to scan for vulnerabilities in organizational systems and applications is defined;
: [b] vulnerability scans are performed on organizational systems with the defined frequency;
: [c] vulnerability scans are performed on applications with the defined frequency;
: [d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified; and
: [e] vulnerability scans are performed on applications when new vulnerabilities are
identified.
|-
|[[Practice_RA.L2-3.11.2_Details|More Practice Details...]]
|}

=== RA.L2-3.11.3 – Vulnerability Remediation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Remediate vulnerabilities in accordance with risk assessments.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] vulnerabilities are identified; and
: [b] vulnerabilities are remediated in accordance with risk assessments.
|-
|[[Practice_RA.L2-3.11.3_Details|More Practice Details...]]
|}

== Security Assessment (CA) ==
=== CA.L2-3.12.1 – Security Control Assessment ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency of security control assessments is defined; and
: [b] security controls are assessed with the defined frequency to determine if the controls are effective in their application.
|-
|[[Practice_CA.L2-3.12.1_Details|More Practice Details...]]
|}

=== CA.L2-3.12.2 – Operational Plan of Action ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
: [b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
: [c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
|-
|[[Practice_CA.L2-3.12.2_Details|More Practice Details...]]
|}

=== CA.L2-3.12.3 – Security Control Monitoring ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] security controls are monitored on an ongoing basis to ensure the continued effectiveness of those controls.
|-
|[[Practice_CA.L2-3.12.3_Details|More Practice Details...]]
|}

=== CA.L2-3.12.4 – System Security Plan ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a system security plan is developed;
: [b] the system boundary is described and documented in the system security plan;
: [c] the system environment of operation is described and documented in the system security plan;
: [d] the security requirements identified and approved by the designated authority as non-applicable are identified;
: [e] the method of security requirement implementation is described and documented in the system security plan;
: [f] the relationship with or connection to other systems is described and documented in the system security plan;
: [g] the frequency to update the system security plan is defined; and
: [h] system security plan is updated with the defined frequency.
|-
|[[Practice_CA.L2-3.12.4_Details|More Practice Details...]]
|}

== System and Communications Protection (SC) ==
=== SC.L2-3.13.1 – Boundary Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the external system boundary is defined;
: [b] key internal system boundaries are defined;
: [c] communications are monitored at the external system boundary;
: [d] communications are monitored at key internal boundaries;
: [e] communications are controlled at the external system boundary;
: [f] communications are controlled at key internal boundaries;
: [g] communications are protected at the external system boundary; and
: [h] communications are protected at key internal boundaries.
|-
|[[Practice_SC.L2-3.13.1_Details|More Practice Details...]]
|}

=== SC.L2-3.13.2 – Security Engineering ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] architectural designs that promote effective information security are identified;
: [b] software development techniques that promote effective information security are identified;
: [c] systems engineering principles that promote effective information security are identified;
: [d] identified architectural designs that promote effective information security are employed;
: [e] identified software development techniques that promote effective information security are employed; and
: [f] identified systems engineering principles that promote effective information security are employed.
|-
|[[Practice_SC.L2-3.13.2_Details|More Practice Details...]]
|}

=== SC.L2-3.13.3 – Role Separation ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Separate user functionality from system management functionality.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] user functionality is identified;
: [b] system management functionality is identified; and
: [c] user functionality is separated from system management functionality.
|-
|[[Practice_SC.L2-3.13.3_Details|More Practice Details...]]
|}

=== SC.L2-3.13.4 – Shared Resource Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent unauthorized and unintended information transfer via shared system resources.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] unauthorized and unintended information transfer via shared system resources is
prevented.
|-
|[[Practice_SC.L2-3.13.4_Details|More Practice Details...]]
|}

=== SC.L2-3.13.5 – Public-Access System Separation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] publicly accessible system components are identified; and
: [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.
|-
|[[Practice_SC.L2-3.13.5_Details|More Practice Details...]]
|}

=== SC.L2-3.13.6 – Network Communication by Exception ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] network communications traffic is denied by default; and
: [b] network communications traffic is allowed by exception.
|-
|[[Practice_SC.L2-3.13.6_Details|More Practice Details...]]
|}

=== SC.L2-3.13.7 – Split Tunneling ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
|-
|[[Practice_SC.L2-3.13.7_Details|More Practice Details...]]
|}

=== SC.L2-3.13.8 – Data in Transit ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
: [b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
: [c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
|-
|[[Practice_SC.L2-3.13.8_Details|More Practice Details...]]
|}

=== SC.L2-3.13.9 – Connections Termination ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] a period of inactivity to terminate network connections associated with communications sessions is defined;
: [b] network connections associated with communications sessions are terminated at the end of the sessions; and
: [c] network connections associated with communications sessions are terminated after the defined period of inactivity.
|-
|[[Practice_SC.L2-3.13.9_Details|More Practice Details...]]
|}

=== SC.L2-3.13.10 – Key Management ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Establish and manage cryptographic keys for cryptography employed in organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] cryptographic keys are established whenever cryptography is employed; and
: [b] cryptographic keys are managed whenever cryptography is employed.
|-
|[[Practice_SC.L2-3.13.10_Details|More Practice Details...]]
|}

=== SC.L2-3.13.11 – CUI Encryption ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] FIPS-validated cryptography is employed to protect the confidentiality of CUI.
|-
|[[Practice_SC.L2-3.13.11_Details|More Practice Details...]]
|}

=== SC.L2-3.13.12 – Collaborative Device Control ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] collaborative computing devices are identified;
: [b] collaborative computing devices provide indication to users of devices in use; and
: [c] remote activation of collaborative computing devices is prohibited.
|-
|[[Practice_SC.L2-3.13.12_Details|More Practice Details...]]
|}

=== SC.L2-3.13.13 – Mobile Code ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of mobile code.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of mobile code is controlled; and
: [b] use of mobile code is monitored.
|-
|[[Practice_SC.L2-3.13.13_Details|More Practice Details...]]
|}

=== SC.L2-3.13.14 – Voice over Internet Protocol ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] use of Voice over Internet Protocol (VoIP) technologies is controlled; and
: [b] use of Voice over Internet Protocol (VoIP) technologies is monitored.
|-
|[[Practice_SC.L2-3.13.14_Details|More Practice Details...]]
|}

=== SC.L2-3.13.15 – Communications Authenticity ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the authenticity of communications sessions.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the authenticity of communications sessions is protected.
|-
|[[Practice_SC.L2-3.13.15_Details|More Practice Details...]]
|}

=== SC.L2-3.13.16 – Data at Rest ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Protect the confidentiality of CUI at rest.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the confidentiality of CUI at rest is protected.
|-
|[[Practice_SC.L2-3.13.16_Details|More Practice Details...]]
|}

== System and Information Integrity (SI) ==
=== SI.L2-3.14.1 – Flaw Remediation [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify, report, and correct information and information system flaws in a timely manner.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the time within which to identify system flaws is specified;
: [b] system flaws are identified within the specified time frame;
: [c] the time within which to report system flaws is specified;
: [d] system flaws are reported within the specified time frame;
: [e] the time within which to correct system flaws is specified; and
: [f] system flaws are corrected within the specified time frame.
|-
|[[Practice_SI.L2-3.14.1_Details|More Practice Details...]]
|}

=== SI.L2-3.14.2 – Malicious Code ProTection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Provide protection from malicious code at appropriate locations within organizational information systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] designated locations for malicious code protection are identified; and
: [b] protection from malicious code at designated locations is provided.
|-
|[[Practice_SI.L2-3.14.2_Details|More Practice Details...]]
|}

=== SI.L2-3.14.3 – Security Alerts & Advisories ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor system security alerts and advisories and take action in response.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] response actions to system security alerts and advisories are identified;
: [b] system security alerts and advisories are monitored; and
: [c] actions in response to system security alerts and advisories are taken.
|-
|[[Practice_SI.L2-3.14.3_Details|More Practice Details...]]
|}

=== SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Update malicious code protection mechanisms when new releases are available.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] malicious code protection mechanisms are updated when new releases are available.
|-
|[[Practice_SI.L2-3.14.4_Details|More Practice Details...]]
|}

=== SI.L2-3.14.5 – System & File Scanning [CUI Data] ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the frequency for malicious code scans is defined;
: [b] malicious code scans are performed with the defined frequency; and
: [c] real-time malicious code scans of files from external sources as files are downloaded, opened, or executed are performed.
|-
|[[Practice_SI.L2-3.14.5_Details|More Practice Details...]]
|}

=== SI.L2-3.14.6 – Monitor Communications for Attacks ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] the system is monitored to detect attacks and indicators of potential attacks;
: [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; and
: [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.
|-
|[[Practice_SI.L2-3.14.6_Details|More Practice Details...]]
|}

=== SI.L2-3.14.7 – Identify Unauthorized Use ===
{|class="wikitable"
|'''SECURITY REQUIREMENT'''
Identify unauthorized use of organizational systems.
|-
|'''ASSESSMENT OBJECTIVES'''
: [a] authorized use of the system is defined; and
: [b] unauthorized use of the system is identified.
|-
|[[Practice_SI.L2-3.14.7_Details|More Practice Details...]]
|}

== Appendix A – Acronyms and Abbreviations ==
{| class="wikitable"
|-
|| AC || Access Control
|-
|| CD-ROM || Compact Disk Read-Only Memory
|-
|| CFR || Code of Federal Regulations
|-
|| CMMC || Cybersecurity Maturity Model Certification
|-
|| CUI || Controlled Unclassified Information
|-
|| CVE || Common Vulnerabilities and Exposures
|-
|| CWE || Common Weakness Enumeration
|-
|| DFARS || Defense Federal Acquisition Regulation Supplement
|-
|| DMZ || Demilitarized Zone
|-
|| DoD || Department of Defense
|-
|| ESP || External Service Provider
|-
|| FAR || Federal Acquisition Regulation
|-
|| FCI || Federal Contract Information
|-
|| IT || Information Technology
|-
|| NIST || National Institute of Standards and Technology
|-
|| OSA || Organization Seeking Assessment
|-
|| PIV || Personal Identity Verification
|-
|| SC || System and Communications Protection
|-
|| SI || System and Information Integrity
|-
|| SP || Special Publication
|-
|| SPRS || Supplier Performance Risk System
|-
|| USB || Universal Serial Bus
|-
|| UUENCODE || Unix-to-Unix Encode
|-
|| VLAN || Virtual Local Area Network
|}

LLMResponse AC.L2-3.1.4.c

2025-04-30T02:31:41Z

David: Created page with "Ranking Evidence Types for Assessment Objective [c] For the assessment objective "[c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals," here's the ranking of evidence types supported by assessment objects: == Evidence Type Ranking == 1. **Artifacts (highest value)** - System access authorization records showing privilege distribution - Access control lists demonstrating separation of pr..."

Ranking Evidence Types for Assessment Objective [c]

For the assessment objective "[c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals," here's the ranking of evidence types supported by assessment objects:

== Evidence Type Ranking ==

1. **Artifacts (highest value)**
- System access authorization records showing privilege distribution
- Access control lists demonstrating separation of privileges
- User account privilege reports showing different access rights
- System audit logs that record access privilege usage by different individuals

2. **Documents**
- System configuration documentation showing access privilege assignments
- Access control matrices mapping privileges to separate individuals
- Security procedures for granting privileges
- Privileged account management policies

3. **Screen Share**
- Live demonstration of access control system showing privilege assignments
- Viewing access management interfaces that display user privileges
- Demonstration of attempts to access functions requiring separated duties

4. **Physical Review (lowest value)**
- Observation of physical access controls that support privilege separation
- Viewing secured environments where separated privileges are exercised

== Assessment Approach Prioritization ==

For assessment objective [c], I recommend prioritizing the approaches as follows:

1. **Test (highest priority)**
- Begin by testing mechanisms implementing separation of duties policy
- Verify that access controls prevent individuals from exercising multiple critical functions
- Attempt to perform incompatible functions using different accounts
- This directly demonstrates that access privileges are properly separated

2. **Examine**
- Review system access authorizations for different individuals
- Check privilege assignments in access control systems
- Analyze audit logs to verify proper privilege distribution
- This documentation confirms the configuration of access controls

3. **Interview**
- Talk with system administrators who manage access privileges
- Interview security personnel about privilege separation implementation
- Discuss with users how they experience access limitations
- These interviews provide context for understanding how privileges are managed

This prioritization first focuses on testing the actual implementation of privilege separation (which is the most direct evidence for this objective), then examines documentation to verify systematic implementation, and finally confirms through interviews that the process is understood and consistently applied.

LLMResponse AC.L2-3.1.4.b

2025-04-30T02:30:40Z

David: Created page with "Ranking Evidence Types for Assessment Objective [b] For the assessment objective "[b] responsibilities for duties that require separation are assigned to separate individuals," here's the ranking of evidence types supported by assessment objects: == Evidence Type Ranking == 1. **Artifacts (highest value)** - User account listings with role assignments - System access authorizations showing different individuals assigned to separated duties - Access control ma..."

Ranking Evidence Types for Assessment Objective [b]

For the assessment objective "[b] responsibilities for duties that require separation are assigned to separate individuals," here's the ranking of evidence types supported by assessment objects:

== Evidence Type Ranking ==

1. **Artifacts (highest value)**
- User account listings with role assignments
- System access authorizations showing different individuals assigned to separated duties
- Access control matrices demonstrating separation implementation
- Change management records showing different people involved in change processes

2. **Documents**
- Procedures documenting how duties are assigned to different individuals
- Organization charts showing actual staff assignments to roles
- Job descriptions that specify individual responsibilities
- Staff assignment records demonstrating separation of duties

3. **Screen Share**
- Live demonstration of access control systems showing individual assignments
- Viewing system configurations showing how different accounts have separate privileges

4. **Physical Review (lowest value)**
- On-site verification of work arrangements supporting separation
- Observation of individuals performing different roles in critical processes

== Assessment Approach Prioritization ==

For assessment objective [b], I recommend prioritizing the approaches as follows:

1. **Interview (highest priority)**
- Start by interviewing personnel with responsibilities for defining divisions of responsibility
- Talk with system administrators who implement access controls
- Interview security personnel about how they ensure proper separations
- These interviews provide direct evidence of how responsibilities are assigned in practice

2. **Examine**
- Review staff assignment documentation
- Check system access authorizations for different individuals
- Analyze role assignments across the organization
- This documentation validates what was learned in interviews

3. **Test (supplementary)**
- Test system access controls to verify different individuals have appropriate access
- Attempt to perform incompatible functions using different accounts
- This testing confirms that technical controls enforce the separation of individuals

This prioritization focuses first on understanding how separations are actually implemented through personnel assignments, then verifies this through documentation, and finally confirms through technical verification that the separations are enforced.

LLMResponse AC.L2-3.1.4.a

2025-04-30T02:29:31Z

David: Created page with "Ranking Evidence Types for Assessment Objective [a] For the assessment objective "[a] the duties of individuals requiring separation are defined," I'll rank the evidence types supported by assessment objects from most to least valuable: == Evidence Type Ranking == 1. **Documents (highest value)** - Access control policy documents - Written procedures addressing divisions of responsibility and separation of duties - System security plan with defined separation..."

Ranking Evidence Types for Assessment Objective [a]

For the assessment objective "[a] the duties of individuals requiring separation are defined," I'll rank the evidence types supported by assessment objects from most to least valuable:

== Evidence Type Ranking ==

1. **Documents (highest value)**
- Access control policy documents
- Written procedures addressing divisions of responsibility and separation of duties
- System security plan with defined separation requirements
- List of divisions of responsibility and separation of duties
- Job descriptions that specify segregated duties

2. **Artifacts**
- System configuration settings showing role separations
- Role matrices showing incompatible functions
- Access control lists demonstrating separation implementation
- Organizational charts showing functional separation

3. **Physical Review**
- On-site verification of physical access controls supporting separation
- Observation of work areas arranged to support separation

4. **Screen Share (lowest value)**
- Demonstration of access control systems showing separation enforcement
- Viewing system configurations that implement separation

== Assessment Approach Prioritization ==

I recommend prioritizing the three assessment approaches as follows:

1. **Examine (highest priority)**
- Start by examining documentation that explicitly defines which duties require separation
- This provides the foundation for understanding how separation of duties is conceptualized in your organization
- Focus on formal policies, procedures, and system security plans

2. **Interview**
- After examining documents, interview personnel with responsibilities for defining divisions of responsibility
- Interview security personnel and system administrators to verify understanding
- These interviews validate that the documented definitions are understood and followed

3. **Test (supplementary)**
- Finally, test mechanisms implementing separation of duties
- This confirms that technical controls enforce the defined separations
- Testing serves as verification of actual implementation rather than primary evidence

This prioritization follows a logical progression: first understand what's defined, then verify understanding through interviews, and finally confirm implementation through testing.

LLMPrompt AC.L2-3.1.4.c

2025-04-30T02:28:28Z

David: Created page with "For the assessment objective, [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.4.b

2025-04-30T02:28:14Z

David: Created page with "For the assessment objective, [b] responsibilities for duties that require separation are assigned to separate individuals, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [b] responsibilities for duties that require separation are assigned to separate individuals, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.4.a

2025-04-30T02:27:57Z

David: Created page with "For the assessment objective, [a] the duties of individuals requiring separation are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [a] the duties of individuals requiring separation are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.4

2025-04-30T02:25:55Z

David: Created page with "I am a cybersecurity manager working for an organization that is a DoD contractor. I need to implement various security practices that conform to DoD's CMMC program at level 2. The CMMC program stipulates security practices that are based on NIST Special Publication 800-171 R2. For each security practice of CMMC Level 2, I need to show evidence that my organization is in compliance with CMMC. Each security practice has a security requirement and several assessment object..."

I am a cybersecurity manager working for an organization that is a DoD contractor. I need to implement various security practices that conform to DoD's CMMC program at level 2. The CMMC program stipulates security practices that are based on NIST Special Publication 800-171 R2. For each security practice of CMMC Level 2, I need to show evidence that my organization is in compliance with CMMC. Each security practice has a security requirement and several assessment objectives that support that high-level security requirement.

I am assessing one of the assessment objectives within the practice AC.L2-3.1.4 "SEPARATION OF DUTIES." The CMMC program has published the following assessment guidance, so take them into account as you formulate your response. Also refer to the attached CMMC Level 2 Assessment Guide for more context and information about the practice.

A. SECURITY REQUIREMENT: Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

B. ASSESSMENT OBJECTIVES [NIST SP 800-171A]: Determine if: [a] the duties of individuals requiring separation are defined; [b] responsibilities for duties that require separation are assigned to separate individuals; and [c] access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals.

C. ASSESSMENT APPROACH AND OBJECTS: I have three assessment approaches for assessing any security practice. They are listed as follows:

C1. Examine: The process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objectives to facilitate understanding, achieve clarification, or obtain evidence. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.

C2. Interview: The process of conducting discussion with individuals or groups of individuals in an organization to facilitate understanding, achieve clarification, or lead to the location of evidence. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.

C3. Test: The process of exercising one or more assessment objects under specified conditions to compare actual with expected behavior. The results are used to support the determination of security safeguard existence, functionality, correctness, completeness, and potential for improvement over time.

D. ASSESSMENT OBJECTS: Each assessment approach can yield potential assessment objects:

D1. Examine: [SELECT FROM: Access control policy; procedures addressing divisions of responsibility and separation of duties; system security plan; system configuration settings and associated documentation; list of divisions of responsibility and separation of duties; system access authorizations; system audit logs and records; other relevant documents or records].

D2. Interview: [SELECT FROM: Personnel with responsibilities for defining divisions of responsibility and separation of duties; personnel with information security responsibilities; system or network administrators].

D3. Test: [SELECT FROM: Mechanisms implementing separation of duties policy].

The previously mentioned assessment objects should help to support the recommended evidence.

E. DISCUSSION: Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security);and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of organizational systems and system components when developing policy on separation of duties.

F. FURTHER DISCUSSION: No one person should be in charge of an entire critical task from beginning to end. Documenting and dividing elements of important duties and tasks between employees reduces intentional or unintentional execution of malicious activities.

G. Examples:

G1. Example 1: You are responsible for the management of several key systems within your organization. You assign the task of reviewing the system logs to two different people. This way, no one person is solely responsible for the execution of this critical security function [c].

G2. Example 2: You are a system administrator. Human Resources notifies you of a new hire, and you create an account with general privileges, but you are not allowed to grant access to systems that contain CUI [a,b]. The program manager contacts the team in your organization that has system administration authority over the CUI systems and informs them which CUI the new hire will need to access. Subsequently, a second system administrator grants access privileges to the new hire [c].

H. Potential Assessment Considerations: Does system documentation identify the system functions or processes that require separation of duties (e.g., function combinations that represent a conflict of interest or an over-allocation of security privilege for one individual) [a]?

I. EVIDENCE TYPES: Finally, I have four evidence types that I can collect. The definitions of the evidence types are as follows:

I1. Artifacts: Tangible and reviewable records that are the direct outcome of a practice or process being performed by a system, person, or persons performing a role in that practice, control, or process. (See CAP Glossary for additional details.)

I2. Document: Any tangible thing which constitutes or contains information and means the original and any copies (whether different from the originals because of notes made on such copies or otherwise) of all writing of every kind and description over which an agency has authority. (See CAP Glossary for additional details.)

I3. Physical Review: An on-premise observation of Evidence.

I4. Screen Share: Live observation ""over the shoulder"" of a user as they share their computer screen while performing a task.

J. KEY REFERENCES: NIST SP 800-171 Rev 2 3.1.4

LLMResponse AC.L2-3.1.3.e

2025-04-30T02:18:36Z

David: Created page with "Ranking Evidence Types for Enforcement of CUI Flow Authorizations For assessment objective [e] "approved authorizations for controlling the flow of CUI are enforced," here's my ranking of evidence types based on the CMMC assessment objects: == Evidence Type Ranking == 1. **Technical Testing Evidence (Highest Priority)** - Results from testing mechanisms implementing information flow enforcement policy - Configuration screenshots of boundary protection devices..."

Ranking Evidence Types for Enforcement of CUI Flow Authorizations

For assessment objective [e] "approved authorizations for controlling the flow of CUI are enforced," here's my ranking of evidence types based on the CMMC assessment objects:

== Evidence Type Ranking ==

1. **Technical Testing Evidence (Highest Priority)**
- Results from testing mechanisms implementing information flow enforcement policy
- Configuration screenshots of boundary protection devices
- Audit logs showing enforcement of flow controls
- Network traffic analysis showing blocked unauthorized attempts
- System monitoring records demonstrating active enforcement

2. **Documentation (Medium-High Priority)**
- System configuration settings and associated documentation
- System audit logs and records showing enforcement actions
- System baseline configuration showing enforcement mechanisms
- Incident reports showing response to unauthorized flow attempts

3. **Interview Evidence (Supporting Priority)**
- Information from system/network administrators about enforcement activities
- Explanations from security personnel about how violations are handled
- Examples of enforcement actions taken from relevant personnel

== Assessment Approach Prioritization ==

For this objective, I recommend prioritizing assessment approaches as follows:

1. **Test (First)**: Unlike the previous objectives, testing should be your primary approach for demonstrating enforcement. This is because enforcement is an active function that can best be verified through technical validation of working mechanisms.

2. **Examine (Second)**: Documentation review provides supporting evidence of enforcement through logs, configuration files, and records of enforcement actions.

3. **Interview (Third)**: Interviews can provide context and explanations for how enforcement works in practice and how exceptions are handled.

This objective differs significantly from the previous ones because it focuses on the actual implementation and operation of controls rather than their definition. While documentation remains important, technical evidence showing that the mechanisms are actively enforcing the defined authorizations is most critical. This is why the "Test" approach takes precedence for this specific objective.

LLMResponse AC.L2-3.1.3.d

2025-04-30T02:17:40Z

David: Created page with "Ranking Evidence Types for CUI Flow Authorizations For assessment objective [d] "authorizations for controlling the flow of CUI are defined," here's my ranking of evidence types based on the CMMC assessment objects: == Evidence Type Ranking == 1. **Documentation (Highest Priority)** - List of information flow authorizations - Access control policy sections on authorization requirements - System connection or processing agreements - System security plan se..."

Ranking Evidence Types for CUI Flow Authorizations

For assessment objective [d] "authorizations for controlling the flow of CUI are defined," here's my ranking of evidence types based on the CMMC assessment objects:

== Evidence Type Ranking ==

1. **Documentation (Highest Priority)**
- List of information flow authorizations
- Access control policy sections on authorization requirements
- System connection or processing agreements
- System security plan sections on authorization processes
- Approval documentation for CUI flow paths
- Account management documents with authorization details

2. **Interview Evidence (Medium Priority)**
- Interviews with personnel responsible for defining authorizations
- Discussions with system administrators about authorization processes
- Information from security personnel on approval workflows

3. **Technical Testing Evidence (Supporting Priority)**
- Configuration evidence showing implemented authorization rules
- Screenshots of authorization tables or matrices
- System settings that enforce defined authorizations

== Assessment Approach Prioritization ==

For this objective, I recommend prioritizing assessment approaches as follows:

1. **Examine (First)**: Start by examining formal documentation of authorizations since this objective specifically focuses on whether authorizations are "defined." This includes reviewing policies, procedures, and authorization records that formally establish who/what is permitted to transmit CUI.

2. **Interview (Second)**: After reviewing documentation, interview personnel responsible for defining and managing authorizations to understand how the organization determines who is authorized to control CUI flow.

3. **Test (Third)**: While technical validation is still important, it serves more as supporting evidence for this objective, as it focuses more on enforcement (objective [e]) than on definition.

This objective focuses specifically on the formal definition of who or what is authorized to control the flow of CUI. Strong documentation showing clearly defined authorization requirements, roles, and processes will be your most compelling evidence. The technical implementation of these authorizations becomes more critical for objective [e].

LLMResponse AC.L2-3.1.3.c

2025-04-30T02:16:04Z

David: Created page with "Ranking Evidence Types for Designated Sources and Destinations For assessment objective [c] "designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified," here's my ranking of evidence types based on the CMMC assessment objects: == Evidence Type Ranking == 1. **Documentation (Highest Priority)** - Network diagrams showing CUI flow paths - System design documentation id..."

Ranking Evidence Types for Designated Sources and Destinations

For assessment objective [c] "designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified," here's my ranking of evidence types based on the CMMC assessment objects:

== Evidence Type Ranking ==

1. **Documentation (Highest Priority)**
- Network diagrams showing CUI flow paths
- System design documentation identifying CUI sources and destinations
- System security plan sections mapping CUI flows
- List of information flow authorizations with source/destination details
- System baseline configuration documents showing network segmentation

2. **Technical Testing Evidence (Medium-High Priority)**
- Configuration files showing allowed/denied paths between sources and destinations
- Firewall/router/switch configurations with rules for specific sources and destinations
- Access control lists identifying permitted connection paths

3. **Interview Evidence (Supporting Priority)**
- Explanations from system/network administrators about how sources and destinations are identified
- Information from security personnel on how CUI boundaries are defined

== Assessment Approach Prioritization ==

For this objective, I recommend prioritizing assessment approaches as follows:

1. **Examine (First)**: Documentation review should be your first approach since identifying sources and destinations is primarily documented through network diagrams, data flow diagrams, and other system documentation that maps where CUI resides and flows.

2. **Test (Second)**: Technical validation provides concrete evidence that the identified sources and destinations are actually implemented in the system. This helps verify that documentation accurately reflects the actual system state.

3. **Interview (Third)**: Use interviews to clarify how the organization identifies and tracks CUI sources and destinations, particularly for any areas not clearly documented.

This objective is particularly focused on having clearly identified and documented locations where CUI is stored, processed, and transmitted. Strong documentation that maps these sources and destinations is the most critical evidence type, supported by technical validation that the system is configured according to these specifications.

LLMResponse AC.L2-3.1.3.b

2025-04-30T02:14:42Z

David: Created page with "Ranking Evidence Types for Methods and Enforcement Mechanisms For assessment objective [b] "methods and enforcement mechanisms for controlling the flow of CUI are defined," here's how I rank the evidence types based on the CMMC assessment objects: == Evidence Type Ranking == 1. **Documentation (High Priority)** - System design documentation showing flow control mechanisms - Configuration settings and associated documentation - Information flow control policie..."

Ranking Evidence Types for Methods and Enforcement Mechanisms

For assessment objective [b] "methods and enforcement mechanisms for controlling the flow of CUI are defined," here's how I rank the evidence types based on the CMMC assessment objects:

== Evidence Type Ranking ==

1. **Documentation (High Priority)**
- System design documentation showing flow control mechanisms
- Configuration settings and associated documentation
- Information flow control policies with technical specifications
- Procedures addressing information flow enforcement
- System baseline configuration documentation

2. **Technical Testing Evidence (High Priority)**
- Documentation of mechanisms implementing information flow enforcement
- Configuration files for boundary protection devices
- Screenshots of rule sets for gateways, routers, firewalls, etc.

3. **Interview Evidence (Supporting Priority)**
- Technical explanations from system/network administrators
- Clarification from system developers on implementation details

== Assessment Approach Prioritization ==

For obtaining evidence of defined methods and enforcement mechanisms, I recommend this approach order:

1. **Examine (First)**: Start by examining technical documentation that specifically describes the methods and mechanisms for controlling CUI flow. This establishes that the methods are formally defined.

2. **Test (Second)**: For this objective, testing is particularly important as it provides concrete evidence that enforcement mechanisms are properly defined in the system. Technical validation should closely follow documentation review.

3. **Interview (Third)**: Use interviews to clarify technical aspects of the mechanisms and fill gaps in understanding how methods are defined within the organization.

This prioritization differs slightly from objective [a] because "methods and enforcement mechanisms" are more technical in nature than general policies. While documentation remains important, technical evidence plays a more significant role in demonstrating that specific methods and mechanisms are defined in your systems.

LLMResponse AC.L2-3.1.3.a

2025-04-30T02:13:17Z

David: Created page with "Ranking Evidence Types for Information Flow Control Policies For assessment objective [a] "information flow control policies are defined," I'll rank the evidence types from most to least important based on the assessment objects in the CMMC documentation: == Evidence Type Ranking == 1. **Documentation (Highest Priority)** - Access control policy documents - Information flow control policy documentation - System security plan sections on information flow -..."

Ranking Evidence Types for Information Flow Control Policies

For assessment objective [a] "information flow control policies are defined," I'll rank the evidence types from most to least important based on the assessment objects in the CMMC documentation:

== Evidence Type Ranking ==

1. **Documentation (Highest Priority)**
- Access control policy documents
- Information flow control policy documentation
- System security plan sections on information flow
- Procedures addressing information flow enforcement
- List of information flow authorizations

2. **Interview Evidence (Medium Priority)**
- Statements from system/network administrators
- Feedback from personnel with information security responsibilities

3. **Technical Testing Evidence (Supporting Priority)**
- Configuration settings demonstrating policy implementation
- Screenshots or outputs showing mechanisms supporting the policies

== Assessment Approach Prioritization ==

For obtaining this evidence, I recommend prioritizing the assessment approaches in this order:

1. **Examine (First)**: Begin by examining all documentation since this directly addresses whether policies are defined. The CMMC guide specifically lists policy documents first in the assessment objects.

2. **Interview (Second)**: After reviewing documentation, interview personnel to confirm understanding of policies and fill any gaps in documentation.

3. **Test (Third)**: For policy definition (as opposed to enforcement), testing is less critical but still provides supporting evidence that policies have been operationalized.

This prioritization makes sense because "defined" in this context primarily refers to documented policies. Examination of documentation provides the most direct evidence that information flow control policies have been formally defined, while interviews and testing help verify that these definitions are understood and implemented.

LLMPrompt AC.L2-3.1.3.e

2025-04-30T02:11:40Z

David: Created page with "For the assessment objective, [e] approved authorizations for controlling the flow of CUI are enforced, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [e] approved authorizations for controlling the flow of CUI are enforced, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.3.d

2025-04-30T02:11:27Z

David: Created page with "For the assessment objective, [d] authorizations for controlling the flow of CUI are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [d] authorizations for controlling the flow of CUI are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.3.c

2025-04-30T02:11:09Z

David: Created page with "For the assessment objective, [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [c] designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?

LLMPrompt AC.L2-3.1.3.b

2025-04-30T02:10:52Z

David: Created page with "For the assessment objective, [b] methods and enforcement mechanisms for controlling the flow of CUI are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?"

For the assessment objective, [b] methods and enforcement mechanisms for controlling the flow of CUI are defined, rank the evidence types supported by assessment objects. Also, how should I prioritize the three assessment approaches in obtaining the evidence?