System Baselining

A baseline says what a machine should be, not what it happens to be.

Exporting the current configuration of a workstation is a backup, not a baseline. Write down the operating system edition and version, the standard software with version minimums, and the security-relevant settings you have decided on, then compare machines against that document. Objective [a] asks for the decided state, and the comparison is how you maintain it under [c].

This requirement produces two artifacts, and the objectives split evenly between them.

Objectives [a] through [c] are the baseline configuration. [d] through [f] are the system inventory. Both must cover hardware, software, firmware, and documentation under [b] and [e]. Software and documentation are the two categories that get skipped: list the software on the machines, not just the machines, and point each hardware and software entry at its vendor documentation.

A spreadsheet is a compliant inventory for a small company.

Nothing in the objectives asks for an asset management platform. A spreadsheet with manufacturer, model, serial number, location, assigned owner, installed software, and firmware versions satisfies [d] and [e]. Buy tooling when the row count makes manual upkeep fail, not before.

Enforce the baseline with whatever pushes settings. The document is what the requirement asks for.

Group Policy, Intune, a standard image, or a written build procedure all work as the mechanism, and no tool is required by name. The test is two questions. Are assets of the same type configured the same? Can you produce the document that says how they are supposed to be configured? A tenant full of Intune policies with no written baseline fails the first half of that test.

Standardize before you document.

Every operating system, hardware brand, and one-off appliance you keep is another baseline to write and maintain. Fewer platforms means fewer baselines, and that is the biggest reduction in effort available under this requirement.

Maintained means reviewed on a schedule and updated on change.

Objectives [c] and [f] fail when the documents go stale. Update the baseline when your change process approves a change to it. Update the inventory when hardware or software enters or leaves. Put a recurring review on the calendar to catch what slipped through.

Finish this before assessment, because it cannot wait on a plan of action and milestones.

A plan of action and milestones is the corrective plan that lets certain gaps be closed after assessment. CM.L2-3.4.1 is a five-point basic security requirement under the scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21, a Conditional status plan may only include requirements worth one point, with a single named exception that is not this one. A missing baseline or inventory is a five-point deduction with no deferral path.