CMMC configuration management change control audit requirements are the ones I watch trip up otherwise well-prepared contractors, assessment after assessment. Here’s a question I ask during every readiness engagement: “Show me your current system configuration. Show me what it looked like 90 days ago. Show me the changes in between.” Most companies can’t do it — and that three-part question is essentially the assessment. This article breaks down what configuration management actually requires under CMMC, why partial implementations fail, and the methodical (not sophisticated) process that passes.
Why Configuration Management Gets Misunderstood
The configuration management family in NIST SP 800-171 asks for something conceptually simple: know what your systems should look like, control how they change, and verify they still look that way. Baselines, change control, audits. Three legs of one stool.
The misunderstanding is treating the first leg as the whole stool. Most contractors I assess have configuration baselines — often good ones, hardening guides applied at build time, documented somewhere in the wiki. Very few have the change control logs connecting those baselines to the present day. Almost none have regular audit documentation proving anyone ever checked whether reality still matches the baseline. One leg out of three doesn’t hold weight, and assessors know exactly where to push.
Think about what an unverified baseline actually is: a description of how a system looked on the day someone wrote the document. Six months of patches, hotfixes, vendor updates, and Friday-afternoon tweaks later, that document describes a system that no longer exists. Without change records and audits, you don’t have configuration management — you have configuration archaeology.
The Three Artifacts a CMMC Configuration Management Change Control Audit Examines
- Documented baselines for every system in the CUI boundary: operating system settings, installed software, network configuration, and access parameters. Approved, dated, and versioned — when the baseline changes, the change itself goes through change control.
- Change control records — a ticket trail for every production change: who requested it, who approved it, what was tested, when it deployed. The rule that makes this work is brutal in its simplicity: no ticket, no change.
- Audit documentation — recurring, dated comparisons of live systems against baselines, with the deviations found and what happened to them. This is the leg that proves the other two aren’t fiction.
Building the Process: Methodical Beats Sophisticated
Here’s the fix I give clients, and I want to be honest about how unglamorous it is. Document the current configuration for your critical systems. Establish a change request process. Conduct one audit and document it. Repeat monthly. That’s not sophisticated. It’s methodical — and it’s the difference between passing and failing configuration management during assessment.
Start with scope discipline. You don’t need enterprise configuration management across every laptop in the building. You need it for the systems inside your CUI boundary — the file server holding contract drawings, the workstations that touch it, the network gear between them. For a typical Tier 2 or Tier 3 contractor that’s a dozen or two systems, not hundreds. Scoping this correctly is the same exercise that anchors the 90-day CMMC readiness roadmap: secure what handles CUI, don’t boil the ocean.
For baselines, don’t write from scratch. Start from an established hardening reference — the CIS Benchmarks are free and map well to 800-171 expectations — then document your deviations with justifications. A baseline that says “CIS Windows Server benchmark, level 1, with these five documented exceptions” is stronger and faster than a hundred pages of homegrown settings.
For change control, use whatever ticketing you already have. The workflow needs four fields: what’s changing, why, who approved it, and how it was verified. Email approvals scattered across inboxes fail assessments — not because email is forbidden, but because you can’t produce a coherent trail from it under time pressure.
The Monthly Audit: Thirty Minutes That Passes Assessments
The audit leg is where contractors overcomplicate and then abandon the whole effort. Here’s the version that works: once a month, pick your CUI-critical systems, compare live configuration against the baseline — configuration export diffs, or a scanning tool if you have one — and write down three things. What matched. What deviated. What you did about the deviations. Date it, sign it, file it.
Every deviation lands in one of two buckets: it went through change control and the baseline needs updating, or it didn’t and you’ve caught unauthorized drift — which is the control working, not the control failing. Assessors love seeing caught-and-corrected drift in audit records. It’s the single strongest signal that your configuration management is a living process rather than a binder. Twelve monthly audit records with a handful of caught deviations beats a perfect-looking program with no audit trail every single time.
Your First 60 Days
Weeks 1–2: inventory the CUI boundary systems and adopt a baseline reference for each platform. Weeks 3–4: document baselines with your justified deviations, and stand up the change ticket workflow — announce the no-ticket-no-change rule and mean it. Weeks 5–6: run your first audit; expect it to be messy and to surface drift, because that’s the point. Weeks 7–8: process what the audit found, update baselines through the new change process, and calendar the monthly cycle. From that point forward, every month generates another dated artifact — and by assessment time, you’re the contractor who answers “show me 90 days ago” by opening a folder.
Configuration management rewards the organizations that start early and punish the ones that cram, because the evidence only accumulates on the calendar. If you want an honest read on whether your baselines, change logs, and audits would survive a C3PAO’s three-part question, schedule a discovery call — we’ll run the question against your environment before an assessor does.