CM-3: Configuration Change Control

Quick-reference card

What this control requires

CM-03 requires organizations to formally propose, evaluate, approve, and document every change made to their information systems. Without this control, modifications to system configurations happen ad hoc, introducing security gaps that go undetected until an auditor or an attacker finds them.

In practice, this means your organization needs to define which types of changes qualify as configuration-controlled, then route each proposed change through a structured review that explicitly weighs security and privacy impacts. You implement approved changes and log them, and you document disapproved changes with the rationale for rejection.

A designated body, typically a configuration control board (CCB) or change advisory board (CAB), coordinates this oversight and convenes on a defined schedule or when specific conditions trigger a review cycle.

Specifically, the control requires you to retain records of every configuration-controlled change and to monitor activities tied to those changes over time. This retention and monitoring requirement connects CM-03 directly to your broader NIST SP 800-53 compliance program by creating the audit trail that multiple other controls depend on.

Why it matters

Uncontrolled configuration changes are one of the highest-frequency root causes behind audit findings in federal and regulated environments. When changes bypass a formal review process, organizations lose visibility into what was modified, why it was modified, and whether anyone assessed the security impact before the change went live.

That loss of visibility creates compounding risk. A single undocumented firewall rule change can silently expose internal services. An unreviewed software update can introduce a vulnerability that remains undetected for months. Without change records, incident responders lack the baseline they need to determine what “normal” looked like before a compromise.

When change control fails, attackers gain predictable footholds:

• Unreviewed changes that open network ports or weaken access controls
• Missing change records that prevent detection of unauthorized modifications
• Gaps between change approval and change implementation that allow scope creep
• Lack of post-implementation monitoring that lets malicious changes persist
• Absent coordination between development, operations, and security teams during system upgrades

Beyond the threat landscape, CM-03 failures create direct audit exposure. Assessors look for documented evidence that every change followed your approved process. Missing records or inconsistent approvals result in findings that can delay or block your authorization to operate (ATO).

In practice, organizations that treat change control as a checkbox exercise often discover the gap during their first real audit. Building the process correctly from the start, with clear roles, defined triggers, and retained evidence, prevents that outcome. A solid NIST 800-53 compliance checklist can help you confirm nothing gets missed.

How to implement

For your organization

Start by defining the scope of configuration-controlled changes in your configuration management plan. Not every change needs formal review. Identify the categories that carry security or privacy impact, such as changes to baseline configurations, operating system updates, network topology modifications, access control rule changes, and vulnerability remediation actions.

Once scope is defined, stand up a configuration control board or change advisory board with representatives from security, operations, privacy, and, when applicable, development. Define the cadence for scheduled meetings and the criteria that trigger ad hoc sessions. Document the charter, membership, and escalation paths.

With the board established, build a change request workflow that captures the following for every proposed change:

• Description of the change and its justification
• Security and privacy impact analysis
• Approval or disapproval decision with rationale
• Implementation plan and rollback procedure
• Post-implementation verification results

In parallel, retain all change records according to your organization’s defined retention period and monitor change activities continuously. Your configuration management policy should specify the minimum retention duration aligned with your compliance obligations and organizational risk tolerance.

The result is a complete audit trail. Audit logs should capture who submitted, reviewed, approved, and implemented each change, and periodic reviews of change control records help identify process drift before it becomes an audit finding.

Certain implementation choices consistently create audit exposure:

• Defining scope too narrowly and excluding infrastructure changes that carry security impact
• Convening the CCB on a fixed schedule without a mechanism for urgent, out-of-cycle reviews
• Documenting approvals but not disapprovals, which leaves gaps in the decision record
• Treating emergency changes as exempt from documentation rather than documenting them retroactively

For your vendors

When your vendors process, store, or transmit your data, their configuration change practices affect your risk posture. Assessing CM-03 compliance in your supply chain requires targeted questions and evidence requests.

When assessing a vendor’s CM-03 posture, ask targeted questions across their change lifecycle:

• Do you maintain a formal configuration change control process for systems that handle our data?
• How do you assess security and privacy impact before approving configuration changes?
• What body or role has authority to approve or reject proposed changes?
• How long do you retain configuration change records?
• How do you handle emergency or out-of-cycle changes?

Supporting your assessment requires documentary evidence across several areas:

• Configuration management policy and change control procedures
• Sample change request records showing the full lifecycle from proposal through implementation
• CCB or CAB meeting minutes from the past 12 months
• Audit reports covering change control activities

Certain responses indicate a vendor’s change control process is inadequate:

• No formal change control board or designated approval authority
• Change records that lack security impact analysis
• Emergency change procedures that bypass documentation entirely
• No defined retention period for change records
• Inability to produce sample change requests when asked

Verify vendor claims by cross-referencing their SOC 2 Type II report or ISO 27001 certification against the evidence they provide. A vendor that claims to follow ISO 27001 change management practices but cannot produce change request samples or meeting minutes warrants deeper scrutiny.

Evidence examples

Cross-framework mapping

Related controls

• CA-07 (Continuous Monitoring) provides the ongoing assessment activities that verify configuration changes don’t degrade the security posture over time
• CM-02 (Baseline Configuration) establishes the documented system baseline that CM-03 change requests are measured against
• CM-04 (Impact Analyses) requires the security and privacy impact analysis that CM-03 mandates as part of change approval
• CM-05 (Access Restrictions for Change) limits who can execute approved changes, enforcing separation of duties within the CM-03 workflow
• CM-06 (Configuration Settings) defines the specific parameter values that configuration-controlled changes must preserve or deliberately modify
• CM-09 (Configuration Management Plan) documents the overarching plan that governs how CM-03 processes, roles, and tools operate
• CM-11 (User-installed Software) addresses a category of changes that CM-03 change control processes must account for
• IA-03 (Device Identification and Authentication) ensures that devices introducing configuration changes are authenticated before modifications proceed
• MA-02 (Controlled Maintenance) governs maintenance activities that involve configuration changes subject to CM-03 review
• PE-16 (Delivery and Removal) controls the physical introduction or removal of system components that trigger configuration-controlled changes

Frequently asked questions

What is NIST SP 800-53 CM-03

CM-03 is the NIST SP 800-53 control that requires organizations to establish a formal process for proposing, reviewing, approving, documenting, and monitoring all configuration-controlled changes to information systems. It applies to moderate and high baselines and mandates that a designated oversight body, such as a CCB, coordinate change control activities on a defined schedule.

What happens if CM-03 is not implemented

Organizations without CM-03 controls face audit findings that can delay or block authorization to operate. Assessors specifically check for documented change request records, security impact analyses, and evidence that a formal approval body reviewed each change. Missing any of these elements results in a control deficiency that must be remediated before the system receives authorization.

How do you audit CM-03

Auditors verify CM-03 by examining configuration management policies, reviewing a sample of change request records for completeness, confirming that security and privacy impact analyses accompany each change, and checking that the configuration management plan identifies a designated change control body. They also review CCB meeting minutes and audit logs to confirm that change activities are monitored and that the oversight body convenes at the frequency defined in the plan.

What is a configuration control board

A configuration control board is a designated group responsible for reviewing, approving, or rejecting proposed configuration changes to information systems. The board typically includes representatives from security, operations, privacy, and development, and it convenes on a scheduled basis or when specific conditions require an out-of-cycle review. CM-03 requires organizations to identify this oversight body and define its operating cadence.