Skip to main content
NetStable
⚙️ 9 Practices NIST 3.4.1 - 3.4.9

Configuration Management Policy

Configuration Management Domain (CM)

📖 What This Policy Covers

Configuration Management is about knowing exactly what your systems look like, keeping them hardened to a known-good state, and controlling any changes. This policy covers baseline configurations (the secure 'gold image' for each system type), change control processes (formal approval before any production change), least functionality (disabling what you don't need), user-installed software restrictions, asset inventory, automated configuration enforcement, vulnerability management, security impact analysis, and access restrictions for making changes.

Purpose

This policy ensures secure baseline configurations are established for all systems, all configuration changes are controlled and tracked, system inventories and documentation are maintained, consistent security settings are enforced across environments, and rapid recovery and incident response capabilities are supported.

Scope

Applies to all information systems, devices, applications, and network components processing or storing CUI, including cloud infrastructure, on-premise systems, and endpoints.

🎯 Why It Matters

Misconfigured systems are a leading cause of breaches -- 70% of cloud breaches involve misconfiguration (Check Point 2023). Without configuration management, systems drift from secure baselines over time, creating exploitable gaps. Assessors will check that you have documented baselines, a formal change control process, and evidence of vulnerability remediation within defined timeframes. With 9 practices, this is a medium-sized domain but touches everything in your environment.

🔐 Key Requirements

1. Baseline Configurations

Documented, hardened baseline configurations for every system type, based on industry standards.

  • Documented baseline configs for: Windows workstations, Linux servers, network devices, cloud resources
  • Based on CIS Benchmarks, DISA STIGs, or vendor security guides
  • Include: OS hardening, application settings, network configuration, security tool settings
  • Review and update annually or when significant changes occur
  • Least functionality: disable unnecessary services, ports, protocols, applications
  • Default accounts disabled or renamed; default passwords changed
  • Maintained in CMDB or version control with: hostname, IP, OS, software, patch level, owner

2. Configuration Change Control

Formal change control process for all production system modifications.

  • Change request via ticketing with business justification
  • Change Advisory Board (CAB) reviews impact and security implications
  • Manager + IT Security approval required for production changes
  • Test in non-production environment first
  • Execute during approved maintenance window
  • Verify change successful with no adverse impacts
  • Update documentation and close ticket
  • Emergency changes: CISO approval, retroactive CAB approval within 24 hours
  • Prohibited: unscheduled changes without approval, changes without rollback plan

3. Least Functionality

Systems configured to provide only essential capabilities, with unnecessary functions disabled.

  • Disable unnecessary services: SSH on workstations, telnet, FTP, SNMP v1/v2
  • Remove unnecessary software: games, media players, dev tools (unless required)
  • Restrict USB storage, CD/DVD writing, Bluetooth (unless approved)
  • Application whitelisting via AppLocker or Windows Defender Application Control
  • Firewall rules block unnecessary ports

4. User-Installed Software

Restrict software installation to authorized administrators only.

  • Software installation restricted to IT administrators only (enforced via GPO, Intune)
  • Standard users cannot install software
  • Approved software catalog via self-service portal
  • Exception process: business justification, IT Security review for risks

5. System Component Inventory

Comprehensive hardware and software asset inventory, continuously updated.

  • Real-time for cloud (auto-discovery), weekly scans for on-premise
  • Inventory fields: asset tag, serial, hostname, IP, owner, location, OS, software, patch level, CUI classification
  • Discovery via: network scanning (Nmap, Nessus), agent-based (SCCM, Intune, osquery), cloud-native (AWS Config, Azure Resource Graph)
  • Manual reporting for air-gapped systems

6. Security Configuration Enforcement

Automated enforcement and monitoring of security baselines.

  • Group Policy (Windows) for security baselines
  • Intune/MDM for mobile and cloud configuration profiles
  • Ansible/Terraform for Infrastructure as Code enforcement
  • Daily configuration compliance scans with alerts on drift
  • Auto-remediate where possible; create ticket for manual remediation

7. Vulnerability Management

Regular vulnerability scanning with risk-based remediation timelines.

  • Weekly authenticated scans for CUI systems, monthly for other systems
  • Tools: Nessus, Qualys, Rapid7, or cloud-native (AWS Inspector, Azure Defender)
  • Remediation SLAs: Critical (CVSS 9.0-10.0) 7 days, High (7.0-8.9) 30 days, Medium (4.0-6.9) 90 days
  • Risk acceptance documented for exceptions with compensating controls

8. Security Impact Analysis

Analyze security impact before implementing changes to CUI systems.

  • Security impact analysis before all changes to CUI systems
  • Analysis covers: potential vulnerabilities, impact to existing controls, effect on CUI confidentiality/integrity/availability
  • Documented in change ticket
  • IT Security review mandatory for infrastructure and security tool changes

9. Access Restrictions for Change

Physical and logical access restrictions for configuration changes.

  • Server rooms require badge + escort
  • Only authorized administrators can modify configurations
  • Separation of duties: different personnel for development, testing, production
  • All configuration changes logged (who, what, when)

👥 Roles & Responsibilities

CISO / IT Director

  • Approve baseline configurations and exceptions
  • Chair Change Advisory Board (or delegate)
  • Review vulnerability management metrics monthly
  • Approve emergency changes

IT Operations / System Administrators

  • Maintain baseline configurations and CMDB
  • Implement approved changes per change control process
  • Deploy patches within defined SLAs
  • Monitor configuration compliance

IT Security

  • Review security impact of proposed changes
  • Conduct vulnerability scans and track remediation
  • Monitor for configuration drift
  • Approve software installation exceptions

Application Owners

  • Submit change requests for their systems
  • Test changes in non-production before requesting production deployment
  • Maintain system documentation
  • Participate in CAB reviews for their applications

🛠️ Implementation Roadmap (8 Weeks)

1

Baseline Development

Weeks 1-2
  • Select baseline frameworks (CIS Benchmarks for Windows 10, RHEL 8, AWS Foundations)
  • Customize for organization, document in configuration management system
  • Test baselines in lab environment
2

Change Control Process

Week 3
  • Implement change ticketing system (ServiceNow, Jira)
  • Create CAB (IT Director, CISO, Operations Manager, App Owners)
  • Define weekly CAB meeting schedule, create change request templates
3

Configuration Enforcement

Weeks 4-5
  • Deploy Group Policy baselines to domain
  • Configure Intune compliance policies
  • Implement Infrastructure as Code (Terraform, CloudFormation)
  • Deploy configuration monitoring (Azure Policy, AWS Config)
4

Asset & Vulnerability Management

Weeks 6-8
  • Deploy asset discovery tools, populate CMDB
  • Deploy vulnerability scanner, establish remediation workflows
  • Generate baseline vulnerability reports
  • Document all procedures and train team

Recommended Tools

ServiceNow / Jira (change management)CIS Benchmarks / DISA STIGs (baseline standards)Nessus / Qualys / Rapid7 (vulnerability scanning)Azure Policy / AWS Config (compliance monitoring)SCCM / Intune / Ansible / Terraform (configuration enforcement)ServiceNow CMDB / Lansweeper (asset inventory)

📊 CMMC Practice Mapping

Practice ID Requirement Policy Section
CM.L2-3.4.1 Establish/maintain baseline configurations 1, 5
CM.L2-3.4.2 Employ least functionality principle 1, 3, 6
CM.L2-3.4.3 Control/track configuration changes 2
CM.L2-3.4.4 Security impact analysis for changes 8
CM.L2-3.4.5 Define/enforce security configuration settings 6
CM.L2-3.4.6 Employ least functionality 3
CM.L2-3.4.7 Restrict/disable/prevent user software install 4
CM.L2-3.4.8 Apply deny-by-exception policy for software 4, 7
CM.L2-3.4.9 Control access for configuration changes 9

📋 Evidence Requirements

These are the artifacts a C3PAO assessor will ask for. Start collecting early.

Baseline Configuration Documents

Format: PDF per system type
Frequency: Annual review
Contents: Documented baseline for each system type (Windows, Linux, cloud) with CIS Benchmark or STIG references
Tip: Map each baseline setting to the CIS control number. Show customizations with justification.

CMDB / Asset Inventory Export

Format: CSV
Frequency: Monthly export
Contents: Complete hardware and software inventory with all required fields
Tip: Include CUI classification column. Highlight any assets without assigned owners.

Sample Change Tickets

Format: PDF export from ticketing system
Frequency: Ongoing; sample for audit
Contents: 5-10 change tickets showing full approval workflow (request, review, approval, implementation, verification)
Tip: Include at least one emergency change showing retroactive approval. Show both approved and rejected examples.

Configuration Compliance Reports

Format: PDF/Excel
Frequency: Monthly
Contents: Monthly compliance reports showing % of systems meeting baseline (target: 95%+)
Tip: Show trend over time. Document remediation for any non-compliant systems.

Vulnerability Scan Reports

Format: PDF
Frequency: Quarterly
Contents: Last 4 quarters of scan results with remediation tracking by severity
Tip: Show that critical/high vulnerabilities are being remediated within SLA. Track average time-to-patch.

Remediation Metrics

Format: Excel
Frequency: Monthly
Contents: Average time to patch by severity level, trending over last 12 months
Tip: This is a key metric assessors look at. Show improvement over time.

⚠️ Common Gaps (What Assessors Flag)

1. No documented baseline configurations

Why this happens: Systems were set up ad hoc over time. Nobody documented what 'secure' looks like for each system type.
How to close the gap: Start with CIS Benchmarks -- download the benchmark for your OS/platform and customize. Document deviations with justification.

2. No formal change control process

Why this happens: Small team makes changes directly without tickets. Feels like overhead for a small org.
How to close the gap: Even a lightweight process counts: Jira ticket with description, approval comment from manager, and post-change verification. Document the process and follow it consistently.

3. Vulnerability scans running but no remediation tracking

Why this happens: Scans generate reports that sit in inboxes. No one tracks whether vulnerabilities are actually patched.
How to close the gap: Create a remediation workflow: scan results -> Jira tickets (auto-generated) -> assigned to system owner -> tracked to closure with SLA.

4. Users can install software freely

Why this happens: Standard users have local admin rights for convenience.
How to close the gap: Remove local admin rights via GPO/Intune. Deploy a self-service portal for approved software. Use LAPS for controlled admin access when needed.

📝 Template Customization Guide

When filling in the downloadable template for this policy, replace these placeholders with your organization's specifics:

[COMPANY NAME]

Your organization's legal name

Example: Acme Defense Systems, LLC

[CISO Name]

Name of your CISO or IT Director

Example: Jane Smith

[MM/DD/YYYY]

Policy dates

Example: 03/01/2026

Customization Tips

  • 💡 Download CIS Benchmarks for your specific OS versions and cloud platforms as your baseline starting point
  • 💡 Adjust vulnerability remediation SLAs based on your team's capacity -- but document any deviations from the recommended timelines
  • 💡 For small organizations, the CAB can be 2-3 people meeting weekly for 30 minutes
  • 💡 If you use Infrastructure as Code (Terraform, CloudFormation), your IaC templates ARE your baseline documentation
  • 💡 Consider using Azure Policy or AWS Config for automated compliance monitoring rather than manual checks

📚 Related Policies