Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - CM.L2-3.4.2 – Establish and enforce security configuration settings for information technology products employed in organizational systems
Understanding the Requirement
This control requires you to define and enforce secure configuration settings for every information technology product that is part of your environment — desktops, servers, network devices, printers and any other managed endpoint. The baseline configuration must include the security settings, and those settings must be actively enforced; deviations are allowed only when reviewed, documented, and approved. As part of NIST SP 800-171 REV.2 / CMMC 2.0 Level 2, practical guidance calls for using recognized configuration standards such as DISA STIGs or CIS benchmarks to reduce default insecurity and produce repeatable, auditable baselines.
Technical Implementation
- Inventory and classify systems. Start with a complete, current inventory of all managed devices (workstations, servers, network gear, printers, virtual machines). Classify devices by role and data sensitivity so you can select the appropriate baseline (e.g., workstation, developer laptop, domain controller).
- Select and document baselines. For each device class pick an authoritative benchmark — DISA STIGs for DoD-aligned environments or CIS Benchmarks for broader use. Record the chosen baseline and the specific version in a configuration management document or CMDB.
- Automate deployment and enforcement. Use your existing management tools (Group Policy, SCCM/Intune, Ansible, Chef, Puppet, or network device management systems) to implement the baseline settings consistently. Where automation isn't available, use scripted checks and a documented manual process for enforcement.
- Approve and document deviations. Any setting that prevents legitimate business operations must be handled through a formal exception process: document the incompatible setting, record the business justification, get management approval, and set an expiration or review date for the exception.
- Monitor and validate continuously. Schedule regular configuration scans and compliance reporting using tools that can check STIG/CIS compliance or run custom hardening checks. Integrate scan results into a regular review process and remediate drift quickly.
- Change control and periodic review. Include baseline changes in your change control process; require testing before deployment and a record of who made changes, why, and when. Review baselines at least annually or whenever a major OS/device firmware update occurs.
Example in a Small or Medium Business
An SMB that supports 120 employees inventories all endpoints and separates standard workstations from developer machines. IT selects the DISA STIG for Windows 10 as the baseline for standard user laptops and documents the selection and version in the configuration management record. The administrator imports the STIG into the STIG viewer, maps required settings into Group Policy, and rolls the GPO to the standard user OU. After deployment, a developer reports that an applied setting blocks a needed local service used for testing. The IT lead documents the incompatible setting, captures a business justification for the developer exception, and opens a formal exception request. Management approves a limited exception for the developer's laptop with an expiration and mitigation steps, and IT excludes that machine from the specific GPO while applying compensating controls (network segmentation and additional logging). The IT team runs weekly compliance scans to ensure all other endpoints remain within the baseline and schedules a quarterly review for exceptions and baseline updates.
Summary
Establishing and enforcing secure configuration settings is both a policy and a technical effort: choose authoritative baselines (DISA STIGs or CIS benchmarks), document them, and use automation to deploy and enforce across your estate. Pair that technical work with a formal process for exceptions, change control, and ongoing validation so deviations are tracked and approved. For SMBs this approach provides repeatable hardening, reduces attack surface, and creates the audit trail required by NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 while keeping business needs and developer workflows manageable through controlled exceptions.
