StealthTech
A network engineer at a manufacturing subcontractor once told us his configuration management program was “in his head, and it’s a good head.” He wasn’t wrong about the network. Every switch was hardened, every unused port disabled, every firewall rule justified by a business reason he could recite from memory. What he didn’t have was a single document that said any of that. When the assessment team asked for his baseline configuration for the CUI enclave, he had a working network and nothing to show for it on paper. That gap — between a system that works and a system that can prove it works, on demand, to someone who wasn’t there when it was built — is where most CM.L2 findings come from.
Configuration management is one of the least glamorous domains in NIST SP 800-171, and it’s also one of the most heavily assessed. It doesn’t get the attention that access control or incident response gets, because it doesn’t sound like a security control in the traditional sense. It sounds like paperwork. But a C3PAO assessor evaluating CM.L2 practices isn’t grading your network diagram for neatness — they’re testing whether your organization can demonstrate, with objective evidence, that the system in front of them today is the system you decided to build, and that every deviation from that decision was tracked, approved, and justified. “It works” answers a different question than the one being asked.
What CM.L2 Actually Requires
The configuration management domain under CMMC Level 2 maps to a specific set of practices drawn from NIST SP 800-171, and they build on each other in a way that’s easy to miss if you only skim the control titles. The requirement isn’t just “have configurations.” It’s a chain: establish a baseline, control changes to that baseline, restrict who can make those changes, enforce least functionality, and inventory what’s actually running. Miss one link and the rest of the chain doesn’t hold, because an assessor testing CM.L2 will trace that entire path during a readiness assessment.
In practice, that chain breaks down into a few concrete obligations:
- A documented baseline configuration for each system component type in CUI scope, current enough to reflect what’s deployed today, not what was deployed at go-live two years ago
- A formal change control process, with a record of who requested a change, who approved it, and what testing occurred before it reached production
- Configuration settings that reflect the most restrictive mode consistent with operational requirements, not vendor defaults
- Least functionality enforcement — disabling or removing ports, protocols, and services that aren’t tied to an approved business function
- An accurate, current inventory of information system components, tied back to the baseline it’s supposed to match
None of these practices exist in isolation. An organization that has strong technical hardening but no change log is still going to generate findings, because the assessor has no way to verify that the hardened state they’re looking at today is the same state that existed last month, or that any drift since then went through your process. The baseline is the artifact; the change record is the proof that the artifact stayed true.
Why “It Works” Fails as Evidence
Most IT teams, MSP-supported or internal, run configuration management informally and successfully for years. Systems stay patched, firewalls stay tuned, and nobody loses sleep over uptime. That’s a legitimate operational outcome, and it’s also completely orthogonal to what CMMC is testing for. The assessment procedures document that C3PAO assessors work from defines assessment objectives built around specific artifacts — a documented baseline, evidence of a change control board or equivalent approval mechanism, records of configuration change requests — and each objective is tested through some combination of examining a document, interviewing staff, and testing the actual configuration. A verbal description of how good the network is doesn’t satisfy any of those three methods.
This is the part that catches technically strong organizations off guard. Their systems are secure. Their assessment still generates findings, because security posture and documented configuration management are evaluated as separate things. An assessor who watches a firewall demo and confirms the rules make sense hasn’t tested CM.L2 — they’ve tested the firewall. To test CM.L2, they need to see the baseline document the current ruleset should match, and then trace at least one recent change back through a ticket, an approval, and a test record. The assessment objectives published in NIST SP 800-171A spell out exactly which artifacts satisfy each objective, and “the engineer knows the network” doesn’t satisfy any of them. If that chain doesn’t exist in writing, the practice isn’t “partially met” — it’s not met, regardless of how good the actual configuration is.
Baseline Configuration: The Document Assessors Actually Ask For
A baseline configuration is not a network diagram, and it’s not a compliance checklist copied from a NIST publication, nor a document you write once to satisfy a CyberAB-registered assessor and then shelve. It’s a living reference document — for each type of component in your CUI environment (domain controllers, endpoints, firewalls, cloud tenants, VPN concentrators) — that specifies the approved settings, versions, and configuration state those systems are supposed to be in. When someone asks “what should this look like,” the baseline is the answer, and when someone asks “does this match,” the baseline is what you compare against.
The mistake we see most often isn’t the absence of a baseline — most organizations have something. It’s that the baseline was written once, during initial hardening or a system security plan exercise tied to NIST SP 800-18 documentation requirements, and never touched again. Eighteen months later, three firmware updates, a switch replacement, and a new VPN client later, the document describes a system that no longer exists. An assessor who compares the baseline to the live configuration during a CMMC assessment will find drift immediately, and drift between your documentation and your reality is functionally the same finding as having no documentation at all — it just takes longer to discover.
A baseline that survives an assessment gets reviewed on a fixed cadence, tied to a real trigger — a quarterly review, a post-change verification, a pre-assessment audit — rather than existing as a one-time deliverable. It also needs to be granular enough to be useful. “Windows 11 endpoints are hardened per CIS benchmarks” is a policy statement, not a baseline. A baseline says which CIS benchmark level, which specific settings were modified from that benchmark and why, and which group policy object enforces it.
Change Control: The Process That Keeps the Baseline Honest
Change control is where most of the CM.L2 evidence actually lives, because it’s the mechanism that either keeps your baseline accurate or lets it quietly rot. Every deviation from the approved baseline — a new firewall rule, a software installation, a configuration tweak to fix a one-off problem — needs to travel through a process that records the request, the justification, the approval, and the outcome.
This doesn’t require a heavyweight ITIL change advisory board for a fifty-person defense subcontractor. It requires a consistent, repeatable record. A ticketing system that captures who asked for the change, who has authority to approve it, what was tested before deployment, and what the rollback plan was if it failed satisfies the intent completely. What doesn’t satisfy it is a Slack message that says “go ahead and open that port, we’ll deal with it later.” Assessors don’t need elaborate change management theater — they need to trace three or four recent changes end to end and see that the same process applied every time, not just when someone remembered.
Where this consistently goes wrong is emergency changes. A production issue at 11 p.m. gets fixed the fastest way possible, and the paperwork gets backfilled later, if it gets backfilled at all. A mature change control process has an explicit emergency change path — expedited approval, documented after the fact within a defined window, reviewed by whoever normally approves changes — rather than treating urgency as an excuse to skip the record entirely. Assessors have seen enough environments to know which one they’re looking at within the first few questions.
Configuration Management in Cloud and SaaS Environments
Configuration management gets noticeably harder once CUI moves into cloud platforms, because the “system” you’re baselining isn’t hardware you control end to end — it’s tenant-level settings inside someone else’s infrastructure. This matters enormously for organizations deciding between Microsoft 365 GCC and GCC High, a decision we’ve walked through in detail in our comparison of the two environments, because the configuration management burden differs meaningfully between them.
In a cloud tenant, your baseline configuration needs to capture conditional access policies, data loss prevention rules, sharing and external collaboration settings, retention policies, and administrative role assignments — all of which can be changed by anyone with sufficient privilege, often without the same friction as a physical firewall change. That ease of change is exactly why the discipline matters more here, not less. A tenant administrator adjusting a sharing policy to solve a user’s immediate problem is making a configuration change to a system in CUI scope, and if that change isn’t logged and reviewed, the baseline document describing your tenant’s security posture is now wrong the moment it happened. Our cloud transformation engagements build configuration baselining into the migration itself, specifically so organizations aren’t retrofitting a CM program onto a tenant that’s already three years into operational drift.
Least Functionality: The Discipline of Removing, Not Just Adding
Least functionality is the practice most often confused with general hardening, and the distinction matters. Hardening asks “did we turn on the security features.” Least functionality asks “did we turn off everything that isn’t tied to an approved business function.” Those are different questions, and CMMC assessors test the second one specifically.
This shows up constantly in legacy environments. A file transfer protocol that was needed for a vendor integration retired two years ago is still enabled on a server, because disabling it wasn’t anyone’s job once the integration ended. A remote access tool installed for a one-time support engagement never got uninstalled. An administrative share exists because it made someone’s life easier during a migration and nobody circled back. Each of these is a functioning capability with no current business justification, and each one is exactly what an assessor is trained to look for during a configuration review, because unused functionality is attack surface that serves no purpose except risk.
The organizational fix isn’t a bigger hardening checklist — it’s a recurring review that asks, for every open port, installed service, and enabled protocol, whether there’s a documented business reason it exists today, not whether there was one at some point. That review needs an owner and a cadence, the same way patching does, or it becomes the same kind of one-time exercise that baseline documents fall victim to. This is where a vCIO-level relationship earns its keep — someone whose job includes asking “why is this still on” on a schedule, rather than waiting for an assessor to ask it first.
Component Inventory: The Baseline’s Reality Check
An accurate, current inventory of system components sounds like the easiest CM.L2 practice to satisfy, and it’s often the one with the widest gap between believed status and actual status. Asset inventories drift the moment a device is decommissioned without being removed from the spreadsheet, or provisioned without being added to it. In environments supported by multiple parties — internal IT, an MSP, a specialty vendor managing a particular application — inventory drift accelerates, because no single party has visibility into everything touching the CUI boundary.
The inventory has to reconcile against the baseline, not exist as a parallel document nobody cross-references. If your baseline configuration describes settings for “domain-joined Windows workstations,” your inventory needs to identify exactly which devices fall into that category, and any device that exists on the network but isn’t accounted for in either document is, by definition, outside your configuration management program — which means it’s outside your compliance boundary in a way that will surface during scoping review, not during the technical assessment itself.
Tooling: Why Spreadsheets Don’t Survive an Assessment
A spreadsheet-based configuration management program can technically satisfy CM.L2 requirements on paper, and in practice it almost never does, for reasons that have nothing to do with the spreadsheet’s content and everything to do with its maintenance model. Spreadsheets don’t enforce a review cadence. They don’t alert anyone when a change happens outside the documented process. They don’t reconcile automatically against the live environment. Every one of those gaps becomes a manual task that depends on someone remembering to do it, and configuration management programs built entirely on remembering are the ones that produce accurate documentation for the first quarter and stale documentation for every quarter after.
Organizations that pass CM.L2 cleanly tend to have some combination of configuration management database tooling, automated compliance scanning that flags drift from baseline, and change tracking integrated into their ticketing platform rather than living in a separate document. This is also where automation genuinely earns its keep rather than just sounding impressive in a sales conversation — our work in AI-driven monitoring and integration focuses specifically on catching configuration drift as it happens, rather than discovering it during a manual quarterly review six months after it occurred. The tooling doesn’t replace the documentation requirement. It makes the documentation accurate without requiring a human to remember to update it.
Configuration Management Is a Program, Not a Deliverable
The organizations that struggle most with CM.L2 are the ones that treated it as a project with a completion date — write the baseline, submit it, move on. Configuration management under CMMC doesn’t have a finish line, because the underlying premise is that systems change constantly and the documentation has to keep pace, indefinitely, for as long as the organization holds CUI. That’s a fundamentally different operating model than most IT departments are built around, and it’s why configuration management findings show up disproportionately even in organizations with genuinely strong technical security.
Treating it as a program means assigning ownership — someone whose responsibilities explicitly include maintaining the baseline, running the change control process, and reconciling the inventory, not as a side task but as a defined function. It means building the review cadence into the calendar rather than the to-do list. And it means recognizing that a CMMC compliance posture that looked complete during your last internal review can still be inaccurate today, because configuration management, unlike a policy document, describes a moving target.
This ties directly into how incident response and configuration management reinforce each other — a documented baseline is what lets an incident responder identify anomalous configuration changes quickly during a live event, a connection we’ve explored in our breakdown of IR.L2 requirements. It also connects to how CUI is actually stored and disposed of across its lifecycle, which we cover in detail in our piece on the complete CUI lifecycle under CMMC. Configuration management doesn’t operate as an isolated domain during an assessment — it’s the connective tissue that every other technical control is measured against.
The Cost of Getting This Wrong
Findings in the configuration management domain rarely torpedo an assessment on their own, but they compound in a specific way that’s worth understanding before you’re sitting across from an assessor. A missing or stale baseline invites deeper scrutiny of every other domain, because an assessor who can’t verify your documented state has no reliable way to confirm that your access control settings, your audit logging configuration, or your system and communications protections match what you’ve claimed in your System Security Plan. Configuration management is, in a very real sense, the credibility layer underneath every other control family. Weak evidence here doesn’t just cost points in one domain — it undermines confidence in the rest of the assessment.
Beyond the assessment itself, contracting officers and prime contractors increasingly treat configuration discipline as a signal of overall program maturity, which ties directly back to how cybersecurity posture affects DoD contract awards well before certification enters the conversation. An organization that can produce a current baseline and a clean change history on request is demonstrating operational discipline that extends past compliance — it’s the same discipline that limits blast radius during an actual incident and speeds recovery when something does go wrong, a point we’ve made in discussing why cyber insurance alone won’t protect you after a breach.
Building a Configuration Management Program That Survives Contact With an Assessor
Getting this right doesn’t require exotic tooling or a compliance headcount most defense subcontractors can’t justify. It requires a baseline document that’s actually current, a change process that’s actually followed for every change including the urgent ones, an inventory that actually reconciles against the baseline, and an owner who treats maintaining all three as an ongoing function rather than a task that got closed out during initial implementation. Organizations operating across multiple sites — a headquarters in Boston, a satellite office in Tampa, a facility in Sarasota — add another layer of complexity here, because configuration consistency across locations has to be verifiable, not assumed.
The engineer whose network worked flawlessly for three years was right that his systems were secure. He was wrong that security and configuration management evidence were the same thing, and that mistake cost his organization a delayed certification timeline while they rebuilt documentation for infrastructure that had already been running correctly the entire time. The technical work was never the problem. The paper trail was.
That distinction is worth sitting with before your next assessment window, not during it. Configuration management evidence takes months to accumulate honestly — a baseline that was written last week to prepare for an assessor looks exactly like what it is, and experienced assessors know the difference between a program that’s been running and one that’s been staged. Start the clock now, and the paper trail will be real by the time anyone asks to see it.
Conclusion
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
