Top 10 Failed CMMC Controls, #10 System Baselining

CMMC Journey Guides

#10- CM.L2-3.4.1: System Baselining

When working with individual controls, we know that they have to be dissected from an objective level. For this specific control out of the 110 controls, 320 objectives in CMMC, I have chosen to split it up with objectives a/b/c and d/e/f. Two parts, mainly covering “baseline configurations” and “system inventory”. If you work with CUI, you don’t get to “wing it” on configurations or inventory. CM.L2-3.4.1 asks you to do two big things across the system life cycle:
(1) build and maintain secure, documented baselines for each system and
(2) keep a trustworthy inventory that actually reflects reality in production.

The CMMC Level 2 Assessment Guide spells this out clearly, including exactly what assessors will “Examine/Interview/Test” to verify it’s in place. In this article we will get granular with 1) Dissecting the Control, 2) What full implementation looks like, 3) Why this Control Fails, 4) A Quick Checklist.

1) Dissecting The Control in Two Logical Halves

Objectives A/B/C: Baseline Configurations

• [a] Establish a baseline configuration for each system component type. For every deployed machine type, you define the approved build: OS version, required apps, hardened settings, network placement, and anything else that affects security and function.
• [b] Include the full buildout for each system. Baselines must cover hardware, software, firmware, and documentation—not just a golden image. Think platform model/BIOS, OS and app versions/patch status, and the config parameters that lock it down.
• [c] Maintain it consistently moving forward. As your environment changes, review and update baselines so they always reflect the live system and enterprise architecture (create new baselines when things change materially).

What lives in a solid baseline:

• Laptops/Desktops/Servers
• Enclaves (e.g., entire VDI and each component), laptops/workstations, servers
• ALL Applications per asset group
• Versions & patch levels for OS/apps/firmware
• Networking elements: routers, switches, firewalls, WAPs, etc.

Objectives D/E/F: System Inventory

• [d] Establish a system inventory. A real one… no, seriously. This is ideally software via Asset Management agent(s) that automate most of this process. BUT that is not required, just advice. Any devices classified as any of the CMMC asset types will be in-scope and should be in the system inventory.
• [e] Include the full buildout for each system in the inventory. (again: hardware, software, firmware, and documentation).
• [f] Maintain it. Review and update it as systems evolve so it stays accurate to production reality in a reasonable and timely manner.

What lives in a solid inventory:

• Manufacturer, device type, model, serial number, physical location, owners/main users
• Hardware specs & parameters
• Software inventory with version control and potentially licensing information
• Network info (machine names, IPs)

Assessor angle (what they look at): Policies, procedures, SSP, Configuration Management plan, inventory records and update logs, config docs, change/install/remove records; plus, interviews with the people who build and maintain these things; plus, tests of the actual processes and mechanisms you use to manage baselines and the inventory.

2) What Full Implementation Looks Like

A simple, effective pattern from the Assessment Guide:

1. Design a secure workstation baseline. Research the hardened settings that deliver the least functionality needed to do the job, then test that baseline on a pilot machine.
2. Document it (build sheet, settings, required software, version list, how it’s joined to the network) and roll it out to the rest of that asset class from the documented baseline.
3. Update the master inventory manually, or make sure an appropriate agent is live to reflect the software changes and the devices now at the new baseline.
4. Schedule a regular review interval to re-validate versions, patches, and settings; or make review a normal part of your SOP that is updated on a regular basis.

Scale that approach across all deployed machine types:

• Enclaves & Virtual Desktop Infrastructure: baseline the image and each supporting component (connection brokers, secure gateways, user-profile layers, and file-system layers).
• Laptops & Workstations: document hardware models and BIOS/UEFI versions, OS build, required apps, GPOs/MDM profiles.
• Servers: OS baselines per role (AD/DNS, file, app, DB), service hardening, approved modules/agents.
• Networking: switch/router/Firewall/WAP firmware baselines, approved feature sets and templates.
• Applications Inventory: version standards, required configs, and how they’re deployed/updated.
• Docs: build guides, change records.

And yes, tie everything to change management controls, because the second you patch, you either (1) update the baseline or (2) record an approved deviation and a plan to reconcile. The guide’s “Potential Assessment Considerations” call out version/patch levels, configuration parameters, network info, and communications with connected systems (proof for [a]/[b]), and timely baseline updates ([c]).

How computers are actually baselined, end-to-end:

1. Procurement & intake: approve models; capture serials/asset tags at receipt; record ownership/location.
2. Imaging: apply the gold image (or Autopilot/MDT/SCCM/Intune flow); inject drivers; enforce policies (GPO/MDM).
3. Hardening: apply CIS/NIST-inspired settings that match your baseline; lock services/ports/protocols; set logging.
4. Application set: install required software; check licensing; verify versions.
5. Join & place: join to domain/MDM; put it in the right OU/MDM group/VLAN/segmented subnet.
6. Recordkeeping: update the inventory with HW/SW/firmware/docs and network details; save the build sheet and sign-off.
7. Review cadence: calendar-based (e.g., quarterly) and/or event-based (whenever a major patch lands) to keep baseline and inventory current ([c], [f]).

3) Why This Control Fails (Top-10, sitting at #10)

Short answer: it’s a lot of work. and it’s the kind that doesn’t scream until something goes terribly wrong…

• Documentation feels heavy. A real baseline covers hardware, software, firmware, and documentation and needs regular updates. That is inherently more than “we have an image.” It is buildout documentation, version matrices, network placement, and the approval trail that shows the baseline evolved with your environment.
• Inventory discipline gets neglected. Many shops run with a “good enough” list. CMMC expects manufacturer, model, serial, location, owner, license/version data, and network identifiers; and expects you to keep it aligned to reality. If the list doesn’t match what’s plugged in, you’ll feel it during interviews and evidence review… and potentially a failed assessment.
• Change is constant. Patches, feature updates, firmware drops, and hardware refreshes mean your baseline and inventory are living artifacts. If you don’t have a trigger to update both when changes roll out, drift creeps in, and you’ll miss [c]/[f] maintenance requirements.
• Historical culture. Plenty of orgs “got by” without rigorous Change Management and Asset Inventory. CMMC is forcing the shift from tribal knowledge to documented, reviewable practice. Assessors will Examine/Interview/Test to verify it’s not just policy on paper.
• Tool sprawl and ownership ambiguity. If imaging is owned by one team, firmware by another, and inventory by a third, gaps appear. You need clear roles and a single source of truth that each team updates as part of their workflow (again, the guide’s methods target exactly these mechanisms).

4) A Quick checklist you can actually use:

• A baseline configuration exists for each asset class (VDI, laptop/WS, server roles, network devices, key apps) with:
  • Versions/patch levels, hardened settings, required software, network placement, and rationale (A/B).
  • An update log proving periodic and event-driven reviews (C).
• A system (asset) inventory exists and matches production, with HW/SW/firmware/docs and the who/where/how (D/E).
• A cadence (calendar + change triggers) keeps both baseline and inventory in sync with reality (F).
• Evidence on hand for assessors: policies, CM plan/SSP, build sheets, images/scripts, install/removal/change records, inventory review logs, asset inventory dashboards, and interviews with the people who actually do the work (the assessment guide lists these explicitly).

Sources:

• CMMC Assessment Guide – Level 2, CM.L2-3.4.1 (practice statement, objectives a–f, methods, discussion, example).
• NIST SP 800-171A, 3.4.1 (assessment objectives and methods).
• NIST SP 800-171r2, 3.4.1 discussion (what belongs in baselines and inventories).