Level 2 Assessment Guide

Source of Reference: The official 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 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, 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. 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. As described in NIST SP 800-171A, 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.
• 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.
• 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:

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.

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.
• 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.
• 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]

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).

More Practice Details...

AC.L2-3.1.2 – Transaction & Function Control [CUI Data]

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.

More Practice Details...

AC.L2-3.1.3 – Control CUI Flow

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.

More Practice Details...

AC.L2-3.1.4 – Separation of Duties

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.

More Practice Details...

AC.L2-3.1.5 – Least Privilege

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.

More Practice Details...

AC.L2-3.1.6 – Non-Privileged Account Use

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.

More Practice Details...

AC.L2-3.1.7 – Privileged Functions

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.

More Practice Details...

AC.L2-3.1.8 – Unsuccessful Logon Attempts

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.

More Practice Details...

AC.L2-3.1.9 – Privacy & Security Notices

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.

More Practice Details...

AC.L2-3.1.10 – Session Lock

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.

More Practice Details...

AC.L2-3.1.11 – Session Termination

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

More Practice Details...

AC.L2-3.1.12 – Control Remote Access

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.

More Practice Details...

AC.L2-3.1.13 – Remote Access Confidentiality

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.

More Practice Details...

AC.L2-3.1.14 – Remote Access Routing

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.

More Practice Details...

AC.L2-3.1.15 – Privileged Remote Access

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.

More Practice Details...

AC.L2-3.1.16 – Wireless Access Authorization

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.

More Practice Details...

AC.L2-3.1.17 – Wireless Access Protection

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.

More Practice Details...

AC.L2-3.1.18 – Mobile Device Connection

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.

More Practice Details...

AC.L2-3.1.19 – Encrypt CUI on Mobile

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.

More Practice Details...

AC.L2-3.1.20 – External Connections [CUI Data]

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.

More Practice Details...

AC.L2-3.1.21 – Portable Storage Use

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.

More Practice Details...

AC.L2-3.1.22 – Control Public Information [CUI Data]

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.

More Practice Details...

Awareness and Training (AT)

AT.L2-3.2.1 – Role-Based Risk Awareness

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.

More Practice Details...

AT.L2-3.2.2 – Role-Based Training

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.

More Practice Details...

AT.L2-3.2.3 – Insider Threat Awareness

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.

More Practice Details...

Audit and Accountability (AU)

AU.L2-3.3.1 – System Auditing

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.

More Practice Details...

AU.L2-3.3.2 – User Accountability

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.

More Practice Details...

AU.L2-3.3.3 – Event Review

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.

More Practice Details...

AU.L2-3.3.4 – Audit Failure Alerting

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.

More Practice Details...

AU.L2-3.3.5 – Audit Correlation

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.

More Practice Details...

AU.L2-3.3.6 – Reduction & Reporting

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.

More Practice Details...

AU.L2-3.3.7 – Authoritative Time Source

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.

More Practice Details...

AU.L2-3.3.8 – Audit Protection

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.

More Practice Details...

AU.L2-3.3.9 – Audit Management

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.

More Practice Details...

Configuration Management (CM)

CM.L2-3.4.1 – System Baselining

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.

More Practice Details...

CM.L2-3.4.2 – Security Configuration Enforcement

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.

More Practice Details...

CM.L2-3.4.3 – System Change Management

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.

More Practice Details...

CM.L2-3.4.4 – Security Impact Analysis

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.

More Practice Details...

CM.L2-3.4.5 – Access Restrictions for Change

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.

More Practice Details...

CM.L2-3.4.6 – Least Functionality

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.

More Practice Details...

CM.L2-3.4.7 – Nonessential Functionality

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.

More Practice Details...

CM.L2-3.4.8 – Application Execution Policy

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.

More Practice Details...

CM.L2-3.4.9 – User-Installed Software

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.

More Practice Details...

Identification and Authentication (IA)

IA.L2-3.5.1 – Identification [CUI Data]

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.

More Practice Details...

IA.L2-3.5.2 – Authentication [CUI Data]

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.

More Practice Details...

IA.L2-3.5.3 – Multifactor Authentication

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.

More Practice Details...

IA.L2-3.5.4 – Replay-Resistant Authentication

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.

More Practice Details...

IA.L2-3.5.5 – Identifier Reuse

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.

More Practice Details...

IA.L2-3.5.6 – Identifier Handling

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.

More Practice Details...

IA.L2-3.5.7 – Password Complexity

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.

More Practice Details...

IA.L2-3.5.8 – Password Reuse

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.

More Practice Details...

IA.L2-3.5.9 – Temporary Passwords

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.

More Practice Details...

IA.L2-3.5.10 – Cryptographically-Protected Passwords

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.

More Practice Details...

IA.L2-3.5.11 – Obscure Feedback

SECURITY REQUIREMENT Obscure feedback of authentication information.

ASSESSMENT OBJECTIVES [a] authentication information is obscured during the authentication process.

More Practice Details...

Incident Response (IR)

IR.L2-3.6.1 – Incident Handling

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

More Practice Details...

IR.L2-3.6.2 – Incident Reporting

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.

More Practice Details...

IR.L2-3.6.3 – Incident Response Testing

SECURITY REQUIREMENT Test the organizational incident response capability.

ASSESSMENT OBJECTIVES [a] the incident response capability is tested.

More Practice Details...

Maintenance (MA)

MA.L2-3.7.1 – Perform Maintenance

SECURITY REQUIREMENT Perform maintenance on organizational systems.

ASSESSMENT OBJECTIVES [a] system maintenance is performed.

More Practice Details...

MA.L2-3.7.2 – System Maintenance Control

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.

More Practice Details...

MA.L2-3.7.3 – Equipment Sanitization

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.

