Configuration Management Essentials for NIST SP800-171

Eric Marquette

Welcome back to CMMC Unlocked. I’m Eric Marquette, and I’ve got Paul Netopski and Roz the Rulemaker here with me, as always. Today, we’re diving straight into configuration management—why it actually matters, not just in theory but for every organization working toward NIST SP800-171 compliance. Paul, before we dig into the policy weeds, I want to set the scene for folks who might be newer to all this. Configuration management is kind of that unsung foundation of security, right? At its simplest, it’s about keeping systems in the state you want them—not the state hackers or accidents might leave them in. It’s like regular oil changes for your car, but with your software and hardware. Honestly, I worked with this small manufacturer last year—and they thought configuration management was ‘just paperwork you stash somewhere for an audit.’ It was only when we mapped out who had access to what, how stuff actually changed in their network—oh man, it was a lightbulb moment for them. Suddenly, it wasn’t paperwork; it was about really understanding and controlling what could change where CUI lived.

Paul Netopski

That resonates, Eric. Configuration management is far more than documentation. It’s the process of maintaining all assets—hardware, software, even documentation—in a desired, secure state, and making sure changes are intentional and traceable. The real key here is maintaining consistency over time so that security controls don’t erode. NIST SP800-171 isn’t always explicit about needing a full-blown plan, but you’re still on the hook to clearly identify who and what has access to Controlled Unclassified Information—CUI—throughout the environment. If you miss that, you’re missing the spirit of the requirements.

Roz the Rulemaker

Exactly, Paul. And from a regulatory vantage point, not having a handle on configuration management can create a host of vulnerabilities, both technical and compliance-related. If regulators or assessors can’t see that you’re controlling and tracking changes, or that you know who can touch CUI, you’re going to have an uphill battle during an assessment. People sometimes underestimate that these requirements exist precisely because so many breaches have come from unmanaged changes or unclear asset inventories. So yes, Eric, it’s about far more than documentation. It’s how you demonstrate you’re in control.

Eric Marquette

Yeah—and you know, this connects really neatly with the acceptable use policy conversation from last episode, where “policy” comes to life not on paper but in how people and systems actually behave. All right, let’s shift gears and get into the specifics of what NIST SP800-171 wants to see in your policy.

Paul Netopski

Let’s break down what the Configuration Management Policy really looks like under NIST SP800-171. We’re talking about controls 3.4.1 through 3.4.9. So what do those actually mean? First, baseline configuration and asset inventories. Are you keeping a record of all hardware, software, firmware, and documentation, and updating those as things change? Second, are you actually enforcing security config settings—using tools like group policy objects, not just hoping for the best. From there, change management is all about tracking changes—logging them, getting proper review and approval, and making sure you’re not missing the security impact of what you’re updating. I see a lot of gaps in organizations when they don’t log every change. Or, even worse, when they let shadow IT slip changes in with no real oversight. That’s where things can fall apart.

Roz the Rulemaker

Paul, I’d add that from a compliance and governance point of view, accountability really depends on clearly documented roles and responsibilities. The policy should spell out: who’s responsible for maintaining the baseline, who reviews change tickets, who approves new software—otherwise, you get finger-pointing and confusion in an audit or, worse, during an incident. In my experience, the principle of least functionality—running only essential services and software—is deceptively simple but incredibly powerful. Organizations sometimes overlook documenting which programs, ports, or functions are truly “essential,” and that’s a problem. The risk is you wind up with more attack surface than you expect—and no clean documentation trail to show you’re remediating those risks intentionally.

Eric Marquette

This is where people usually gloss over the details. They might think, “I’ll just close a few ports, set a password policy, I’m good.” But least functionality really means paring it all down to only what you need—on everything from applications to services to even external connections. And documenting that baseline is what you get measured against. If you haven’t defined a baseline or made it clear who owns it, you’re setting yourself up to miss something big when the assessor comes calling.

Paul Netopski

And don’t forget items like enforcing software whitelisting or blacklisting, which require documentation and actual technical controls to prevent unauthorized use. Monitoring for user-installed software is also a big one. If a user installs something outside policy, that should generate an audit event. You can’t just rely on good intentions—you need evidence for every step.

Roz the Rulemaker

If I can add one more thing, regular policy review and internal audits are crucial. The responsibilities matrix in most policies isn’t just a bureaucratic exercise; it ensures everyone—from the CISO to the network admin—knows their piece of the puzzle. And updating policies when systems or threats evolve is part of staying audit-ready and secure.

Eric Marquette

So, to sum up, don’t leave roles vague. Know your baseline, enforce your controls, and document everything. Now, let’s talk about what a Configuration Management Plan adds, and why—even if it’s not always strictly required—it’s one of those ‘must-haves’ in practice.

Eric Marquette

So, what’s the real-world value of an actual Configuration Management Plan? It’s funny—‘Plan’ sounds formal and, honestly, sometimes organizations want to skip it because SP800-171 doesn’t explicitly say it’s a requirement everywhere. But Paul, maybe you can explain why it’s almost always essential in practice.

Paul Netopski

Sure, Eric. You hit the nail on the head: NIST SP800-171 may not always mandate a standalone plan, but in the real world—especially for CMMC, and especially under assessment—you’re often asked to show how you’re managing your baselines, enforcing changes, and preventing configuration drift. Certification bodies and contract assessors want to see evidence of a well-documented, repeatable process. That’s not something you can do on the fly. I’ve seen situations—a defense contractor comes to mind—where they did everything “well enough” technically, but when an assessor asked, ‘Show us your approach for baseline and configuration changes,’ they had nothing documented. End result: they failed the audit. A simple plan could have bridged that gap. The key takeaway is that documentation isn’t just red tape; it shows your process is deliberate, consistent, and reviewable.

