7.2 Configuration Management (CM) Domain: Baselines, Changes & Least Functionality

Configuration Management: Baselines, Changes & Least Functionality

Configuration Management contains nine Level 2 requirements. It establishes what the assessed system is, how it should be configured, how changes are controlled, and which functions and software may operate. It does not mandate one benchmark, change board, scan cadence, or configuration platform.

Baselines and inventories

Requirement 3.4.1 establishes and maintains baseline configurations and inventories of organizational systems, including hardware, software, firmware, and documentation, throughout their life cycles. The baseline describes the approved state; the inventory identifies the components to which it applies.

A baseline is not a one-time screenshot. It changes through controlled decisions and should match deployed versions, roles, locations, owners, and scope. Evidence can include approved configuration records, inventories, build definitions, version-control history, management-system exports, and representative endpoint or device comparisons.

Requirement 3.4.2 establishes and enforces security configuration settings for IT products used in organizational systems. CIS Benchmarks, DISA STIGs, vendor guidance, or organization-developed standards may help define settings. None is universally named as the required benchmark for every CMMC system. The organization documents the selected settings, justified deviations, and enforcement.

Change control

Requirement 3.4.3 tracks, reviews, approves or disapproves, and logs changes to organizational systems. A ticket can support the record, but the team must verify the technical change matches the authorized change and that emergency paths are controlled.

Requirement 3.4.4 analyzes the security impact of changes before implementation. The depth should fit the change: a firewall rule, identity integration, application update, cloud feature, or firmware replacement may affect scope and several requirements. A generic “no impact” checkbox without analysis is weak evidence.

Requirement 3.4.5 defines, documents, approves, and enforces physical and logical access restrictions associated with changes. This addresses who can make changes and through which controlled paths. It does not require one commercial privileged-access product.

Least functionality

Requirement 3.4.6 employs least functionality by configuring systems to provide only essential capabilities. 3.4.7 restricts, disables, or prevents the use of nonessential programs, functions, ports, protocols, and services. The organization determines what is essential and keeps that decision current.

A list of disfavored protocols is useful, but CMMC does not say every environment must use the same list. A legacy service may be prohibited, removed, isolated, or exceptionally authorized based on the facts; the team evaluates the actual requirement, risk-based justification, and protection rather than awarding credit for a template.

Software execution and installation

Requirement 3.4.8 applies either a deny-by-exception policy to prevent unauthorized software use or a deny-all, permit-by-exception policy to allow execution of authorized software. The control can operate through application control, package management, platform policy, or another supported mechanism.

Requirement 3.4.9 controls and monitors user-installed software. The organization defines which users and software are authorized, how installation occurs, how exceptions are approved, and how activity is detected or reviewed. Removing local administrator rights may help but does not by itself demonstrate the monitoring objective.

Evidence sequence

1. Reconcile the asset inventory, software/firmware inventory, SSP, scope, and network diagram.
2. Select representative systems and compare deployed settings with the approved baseline.
3. Trace recent normal and emergency changes from request through impact analysis, approval, implementation, validation, and log.
4. Inspect who can change physical and logical components.
5. Test representative disabled services or application-control outcomes.
6. Review user-installed software controls and detected activity.

Suppose a company cites a benchmark but its sampled endpoints differ from the approved values with no recorded exception. The benchmark is only a source; the deployed inconsistency and missing control decide the objectives. Conversely, a documented organization-specific baseline can satisfy the requirements when it is appropriate, enforced, and evidenced.

Scope-changing example

A team approves a new SaaS connector as a routine configuration change. The security-impact analysis should ask whether it transmits CUI or SPD, creates a CSP or ESP dependency, changes identity and logging paths, adds software, or alters the network diagram and SSP. If the ticket addresses only availability, approval did not establish the CMMC impact. Trace the implemented connector back to inventory, baseline, access restriction, execution policy, provider documentation, and updated scope artifacts.

A useful reconciliation table links each sampled asset to its inventory record, approved baseline version, deployed configuration, last controlled change, exception, and software-execution status. Differences are not automatically failures, but each difference needs an authorized and technically supported explanation. This makes drift, undocumented emergency changes, and scope-impacting integrations visible without imposing one commercial configuration tool.