Configuration Management (CM)¶
Domain: Configuration Management (CM)
Requirements in this domain: 9
Assessment Objectives in this domain: 44
CM.L2-3.4.1¶
CM.L2-3.4.1[a]¶
Assessment Objective
a baseline configuration is established.
Collection Approach: Document
Potential Evidence Examples
Documented baseline configuration (e.g., golden/master image build sheet, hardening standard, or configuration management document) describing the standard, approved configuration for system components, and where/how it is deployed.
Assessment Guide – Further Discussion
Do baseline configurations include software versions and patch level, configuration parameters, network information, and communications with connected systems [a,b]?
CM.L2-3.4.1[b]¶
Assessment Objective
the baseline configuration includes hardware, software, firmware, and documentation.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the image/configuration repository (e.g., SCCM, imaging server, IaC template repo) showing the baseline captures hardware specifications, installed software/firmware versions, and associated configuration documentation — not just the OS image.
Assessment Guide – Further Discussion
Do baseline configurations include software versions and patch level, configuration parameters, network information, and communications with connected systems [a,b]?
CM.L2-3.4.1[c]¶
Assessment Objective
the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle.
Collection Approach: Artifact
Potential Evidence Examples
Change records or CCB minutes showing the baseline configuration is periodically reviewed and updated across the system development life cycle (e.g., after major patches, upgrades, or architecture changes), with the review cadence stated in policy.
Assessment Guide – Further Discussion
Are baseline configurations updated as needed to accommodate security risks or software changes [c]?
CM.L2-3.4.1[d]¶
Assessment Objective
a system inventory is established.
Collection Approach: Document
Potential Evidence Examples
Current system inventory (asset management or CMDB export) listing approved hardware/software components authorized for use in the environment.
CM.L2-3.4.1[e]¶
Assessment Objective
the system inventory includes hardware, software, firmware, and documentation.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the inventory/CMDB showing entries include hardware, software, firmware, and version/documentation details — not just device names.
CM.L2-3.4.1[f]¶
Assessment Objective
the inventory is maintained (reviewed and updated) throughout the system development life cycle.
Collection Approach: Artifact
Potential Evidence Examples
Evidence the inventory is kept current — e.g., a change log, scheduled reconciliation report, or discovery-scan comparison showing the inventory is reviewed/updated at the defined frequency throughout the system lifecycle.
CM.L2-3.4.2¶
CM.L2-3.4.2[a]¶
Assessment Objective
security configuration settings for information technology products employed in the system are established and included in the baseline configuration.
Collection Approach: Document
Potential Evidence Examples
Document describing the organization's hardening methodology (e.g., DISA STIGs, CIS Benchmarks) and confirming those settings are incorporated into the baseline configuration/image.
Assessment Guide – Further Discussion
Do security settings reflect the most restrictive settings appropriate [a]?
CM.L2-3.4.2[b]¶
Assessment Objective
security configuration settings for information technology products employed in the system are enforced.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of a configuration-enforcement/compliance tool (e.g., SCCM compliance baseline, STIG viewer/SCAP scan results, GPO settings) showing the defined security configuration settings are actively enforced and drift is detected.
Assessment Guide – Further Discussion
Are changes or deviations to security settings documented [b]?
CM.L2-3.4.3¶
CM.L2-3.4.3[a]¶
Assessment Objective
changes to the system are tracked.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the IT Service Management (ITSM) tool (e.g., ServiceNow, Jira) showing change requests are logged and tracked from submission through closure.
Assessment Guide – Further Discussion
Are changes to the system authorized by company management and documented [a,b,c,d]?
CM.L2-3.4.3[b]¶
Assessment Objective
changes to the system are reviewed.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the ITSM tool or Change Advisory Board (CAB) record showing evidence that submitted changes are reviewed (e.g., technical/security review comments or CAB discussion notes) prior to approval.
Assessment Guide – Further Discussion
Are changes to the system authorized by company management and documented [a,b,c,d]?
CM.L2-3.4.3[c]¶
Assessment Objective
changes to the system are approved or disapproved.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the ITSM tool showing a change record's approval/disapproval decision and approving authority, demonstrating changes cannot proceed without formal sign-off.
Assessment Guide – Further Discussion
Are changes to the system authorized by company management and documented [a,b,c,d]?
CM.L2-3.4.3[d]¶
Assessment Objective
changes to the system are logged.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of the ITSM tool's change log/history showing implemented changes are recorded with date, description, and implementer — providing an auditable change history.
Assessment Guide – Further Discussion
- Are changes to the system authorized by company management and documented [a,b,c,d]?
- Are changes documented and tracked (e.g., manually written down or included in a tracking service such as a ticketing system) [d]?
CM.L2-3.4.4¶
CM.L2-3.4.4[a]¶
Assessment Objective
the security impact of changes to each organizational system is analyzed prior to implementation.
Collection Approach: Artifact
Potential Evidence Examples
Sampled change record (ticket or CCB packet) showing a security impact analysis was performed and documented before the change was implemented — e.g., a security-impact-analysis field/attachment completed prior to the approval step.
Assessment Guide – Further Discussion
Are configuration changes tested, validated, and documented before installing them on the operational system [a]?
CM.L2-3.4.5¶
CM.L2-3.4.5[a]¶
Assessment Objective
physical access restrictions associated with changes to the system are defined.
Collection Approach: Document
Potential Evidence Examples
Policy or SOP defining who may authorize physical access to areas/systems where configuration changes can be made (e.g., server room, network closet) and the criteria for granting that access.
Assessment Guide – Further Discussion
- Are only employees who are approved to make physical or logical changes on systems allowed to do so [a,d,e,h]?
- Are authorized personnel approved and documented by the service owner and IT security [a,e]?
CM.L2-3.4.5[b]¶
Assessment Objective
physical access restrictions associated with changes to the system are documented.
Collection Approach: Document
Potential Evidence Examples
Documented physical-access-request/approval process (e.g., badge-access request form) tied specifically to systems where changes can be made, showing how the restriction defined in [a] is formally recorded.
Assessment Guide – Further Discussion
Does all change documentation include the name of the authorized employee making the change [b,d,f,h]?
CM.L2-3.4.5[c]¶
Assessment Objective
physical access restrictions associated with changes to the system are approved.
Collection Approach: Artifact
Potential Evidence Examples
Sampled physical access request showing management/owner approval was obtained before badge/key access to change-capable areas was granted.
CM.L2-3.4.5[d]¶
Assessment Objective
physical access restrictions associated with changes to the system are enforced.
Collection Approach: Physical Review
Potential Evidence Examples
Physical access control system report (e.g., badge reader log, key/lock inventory) confirming physical access to systems where changes can be made is actually restricted to the approved individuals — i.e., the control is enforced, not just documented.
Assessment Guide – Further Discussion
- Are only employees who are approved to make physical or logical changes on systems allowed to do so [a,d,e,h]?
- Does all change documentation include the name of the authorized employee making the change [b,d,f,h]?
CM.L2-3.4.5[e]¶
Assessment Objective
logical access restrictions associated with changes to the system are defined.
Collection Approach: Document
Potential Evidence Examples
Policy or SOP defining who may authorize logical (system/account-level) access needed to make configuration changes (e.g., who can request elevated change-management rights).
Assessment Guide – Further Discussion
- Are only employees who are approved to make physical or logical changes on systems allowed to do so [a,d,e,h]?
- Are authorized personnel approved and documented by the service owner and IT security [a,e]?
CM.L2-3.4.5[f]¶
Assessment Objective
logical access restrictions associated with changes to the system are documented.
Collection Approach: Document
Potential Evidence Examples
Documented logical-access-request/approval process specific to change-capable accounts/roles (e.g., CCB member or deployment-tool access), showing the restriction defined in [e] is formally recorded.
Assessment Guide – Further Discussion
Does all change documentation include the name of the authorized employee making the change [b,d,f,h]?
CM.L2-3.4.5[g]¶
Assessment Objective
logical access restrictions associated with changes to the system are approved.
Collection Approach: Artifact
Potential Evidence Examples
Sampled logical access request/ticket showing management approval was obtained before an account was granted rights to make system changes.
CM.L2-3.4.5[h]¶
Assessment Objective
logical access restrictions associated with changes to the system are enforced.
Collection Approach: Artifact
Potential Evidence Examples
Screen share of group membership/permissions in the change-management or deployment tool (e.g., SCCM, CI/CD pipeline, network configuration management system) confirming logical access to make changes is enforced and limited to approved individuals.
Assessment Guide – Further Discussion
- Are only employees who are approved to make physical or logical changes on systems allowed to do so [a,d,e,h]?
- Does all change documentation include the name of the authorized employee making the change [b,d,f,h]?
CM.L2-3.4.6¶
CM.L2-3.4.6[a]¶
Assessment Objective
essential system capabilities are defined based on the principle of least functionality.
Collection Approach: Document
Potential Evidence Examples
Document describing how the organization applies the principle of least functionality (e.g., a hardening standard specifying only required services/roles are enabled per system role/function).
Assessment Guide – Further Discussion
- Are the roles and functions for each system identified along with the software and services required to perform those functions [a]?
- Are the software and services required for those defined functions identified [a]?
CM.L2-3.4.6[b]¶
Assessment Objective
the system is configured to provide only the defined essential capabilities.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of system configuration (e.g., Server Manager roles/features, CIS Benchmark scan result) showing unneeded services, ports, and functions have been disabled consistent with the least-functionality standard.
Assessment Guide – Further Discussion
Is the information system configured to exclude any function not needed in the operational environment [b]?
CM.L2-3.4.7¶
CM.L2-3.4.7[a]¶
Assessment Objective
essential programs are defined.
Collection Approach: Document
Potential Evidence Examples
Build documentation, software catalog, or SSP appendix listing the essential programs approved for use on in-scope systems.
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[b]¶
Assessment Objective
the use of nonessential programs is defined.
Collection Approach: Document
Potential Evidence Examples
Acceptable Use Policy or software standard explicitly identifying nonessential programs that are not permitted (i.e., anything outside the essential-programs list from [a]).
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[c]¶
Assessment Objective
the use of nonessential programs is restricted, disabled, or prevented as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of an application-control tool (e.g., AppLocker, Carbon Black, endpoint allow-listing console) showing nonessential programs are actively blocked/disabled from executing.
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[d]¶
Assessment Objective
essential functions are defined.
Collection Approach: Document
Potential Evidence Examples
Build documentation or configuration standard listing the essential system functions/roles permitted on in-scope systems.
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[e]¶
Assessment Objective
the use of nonessential functions is defined.
Collection Approach: Document
Potential Evidence Examples
Configuration standard or policy identifying nonessential functions that must be disabled (outside the essential-function list from [d]).
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[f]¶
Assessment Objective
the use of nonessential functions is restricted, disabled, or prevented as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of system/GPO configuration showing nonessential functions identified in [e] are actually disabled or restricted.
Assessment Guide – Further Discussion
Are only applications and services that are needed for the function of the system configured and enabled [a,b,c,d,e,f]?
CM.L2-3.4.7[g]¶
Assessment Objective
essential ports are defined.
Collection Approach: Document
Potential Evidence Examples
Firewall/network standard or SSP listing the essential ports required for business operations on in-scope systems.
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[h]¶
Assessment Objective
the use of nonessential ports is defined.
Collection Approach: Document
Potential Evidence Examples
Firewall/network standard identifying nonessential ports that must remain closed (outside the essential-port list from [g]).
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[i]¶
Assessment Objective
the use of nonessential ports is restricted, disabled, or prevented as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of host/network firewall rules or GPO settings showing nonessential ports are blocked/disabled consistent with the standard.
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[j]¶
Assessment Objective
essential protocols are defined.
Collection Approach: Document
Potential Evidence Examples
Network/security standard listing the essential protocols permitted on in-scope systems.
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[k]¶
Assessment Objective
the use of nonessential protocols is defined.
Collection Approach: Document
Potential Evidence Examples
Network/security standard identifying nonessential protocols that must be restricted or disabled (outside the essential-protocol list from [j]).
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[l]¶
Assessment Objective
the use of nonessential protocols is restricted, disabled, or prevented as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of firewall rules or GPO settings showing nonessential protocols identified in [k] are actually blocked/disabled.
Assessment Guide – Further Discussion
Are only those ports and protocols necessary to provide the service of the information system configured for that system [g,h,i,j,k,l]?
CM.L2-3.4.7[m]¶
Assessment Objective
essential services are defined.
Collection Approach: Document
Potential Evidence Examples
Server/service configuration standard listing the essential services required to run on in-scope systems.
Assessment Guide – Further Discussion
Are systems services reviewed to determine what is essential for the function of that system [m]?
CM.L2-3.4.7[n]¶
Assessment Objective
the use of nonessential services is defined.
Collection Approach: Document
Potential Evidence Examples
Configuration standard identifying nonessential services that must be disabled (outside the essential-service list from [m]).
CM.L2-3.4.7[o]¶
Assessment Objective
the use of nonessential services is restricted, disabled, or prevented as defined.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of service configuration (e.g., Windows Services console, systemctl output, or endpoint-management console) showing nonessential services identified in [n] are stopped/disabled.
CM.L2-3.4.8¶
CM.L2-3.4.8[a]¶
Assessment Objective
a policy specifying whether whitelisting or blacklisting is to be implemented is specified.
Collection Approach: Document
Potential Evidence Examples
Policy stating whether the organization implements allow-listing (default-deny, only approved software runs) or deny-listing (default-allow, only specified software is blocked), and the rationale for that approach.
Assessment Guide – Further Discussion
- Is the authorization policy a deny-all, permit by exception for software allowed to execute on the system [a,b,c]?
- Is the information system configured to only allow authorized software to run [a,b,c]?
- Is the system configured to disallow running unauthorized software [a,b,c]?
- Are automated mechanisms used to prevent program execution in accordance with defined lists (e.g., white listing) [a,b,c]?
CM.L2-3.4.8[b]¶
Assessment Objective
the software allowed to execute under whitelisting or denied use under blacklisting is specified.
Collection Approach: Document
Potential Evidence Examples
The specific allow-list of approved software (for allow-listing) or deny-list of prohibited software (for deny-listing), maintained and kept current.
Assessment Guide – Further Discussion
- Is the authorization policy a deny-all, permit by exception for software allowed to execute on the system [a,b,c]?
- Is the information system configured to only allow authorized software to run [a,b,c]?
- Is the system configured to disallow running unauthorized software [a,b,c]?
- Are automated mechanisms used to prevent program execution in accordance with defined lists (e.g., white listing) [a,b,c]?
CM.L2-3.4.8[c]¶
Assessment Objective
whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the application-control tool (e.g., Carbon Black, AppLocker, Windows Defender Application Control, DNS sinkhole, or web proxy category block) enforcing the allow-list or deny-list as configured, ideally showing a blocked execution attempt.
Assessment Guide – Further Discussion
- Is the authorization policy a deny-all, permit by exception for software allowed to execute on the system [a,b,c]?
- Is the information system configured to only allow authorized software to run [a,b,c]?
- Is the system configured to disallow running unauthorized software [a,b,c]?
- Are automated mechanisms used to prevent program execution in accordance with defined lists (e.g., white listing) [a,b,c]?
CM.L2-3.4.9¶
CM.L2-3.4.9[a]¶
Assessment Objective
a policy for controlling the installation of software by users is established.
Collection Approach: Document
Potential Evidence Examples
Software Installation Policy describing who may install software and the approval process required before installation is permitted.
Assessment Guide – Further Discussion
Are user controls in place to prohibit the installation of unauthorized software [a]?
CM.L2-3.4.9[b]¶
Assessment Objective
installation of software by users is controlled based on the established policy.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of the technical control enforcing that policy — e.g., standard users lack local admin rights (UAC/GPO restriction), or a self-service software portal requires pre-approved catalog selection.
Assessment Guide – Further Discussion
Is all software in use on the information systems approved [b]?
CM.L2-3.4.9[c]¶
Assessment Objective
installation of software by users is monitored.
Collection Approach: Screen Share
Potential Evidence Examples
Screen share of a software-deployment/inventory tool (e.g., SCCM, Software Center, endpoint management console) showing installed software is monitored/reported against the approved list, surfacing unauthorized installations.
Assessment Guide – Further Discussion
Is there a mechanism in place to monitor the types of software a user is permitted to download (e.g., is there a white list of approved software) [c]?