Configuration Management: Keeping Controls Honest After Testing Ends | MS Capital Resource Library
RMF · Control Selection

Configuration Management: Keeping Controls Honest After Testing Ends

6 min read · Updated [Date]

Key Takeaways

  • Configuration drift — the gap between what's documented and what's actually deployed — is the real risk, not any single misconfigured setting.
  • CM-2 (Baseline Configuration) and CM-6 (Configuration Settings) carry the most weight in assessments — they define what "normal" is supposed to look like.
  • CM isn't a one-time deliverable for the assessment. It's an ongoing process, with a real recurring time cost most teams underestimate.
Executive Summary

Configuration Management ensures systems are built, documented, and maintained securely throughout their lifecycle — inventory, baseline, change control, and version control. The organizations that struggle here almost never do so because they lack a CM policy on paper; they struggle because the policy stops matching reality the moment a change gets made without going through it. A patch applied without approval, a setting changed outside the documented process, a component nobody re-inventoried — each one, individually, seems minor. Together, they're what an assessor calls configuration drift, and it's one of the most common findings in a Security Assessment Report. If your CM Plan hasn't been checked against what's actually deployed recently, that gap is worth closing before an assessor closes it for you.

Busy executives can stop here. The full guide below is for the team maintaining the actual CM process.

The Full Guide

Configuration Management is one of the most foundational control families in any cyber program — and one of the most commonly under-invested in, because its failures are quiet. Nothing breaks visibly when documentation drifts out of sync with deployment. It just sits there, until an assessor tests it.

What CM Actually Covers

CM focuses on four things: inventory (knowing what you have), baseline configuration (knowing what "normal" looks like), change control (governing how that baseline changes), and version control (tracking the history of those changes). The control family runs from CM-1 through CM-11, but CM-2 and CM-6 carry the most practical weight — they're where drift actually gets caught in an assessment.

The Real Risk

The risk isn't any single misconfigured setting. It's the gap between what's documented and what's actually deployed — because that gap is where unauthorized changes, missed patches, and untracked components all hide. Configuration drift is the finding, not the individual change that caused it.

How to Keep CM Honest in Practice

  • Establish a Configuration Control Board (CCB) that actually meets and reviews changes — not one that exists on paper only.
  • Maintain version history for every configuration item, not just the ones that seem important.
  • Track updates with automated tools — SCCM, Tanium, or equivalent — rather than relying on manual logs that go stale.
  • Draft your SSPP's CM section from real evidence: actual tools, actual components, actual SOPs, actual change request logs attached.

Most CM problems trace back to poor logging or informal processes, not a lack of policy. Automation is what actually closes that gap — manual tracking degrades the moment nobody's watching closely.

A Real Example

A server patch gets applied without proper approval, and it causes downtime. The finding that results isn't really about the patch — it's a gap in CM-3 (Change Control) and CM-5 (Access Restrictions). That finding gets added to the Security Assessment Report and the POA&M. The lesson: the technical change usually isn't the problem. The missing approval step is.

Where Teams Get This Wrong

  • Informal or undocumented change processes that exist in practice but never in writing.
  • A CCB that exists on paper but doesn't actually meet or review anything.
  • Configuration drift that never gets reconciled back against documentation.
  • Treating CM as a one-time deliverable for the assessment, instead of the ongoing process it actually is.

The Real Time Cost

Set realistic expectations: a CM Plan typically takes 10–20 hours to build properly. Change tracking is ongoing, not a one-time task. The SSPP writeup itself usually takes 4–6 hours. And CCB scheduling and minutes represent a recurring monthly effort. CM is a living process — budgeting for it as a single deliverable is where the drift starts.

Where to Go From Here

The honest test: if you pulled your current CM Plan right now and compared it against what's actually deployed, would they match? If the answer is "probably not entirely," that's worth reconciling before an assessor does the comparison for you.

Choose Your Next Step

Doing This Yourself

Download the Template

Self-serve CM Plan drafting, with a full control family checklist referenced throughout.

Get the Template
Want an Expert

Talk to MS Capital

Have someone who's carried the accountability for this call before get it right the first time.

Book a Discovery Call
MS Capital, LLC