CMMC Configuration Management: Requirements, Policy, and How to Document It
Configuration Management is one of the most consistently deficient practice families in CMMC Level 2 assessments. Not because the concepts are hard, but because organizations underestimate what "documented and enforced" actually means to a C3PAO assessor. Here's a complete breakdown of all 9 CM practices and what you need to demonstrate.
Why CM Gets So Many Organizations
Configuration Management sounds like a technical IT task, and it is. But CMMC treats it as a documentation and governance problem as much as a technical one. You can have hardened workstations, but if you can't produce a written baseline configuration document, evidence that you enforce it, and records of your change approval process, a C3PAO has to mark those practices as NOT MET.
The CM family covers 9 practices in NIST SP 800-171 Rev 2 3.4.1–3.4.9. All 9 must be MET for CMMC Level 2 certification. Let's walk through each one.
The 9 CMMC CM Practices
CM.L2-3.4.1
Establish and maintain baseline configurations and inventories of organizational systems
You must document the approved configuration for every major component in your CUI environment: OS version, installed software, enabled services, network topology, and security settings. This baseline becomes the reference point for detecting unauthorized changes.
Written baseline configuration document for each major technology type (workstations, servers, network devices)
Hardware and software inventory covering all in-scope systems
Evidence that baselines are reviewed at least annually
CM.L2-3.4.2
Establish and enforce security configuration settings for IT products
Define security hardening standards for each technology type in scope and enforce them consistently. DISA STIGs and CIS Benchmarks are the most widely accepted references. Enforcement should be automated where possible, Group Policy, Intune, Ansible, or similar tooling.
Security configuration standard or reference to DISA STIG/CIS Benchmark in use
Evidence of enforcement mechanism (GPO screenshots, Intune compliance report, etc.)
Process for handling deviations with documented justification
CM.L2-3.4.3
Track, review, approve or disapprove, and log changes to systems
This is your change management process, the formal workflow that any configuration change must go through before being implemented in the CUI environment. Without a documented, practiced process with approval records, this practice is NOT MET regardless of how good your technical controls are.
Written change management procedure describing the request, review, approval, and implementation steps
Change log or ticket system records showing approved changes
Evidence of the review and approval chain for recent changes
CM.L2-3.4.4
Analyze the security impact of changes prior to implementation
Before any change is approved, someone must assess the security implications. This doesn't require a full security review for every patch, but significant changes, new software, network changes, infrastructure modifications, need documented security impact consideration.
Security impact analysis field or step in your change management process
Sample records showing security impact was documented for recent significant changes
CM.L2-3.4.5
Define, document, approve, and enforce physical and logical access restrictions associated with changes
Not everyone should be able to make changes to CUI systems. This practice requires that the people authorized to implement changes are defined and documented, and that access controls enforce those boundaries.
Documentation of who is authorized to make system changes
Evidence that access is restricted to authorized individuals (RBAC, privileged account controls)
CM.L2-3.4.6
Employ the principle of least functionality
Systems in your CUI environment should be configured to provide only essential capabilities. Everything not needed for the mission, services, features, ports, protocols, should be disabled or removed. This is one of the most impactful security controls in the CM family from an attack surface reduction standpoint.
Policy statement establishing least functionality as a configuration requirement
Evidence of service/port hardening (firewall rules, disabled services list)
Process for reviewing and approving any exceptions
CM.L2-3.4.7
Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services
This overlaps with 3.4.6 but is more operational, the active enforcement of least functionality through technical controls. Assessors look for evidence that you've actually implemented restrictions, not just written a policy about them.
Firewall rules blocking unused ports and protocols
Disabled Windows features/services documentation
Application control or allowlisting configuration evidence
CM.L2-3.4.8
Apply deny-by-exception (blacklisting) policy to prevent use of unauthorized software
At minimum, maintain a list of software explicitly prohibited on CUI systems, with a process to detect and remediate violations. More mature implementations use application allowlisting (only approved software can execute). Note: the practice says "deny-by-exception" which in NIST terminology means a blacklist approach, but allowlisting is considered a stronger implementation.
Written policy defining unauthorized software categories
List of explicitly prohibited software (at minimum) or allowlist (preferred)
Evidence of enforcement or monitoring mechanism
CM.L2-3.4.9
Control and monitor user-installed software
Users should not be able to install software on CUI systems without authorization. This requires both a policy prohibiting unauthorized installation and a technical control that either prevents it or detects and alerts on it. Standard user accounts (non-admin) cover the prevention side for most scenarios.
Evidence that standard users lack admin rights on CUI systems
Monitoring capability to detect user-installed software (endpoint tool, periodic audit)
What Assessors Actually Look For
In a CMMC Level 2 assessment, the CM family assessment typically involves:
Document review: Your CM policy, baseline configuration documents, change log, and security configuration standards are all requested upfront.
Interviews: Assessors will ask your IT staff to walk through the change management process, describe how configurations are enforced, and explain what happens when an unauthorized change is detected.
Technical observation: Assessors may request to see your configuration management tooling in operation, review firewall rules, check for disabled services on a sample workstation, or review your software inventory tool.
The gap most organizations miss: Having a good change management process in your ticketing system and a written CM policy, but no documented baseline configuration. Assessors need all three: the policy (governing intent), the baseline (the specific approved state), and the process evidence (proof it's being practiced). Missing any one of them results in NOT MET findings.
CMMC Documentation That Holds Up to Assessment
Our CMMC Level 2 templates are written by practitioners who've been through real CMMC implementations, structured the way assessors expect to see them, not the way a generic template generator would produce them.
CMMC Level 2 includes 9 CM practices from NIST 800-171 Rev 2: CM.L2-3.4.1 (baseline configurations and inventory), CM.L2-3.4.2 (security configuration settings), CM.L2-3.4.3 (track and log changes), CM.L2-3.4.4 (analyze security impact of changes), CM.L2-3.4.5 (access restrictions for changes), CM.L2-3.4.6 (least functionality), CM.L2-3.4.7 (restrict nonessential programs/ports/services), CM.L2-3.4.8 (deny-by-exception policy), and CM.L2-3.4.9 (control user-installed software). All 9 must be MET for CMMC Level 2 certification.
A baseline configuration is a documented, approved set of specifications for an information system or component, capturing the system's approved state at a specific point in time. For CM.L2-3.4.1, baselines must cover OS versions, installed software, enabled services, network configurations, and security settings for all components in the CUI boundary. Baselines must be reviewed when systems change significantly and at least annually.
CM.L2-3.4.2 requires establishing and enforcing security hardening standards for each technology in your CUI environment. DISA STIGs and CIS Benchmarks are the most widely accepted references that satisfy this practice. Configuration enforcement should be automated through Group Policy, Intune, Ansible, or similar tooling, and any deviations require documented justification.
You need: a Configuration Management Policy, baseline configuration documents for each major technology type in scope, a security configuration standard or STIG/CIS Benchmark reference, a change management procedure with approval records and change log, a software inventory or authorized software list, evidence of least functionality implementation, and records showing configuration monitoring. Assessors look for both policy documentation and operational evidence.
CM.L2-3.4.6 requires configuring systems to provide only essential capabilities, disabling functions, ports, protocols, and services not needed for the mission. In practice: disable unused Windows features and services, block unused network ports at the firewall, remove software with no business purpose, and apply application control to prevent unauthorized executables. Anything not explicitly needed should be disabled by default.
CM.L2-3.4.8 requires a deny-by-exception (blacklist) approach at minimum, meaning you maintain a list of explicitly prohibited software and enforce it. Allowlisting (where only approved software can execute, everything else is blocked by default) is a stronger implementation of the same principle and is considered a more mature approach. NIST 800-171 uses "deny-by-exception" to mean the blacklist baseline, but assessors will view allowlisting as a stronger demonstration of the practice.
Bottom Line
Configuration Management is one of those practice families where the gap between "we do this in practice" and "we can prove we do this in practice" is enormous. The technical controls are usually in better shape than the documentation. Before your assessment, make sure you have written baseline documents, a functioning change management process with records, and evidence of enforcement, not just the controls themselves.
The CM family is also foundational: a well-implemented CM program makes the access control, incident response, and audit and accountability practices significantly easier to demonstrate, because you know exactly what's in your environment at all times.
📬
Get CMMC tips and template updates
No spam. Just practical guidance on CMMC compliance and new resources when we publish them.