Configuration management.

01What this family protects

Configuration Management protects the gap between what a system is supposed to be and what it’s actually become. Every unreviewed change, every default setting left in place, every unnecessary service still running is a small deviation from the documented baseline — and deviations are where unexpected weaknesses tend to hide, not because anyone did anything wrong, but because nobody was tracking the drift.

02The rule says

All 9 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.4 has the full text and discussion for each; Source Library covers when to open it.

03In practice

Baselines and inventory (3.4.1). A documented starting point for what “normal” looks like on a system or component — what hardware, software, firmware, and configuration it’s supposed to have — maintained as systems change, not written once at setup and left to drift.

Configuration settings (3.4.2). Security-relevant settings — account and file permissions, which ports and protocols are open, remote-connection settings — set deliberately and consistently rather than left at manufacturer defaults, which are built for ease of setup, not security.

Change control (3.4.3–3.4.5). Changes to a system get tracked, reviewed, and approved before they happen rather than made ad hoc, with a security-impact check (3.4.4) before implementation and access to make changes restricted to people who are actually authorized to make them (3.4.5). For a small shop this can be a lightweight process — a short approval step and a log — rather than a formal change advisory board.

Least functionality (3.4.6–3.4.8). Systems configured to do only what they need to do: unnecessary programs, ports, protocols, and services disabled or removed (3.4.6–3.4.7), and software execution controlled by policy — deny known-bad, permit-by-exception is the stronger of the two approaches the rule allows (3.4.8).

User-installed software (3.4.9). A defined policy on what employees can and can’t install themselves, enforced in whatever way fits the organization — technical controls, a clear written policy, or both.

04Where it fails

Most often, the gap is a baseline that was accurate once, at setup, and has quietly drifted since — a workstation gets reimaged differently than its baseline called for, or a server picks up a one-off configuration change during a support call that never gets folded back into the documented standard.

A second gap is change control that exists on paper but not in practice: a documented approval process that changes routinely skip because the person making the change is also the person who’d approve it, and there’s no one else to ask.

05What evidence may look like

A current system baseline or configuration standard, even a simple one, compared against what’s actually deployed; change-log entries or tickets showing changes were reviewed and approved before being made; a hardening checklist or configuration guide showing unnecessary services were deliberately disabled, not merely never turned on; and a written policy on user-installed software, with any enforcing technical controls noted.

06At the shop

07Commonly confused with

Access Control (AC). CM’s access restrictions for change (3.4.5) sound like AC’s account-and-privilege requirements, but they’re scoped narrowly to who may make configuration changes — a subset of AC’s broader question of who can access a system at all. See Access Control.

System & Information Integrity (SI). CM’s baseline and least-functionality requirements reduce what could go wrong in the first place; SI’s flaw-remediation and monitoring requirements deal with what happens once something does. See System & Information Integrity.

08Cross-desk links

None load-bearing for this family. Baselines, change control, and least functionality are CMMC-specific practices covered on this desk’s own family pages; see Access Control and System & Information Integrity.

09Sources