Roz the Rulemaker

And let’s be honest, from an audit and regulatory perspective, assessors are looking for assurance, not just intent. A Configuration Management Plan connects the dots—what you say, what you do, and what you can prove. It also helps with risk management, because if you know what’s normal through your baseline and change management practices, you can more quickly spot when something’s off—whether that’s an incident or drift in system configurations.

Eric Marquette

Yeah, and it comes back to that idea we’ve talked about before—if it’s not written down, it didn’t happen. The plan makes your ‘good intentions’ visible and actionable, not just something you hope happens right. So, for folks listening, even if no one explicitly asks for the plan at first, you’ll be glad you have it when the stakes are high. All right, let’s dig into what a strong baseline actually looks like in day-to-day operations.

Paul Netopski

If you look at an effective baseline configuration, it’s a collection of key elements that define what’s approved and expected on a system. From the Baselines document, you’re covering everything from password and audit policies, to account lockouts, to what ports or programs are allowed. For example, on Windows 11, you might require specific security patches, block USB ports except for select use cases, enable audit logging, and only allow pre-approved software via group policy or management tools like SCCM. That baseline isn’t just a suggestion—it’s what gets enforced every time a new system is built or re-imaged.

Eric Marquette

It’s sort of like putting bumpers on a bowling lane—if your configuration slips off, you notice fast. Inventories and configuration profiles are what actually make this work. If you don’t have an up-to-date asset inventory tied to your baselines, you’re playing catch-up as soon as anything changes. Stuff like Active Directory group policies or straight disk images—they keep your desired state in check across all machines.

Roz the Rulemaker

And asset inventories are often the linchpin. Auditors and regulators look to see that you’re capturing not just hardware models and locations, but all the little details: firmware versions, software install dates, patching records, configuration references. That way, you can’t lose track of exceptions or forget about a device. It also ties into a lot of compliance requirements around supply chain risk and recordkeeping.

Paul Netopski

Another thing—I see a lot of people miss the connection between baselines and enforcement technology. For instance, you might list out your essential programs and functions, but if those aren’t enforced—like by turning off unnecessary ports in a firewall, or disabling USB storage at the OS level—it’s just wishful thinking. Having a clear, enforced baseline is essential for audit readiness and real security.

Eric Marquette

Yeah, and it’s important to remember this isn’t a one-and-done. Regular review of your baseline as the tech and threat landscape change—that’s a best practice that keeps you current and consistently secure. All right, so the baseline gives us our guardrails—let’s talk about what happens when you need to make a change, or review who’s allowed to make them.

Eric Marquette

Change happens—that’s just the nature of technology, right? But how you log, approve, and analyze every change matters, especially for regulated environments. Paul, walk us through what an ideal change management process should look like for CMMC Level 2 compliance or under NIST SP800-171.

Paul Netopski

Sure. Every config change—software, hardware, or firmware—should first be recorded in a formal ticketing system. That ticket gets reviewed and needs approval from both IT and security, typically. Before you actually implement the change, you should analyze the security impact. Many organizations will test the change on an exemplar system, do a vulnerability scan, and review the results for negative impacts before rolling it out broadly. This isn’t just bureaucracy—it’s how you catch problems early. Once rolled out, the change should be auditable—meaning it’s traceable back to that ticket, with who did what and when, for compliance checks.

Roz the Rulemaker

From the governance perspective, one recurring challenge is balancing restrictive security measures—like whitelisting all software or disabling unneeded ports—with the operational need for business flexibility. Too much restriction, and you stifle productivity. Too little, and you risk compliance failure. So it’s about regular review, updating, and—not to sound like a broken record—documenting those decisions and exceptions. Tools like inventories, audit logs, and the ticketing system aren’t just red tape; they’re your evidence during an audit that you’re managing change intentionally, not reactively.

Eric Marquette

And you can’t forget about enforcing physical and logical access restrictions. Sometimes it’s not just who clicks “install”—it’s who has keys to the server room, or VPN access to critical systems. Documenting and controlling that is just as important. If you’re not reviewing privileged access, or making sure installed software comes only from approved sources, your change controls won’t hold up.

Paul Netopski

To stay compliant, regularly review the tools and docs—your inventories, ticketing system, firewall rules, enforcement tech. Make sure they’re current, your logging is working, and what you say in your policies is actually happening in your environment. That’s how you prevent drift and prove it to an assessor.

Roz the Rulemaker

And keep those internal audits going. A living, breathing change and access management process is how organizations avoid both compliance surprises and security incidents. The most mature orgs I’ve worked with made this stuff part of their culture, not just annual checkboxes.

Eric Marquette

Well said. I think that’s a strong note to end on for today’s episode. Configuration management may not get the glory, but it’s the backbone of compliance—and real defense. Thanks for joining us—Roz, Paul, appreciate your insights as always. We’ll be back with more deep dives next time. Everyone, stay secure out there!

Roz the Rulemaker

Great session as always. Thanks, Eric, and thank you, Paul. Looking forward to the next episode.

Paul Netopski

Thanks, Roz. Eric—always a pleasure. Until next time, keep your baselines tight and your changes tracked.