Configuration Change Control CM-3

Configuration Management · Moderate baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds CM-3 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, Configuration Management family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

CM-3 (Configuration Change Control) is about putting proposed changes through a gate before they reach the running system. You decide which kinds of changes are controlled, review each one for security and privacy impact, approve or reject it on the record, carry out the approved change, and keep records of what was decided and done. It lives in the Moderate baseline, one step up from just having a policy.

What good looks like

Define which changes are controlled — for example, package installs, firewall rule edits, and changes to files under /etc — so everyone knows what needs approval.
Review before you change: weigh the security and privacy impact of each proposed change, then approve or reject it.
Record the decision — who asked, who approved, and why — not just the change itself.
Implement only approved changes, and keep the records for a defined period so you can trace what changed and when.
Monitor and review change activity, and route it through a single point of oversight — a change board, or in a small shop, a named approver.

Framework mapping

NIST CSF 2.0 — ID.RA-07 — Changes and exceptions are managed, assessed for risk impact, recorded, and tracked

How to move it toward Implemented

Start tracking /etc under version control so every change is recorded: cd /etc && sudo git init && sudo git add -A && sudo git commit -m ‘baseline’.
Keep a simple change log (a dated file or an issue tracker) with the request, the impact note, the approver, and the result for each controlled change.
For each change, commit the /etc diff with a message that names the approver and reason, so the record and the actual change stay together (sudo git commit -m ‘CHG-14: open 443, approved by ...’).
Set a retention period for those records (for example, keep the change log and git history for 12 months) and write it down.
Attach the change log and a sample of the version-controlled /etc history as hardening evidence on the asset, naming CM-3 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.