More Practice Details...

MA.L2-3.7.4 – Media Inspection

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.

More Practice Details...

MA.L2-3.7.5 – Nonlocal Maintenance

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.

More Practice Details...

MA.L2-3.7.6 – Maintenance Personnel

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.

More Practice Details...

Media Protection (MP)

MP.L2-3.8.1 – Media Protection

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.

More Practice Details...

MP.L2-3.8.2 – Media Access

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.

More Practice Details...

MP.L2-3.8.3 – Media Disposal [CUI Data]

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.

More Practice Details...

MP.L2-3.8.4 – Media Markings

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.

More Practice Details...

MP.L2-3.8.5 – Media Accountability

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.

More Practice Details...

MP.L2-3.8.6 – Portable Storage Encryption

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.

More Practice Details...

MP.L2-3.8.7 – Removable Media

SECURITY REQUIREMENT Control the use of removable media on system components.

ASSESSMENT OBJECTIVES [a] the use of removable media on system components is controlled.

More Practice Details...

MP.L2-3.8.8 – Shared Media

SECURITY REQUIREMENT Prohibit the use of portable storage devices when such devices have no identifiable owner.ASSESSMENT OBJECTIVES

ASSESSMENT OBJECTIVES [a] the use of portable storage devices is prohibited when such devices have no identifiable owner.

More Practice Details...

MP.L2-3.8.9 – Protect Backups

SECURITY REQUIREMENT Protect the confidentiality of backup CUI at storage locations.

ASSESSMENT OBJECTIVES [a] the confidentiality of backup CUI is protected at storage locations.

More Practice Details...

Personnel Security (PS)

PS.L2-3.9.1 – Screen Individuals

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.

More Practice Details...

PS.L2-3.9.2 – Personnel Actions

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.

More Practice Details...

Physical Protection (PE)

PE.L2-3.10.1 – Limit Physical Access [CUI Data]

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.

More Practice Details...

PE.L2-3.10.2 – Monitor Facility

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.

More Practice Details...

PE.L2-3.10.3 – Escort Visitors [CUI Data]

SECURITY REQUIREMENT Escort visitors and monitor visitor activity.

ASSESSMENT OBJECTIVES [a] visitors are escorted; and [b] visitor activity is monitored.

More Practice Details...

PE.L2-3.10.4 – Physical Access Logs [CUI Data]

SECURITY REQUIREMENT Maintain audit logs of physical access.

ASSESSMENT OBJECTIVES [a] audit logs of physical access are maintained.

More Practice Details...

PE.L2-3.10.5 – Manage Physical Access [CUI Data]

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.

More Practice Details...

PE.L2-3.10.6 – Alternative Work Sites

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.

More Practice Details...

Risk Assessment (RA)

RA.L2-3.11.1 – Risk Assessments

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.

More Practice Details...

RA.L2-3.11.2 – Vulnerability Scan

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.

More Practice Details...

RA.L2-3.11.3 – Vulnerability Remediation

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.

More Practice Details...

Security Assessment (CA)

CA.L2-3.12.1 – Security Control Assessment

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.

More Practice Details...

CA.L2-3.12.2 – Operational Plan of Action

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.

More Practice Details...

CA.L2-3.12.3 – Security Control Monitoring

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.

More Practice Details...

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 [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.

More Practice Details...

System and Communications Protection (SC)

SC.L2-3.13.1 – Boundary Protection [CUI Data]

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.

More Practice Details...

SC.L2-3.13.2 – Security Engineering

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.

More Practice Details...

SC.L2-3.13.3 – Role Separation

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.

More Practice Details...

SC.L2-3.13.4 – Shared Resource Control

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.

More Practice Details...

SC.L2-3.13.5 – Public-Access System Separation [CUI Data]

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.

More Practice Details...

SC.L2-3.13.6 – Network Communication by Exception

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.

More Practice Details...

SC.L2-3.13.7 – Split Tunneling

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).

More Practice Details...

SC.L2-3.13.8 – Data in Transit

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.

More Practice Details...

SC.L2-3.13.9 – Connections Termination

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.

More Practice Details...

SC.L2-3.13.10 – Key Management

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.

More Practice Details...

SC.L2-3.13.11 – CUI Encryption

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.

More Practice Details...

SC.L2-3.13.12 – Collaborative Device Control

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.

More Practice Details...

SC.L2-3.13.13 – Mobile Code

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.

More Practice Details...

SC.L2-3.13.14 – Voice over Internet Protocol

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.

More Practice Details...

SC.L2-3.13.15 – Communications Authenticity

SECURITY REQUIREMENT Protect the authenticity of communications sessions.

ASSESSMENT OBJECTIVES [a] the authenticity of communications sessions is protected.

More Practice Details...

SC.L2-3.13.16 – Data at Rest

SECURITY REQUIREMENT Protect the confidentiality of CUI at rest.

ASSESSMENT OBJECTIVES [a] the confidentiality of CUI at rest is protected.

More Practice Details...

System and Information Integrity (SI)

SI.L2-3.14.1 – Flaw Remediation [CUI Data]

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.

More Practice Details...

SI.L2-3.14.2 – Malicious Code ProTection [CUI Data]

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.

More Practice Details...

SI.L2-3.14.3 – Security Alerts & Advisories

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.

More Practice Details...

SI.L2-3.14.4 – Update Malicious Code Protection [CUI Data]

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.

More Practice Details...

SI.L2-3.14.5 – System & File Scanning [CUI Data]

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.

More Practice Details...

SI.L2-3.14.6 – Monitor Communications for Attacks

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.

More Practice Details...

SI.L2-3.14.7 – Identify Unauthorized Use

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.

More Practice Details...

Appendix A – Acronyms and Abbreviations

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