System Baselining

Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.1.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   a baseline configuration is established;

   1 example covers this

2. [b]

   the baseline configuration includes hardware, software, firmware, and documentation;

   1 example covers this

3. [c]

   the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;

   1 example covers this

4. [d]

   a system inventory is established;

   1 example covers this

5. [e]

   the system inventory includes hardware, software, firmware, and documentation; and

   1 example covers this

6. [f]

   the inventory is maintained (reviewed and updated) throughout the system development life cycle.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c][d][e][f]

  CM.L2-3.4.1 · System Baselining

  Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

  • [a]

    a baseline configuration is established;

  • [b]

    the baseline configuration includes hardware, software, firmware, and documentation;

  • [c]

    the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;

  • [d]

    a system inventory is established;

  • [e]

    the system inventory includes hardware, software, firmware, and documentation; and

  • [f]

    the inventory is maintained (reviewed and updated) throughout the system development life cycle.

  Baselines as code and one inventory of record, including firmware and the documents

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. Only 1 verdict so far.Last verdict Aug 2, 2026

  Implementation

  AO coverage. Addresses all six System Baselining objectives: baseline established [a] and covering hardware, software, firmware, and documentation [b]; baseline maintained across the life cycle [c]; inventory established [d] and covering the same four categories [e]; inventory maintained across the life cycle [f].

  Baseline as code [a][b]. Each system role has a baseline expressed as Ansible roles plus a written specification in the same repository. The specification covers the hardware model and configuration the role assumes, the software package set with pinned versions, the minimum firmware level (BIOS/UEFI, switch and array firmware, endpoint TPM), and the documents that belong to the baseline — the role specification itself, its network diagram, and its hardening rationale. Documentation lives beside the code so a baseline version means one identifiable set of settings and papers.

  Inventory of record [d][e]. NetBox holds devices, virtual machines, roles, owners, life-cycle state, serials, and firmware level. Software inventory is collected by osquery and joined to the device record; the firmware fields are populated from the same collection rather than typed in by hand, which is why they are now accurate. Every record links to the baseline version it is supposed to match and to its documentation set.

  Maintenance across the life cycle [c][f]. Baseline changes go through the change process described in the CM.L2-3.4.3 example and produce a new version tag (vYYYY.MM). Procurement and decommission both write to the inventory: nothing is racked without a record, and retirement flips life-cycle state and links the sanitization ticket. A nightly reconciliation compares observed hosts against the inventory and files a ticket for anything present but unrecorded, or recorded but absent for 14 days.

  Maintenance. Nightly reconciliation with ticketed exceptions; quarterly review that each active role still has a current baseline version and that its documents were reviewed within the year; post-upgrade re-diff of the running configuration against the role definition.

  Accepted gap. Two shop instruments run vendor-supplied images we may not modify, so their baseline is the vendor's documented configuration plus our isolation and monitoring requirements. They are inventoried with firmware level and vendor documentation reference, and flagged so nobody assumes our roles apply to them.

  What the evidence looks like

  • Repository showing role definitions, pinned versions, and baseline specification documents
  • Inventory export with hardware, software, firmware, and documentation links
  • Baseline version tags with the change tickets that produced them
  • Nightly reconciliation output and a resulting ticket
  • Vendor-image exception records with their isolation requirements

  Environment

  ~150 endpoints, 30 Linux VMs, 12 switches, and two storage arrays. The prior inventory was a spreadsheet that had not been accurate since the last office move.

  Tools

  • Ansible
  • osquery
  • NetBox
  • Git

  Edit history

  · No edits yet

  1 rating on this revision

  • AlignedCIControlVerdict Implementer@cv-implementerOSCAug 2, 2026

    Across the finish line

    Baseline configuration with drift detection is clear.