Meeting NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.2 means establishing, documenting, and maintaining baseline configurations for your organizational systems so they start in a secure, auditable state and you can detect unauthorized changes—this post gives a practical, step-by-step approach (with templates and a checklist) that small businesses can implement right away.
Understanding CM.L2-3.4.2 and the compliance objective
CM.L2-3.4.2 requires organizations to define and maintain baseline configurations for systems that process, store, or transmit Controlled Unclassified Information (CUI). The key objective under this Compliance Framework is reproducibility and traceability: an auditor must be able to see an approved baseline, the deployment history or image used, and evidence you regularly check for drift. For small businesses this means treating configuration baselines as formal artifacts—not ad-hoc settings on laptops or servers.
Practical implementation: inventory and scoping
Inventory and categorize systems
Start by building a simple system inventory (CSV or CMDB) with fields: asset ID, owner, system type (workstation/server/network device), OS and version, location, CUI in-scope (yes/no), baseline template ID, and last-audited date. Use tools appropriate to your size: for 10–50 endpoints, Intune + Azure AD devices or a small CMDB like Snipe-IT works; for hybrid/cloud, add AWS account/region and use AWS Config to list in-scope EC2/RDS resources. Accurate scope is the foundation of CM.L2-3.4.2 compliance.
Define baseline classes
Create baseline templates by class (e.g., Windows 11 corporate laptop, Ubuntu 22.04 server, Cisco IOS edge router). For each template include: OS/build number, approved image identifier (AMI or MDT/Intune image), required agents (EDR, EDR configuration, syslog/CEF forwarder), patch level policy, firewall rules and listening ports, disabled services, account and password policies (e.g., minimum length 14, complexity on, max age 90), auditing/logging settings, and CIS Benchmark target score. Use CIS Benchmarks, vendor STIGs, or NIST guidance as a baseline source and record the exact benchmark version you applied.
Automate enforcement and deployment
Implement automation to create consistency and evidence. Use imaging and configuration-as-code: create golden images (SCCM/Intune/MDT for Windows, Packer + AMI for AWS Linux) and store image IDs in the baseline template. Use Ansible/Chef/Puppet/PowerShell DSC to apply runtime configuration and remediate drift. For cloud, attach AWS Config rules or Azure Policy assignments that enforce baseline policies (e.g., encryption at rest, security group rules). Record automation runs in version control (Git) with tags that map to baseline IDs so auditors can see the exact code used to configure systems.
Monitor drift, change control, and audit evidence
Detect and log deviations continuously. Deploy configuration assessment tools: osquery, InSpec, CIS-CAT Pro, or commercial posture managers to regularly snapshot system state and compare to baseline templates. Integrate with SIEM or centralized logging so you have: timestamped drift reports, remediation actions (playbook run IDs), and change request IDs that show authorized changes. For evidence, collect the baseline document (signed/approved), the template in Git with commit hash, deployment logs, scan reports showing compliance percentage, and a CSV export of the current inventory mapped to baseline IDs.
Templates and a concise checklist (practical artifacts)
Template: Baseline Configuration Template (fields you must capture): Template ID, Template name, System class (desktop/server), Approved OS/build, Image ID or build script link, Approved software list with versions, Network/firewall rules (allowed inbound ports), Required agents + versions, Hardening source (CIS vX.Y), Password policy values, Auditing settings (what to collect/retention), Patch schedule (weekly/monthly), Owner/approver, Change control link, Last updated, Rollback procedure. Store this as a YAML/JSON file in Git and export a human-readable PDF for auditors.
Checklist to implement CM.L2-3.4.2 (use for initial audit readiness): 1) Inventory completed and tagged in CMDB; 2) Baseline templates created for each system class and approved by owner; 3) Golden images or IaC committed to Git with tags linking to template IDs; 4) Automation in place (Ansible/Intune/etc.) to enforce baseline and remediate drift; 5) Continuous checks scheduled (weekly scans) with results forwarded to central log; 6) Change control process documented with CR numbers linked to config changes; 7) Quarterly review schedule documented and evidence (scan reports, change logs, image IDs) stored for at least one year (or contractually required retention). Include one sample evidence pack per baseline for auditors: template PDF + Git commit + scan PDF + CR ticket + inventory CSV row.
Real-world small business scenario
Example: Acme Widgets (35 employees) uses Azure AD, Intune, and two Linux servers in AWS hosting an app with CUI. Implementation steps: create two baseline templates (Windows laptop, Ubuntu server), build an Intune image and a Packer AMI, enforce baseline with Intune configuration profiles and an Ansible playbook that ensures SSH settings (PermitRootLogin no, PasswordAuthentication no), firewall (ufw default deny incoming; allow 22 from management subnet), and logging (rsyslog forwarder to a central Graylog). They run weekly InSpec checks and store reports in an S3 bucket with versioned filenames that include the baseline ID and date. During an audit they present the baseline PDF, the Git commit hash for the Ansible playbook, Packer build logs, the CR ticket approving a change, and the latest InSpec report showing 98% compliance—this fulfills CM.L2-3.4.2 evidence needs.
Risk of not implementing baselines & compliance tips
Without formal baselines you risk unauthorized configuration drift, unpatched vulnerabilities, inconsistent security controls across systems, and ultimately failure in contract-driven audits which can lead to lost contracts or remediation orders. Practical tips: 1) Start small—cover the most sensitive systems first; 2) Use version control and immutable image references to provide unambiguous evidence; 3) Tie baseline updates to your change control workflow and require documented approvals; 4) Automate drift remediation where possible but log every automatic action; 5) Keep baseline review frequency in policy (e.g., quarterly or on major software upgrades) and log the review sign-off.
Summary
CM.L2-3.4.2 compliance is achievable for small businesses by treating baseline configurations as formal, versioned artifacts enforced via automation, monitored continuously, and linked to a documented change-control process. Build simple templates, enforce with the tools you already have (Intune, Ansible, AWS Config, etc.), collect a repeatable set of evidence (template, image/commit ID, scan report, change ticket), and use the checklist above to prepare an auditor-friendly evidence pack—doing so reduces risk and makes audits routine instead of disruptive.
