This post explains how to design and implement a hardened configuration checklist that satisfies NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.2 — focusing on practical, small-business friendly steps, concrete configuration settings, automation options, and the types of evidence assessors expect.
Understanding CM.L2-3.4.2 and what compliance looks like
CM.L2-3.4.2 maps to the configuration-management expectations in NIST SP 800-171: you must establish and maintain baseline configurations and inventories of organizational systems (hardware, software, firmware) and ensure configurations are controlled and monitored. In practice this means a documented baseline for each system type, automated scans to detect deviations, change-control tied to configuration changes, and retained evidence (baseline documents, scan reports, change tickets) showing you maintain the baseline.
Step-by-step approach to build a hardened configuration checklist
Think of the checklist as a living artifact: a repeatable, auditable template that describes the secure baseline for a product or system class (workstation, domain controller, web server, router, cloud instance). The steps are: 1) Inventory & classify assets; 2) Define baselines (CIS/DisA/AWS Benchmarks + org-specific settings); 3) Create the checklist entries (settings, acceptable deviations, evidence required); 4) Automate enforcement and scanning; 5) Integrate with change control and documentation.
Inventory and classification — start here
Before you write a checklist, build an accurate inventory. For small businesses, begin with a spreadsheet or Snipe-IT/OCS Inventory NG listing asset ID, owner, OS, role (end-user workstation, server, network device), location, and criticality (CUI processing or not). Use lightweight discovery tools to validate: nmap for network discovery, osquery for endpoint details, or cloud provider inventory APIs (AWS DescribeInstances, Azure Resource Graph). Classification determines which baseline applies — e.g., a domain-joined Windows 10 laptop gets a different checklist than an Ubuntu web server.
Define baseline configurations — leverage benchmarks and organizational policy
Create baseline profiles referencing authoritative benchmarks: CIS Benchmarks, DISA STIGs (where appropriate), and vendor hardening guides. For each baseline include explicit settings such as: Windows GPO values (Password Length >= 12, Account Lockout 5 attempts, Audit: object access enabled), Linux SSH settings (/etc/ssh/sshd_config: Protocol 2, PermitRootLogin no, PasswordAuthentication no, ClientAliveInterval 300), disk encryption (BitLocker/ FileVault enabled), UEFI secure boot and TPM enabled on endpoints, disabled services (telnet, rsh, SMBv1), and minimum patch levels. Capture these as checklist items with a "pass/fail" criterion and the command or registry key to verify (e.g., Get-WmiObject -Class Win32_EncryptableVolume for BitLocker status).
Implement, automate, and monitor — make the checklist enforceable
Automation reduces drift and produces evidence. Use configuration management and scanning tools suitable for your environment: Ansible or PowerShell DSC for enforcing baseline state; OSQuery, OpenSCAP, Lynis, or CIS-CAT for compliance scans; Microsoft Intune / SCCM for Windows policy deployment; Jamf for macOS. Example Ansible task: set /etc/ssh/sshd_config options and restart sshd; example PowerShell to disable local admin accounts and enforce LAPS. Schedule automated scans weekly for endpoints and daily for internet-facing systems; centralize logs in a SIEM or a cloud logging service and retain configuration scan results for at least 90 days as evidence.
Documentation, change control, and evidence collection
For each checklist item define required evidence: configuration file snippet, registry value, scan report, or a change ticket ID. Put change control around baseline changes: require a request, impact assessment, approval, implementation note, and post-change scan. Maintain a versioned baseline repository (Git) and store checklists in your Configuration Management Database (CMDB) or asset tracker. Example evidence artifacts: baseline document v1.2, Ansible playbook commit hash, weekly CIS-CAT report showing 100% compliance, and change request CR-2026-042 for an approved SSH port change.
Real-world small business scenarios, tips, and best practices
Scenario A — 25-person engineering small business with CUI on laptops: Start by baselining the 10 systems that store/process CUI. Use Intune or Group Policy to push disk encryption, password policies, and update cadence. Use osquery to snapshot installed software and schedule weekly scans. Keep remediation playbooks (PowerShell scripts) for quick fixes. Scenario B — 3-person MSP hosting web apps in AWS: Apply AWS CIS Benchmarks via Scout2 or AWS Config conformance packs, enforce AMI hardening, and automate instance baseline checks with CloudFormation or Terraform templates. Best practices: prioritize high-criticality assets, use templates for repeatability, keep baselines as code, and limit exceptions (document any deviations and approval rationale).
Risk of not implementing CM.L2-3.4.2
Failure to maintain hardened baselines increases attack surface and enables common threats: default credentials left active, unpatched services exploited, insecure management interfaces exposed, and inconsistent configurations that hinder incident response. Non-compliance can lead to contract loss with DoD suppliers, failed CMMC assessments, regulatory fines, and operational disruption. Practically, undetected drift means you can’t prove to an assessor that CUI is consistently protected — which is the core objective of CM.L2-3.4.2.
In summary, build your hardened configuration checklist around a verified inventory, authoritative benchmarks, clear verification commands, automation to prevent drift, and documented change control. For small businesses, start small (critical assets), use free/open tools where possible (osquery, Ansible, Snipe-IT), store baselines as code, collect scan reports and change tickets as evidence, and iterate — compliance is achieved through repeatable, auditable processes, not one-off hardening efforts.
