A baseline configuration is the documented, approved state of a system: versions, settings, and components. You keep it under change control, review it on a schedule, and compare reality against it to spot drift or unauthorised change. Keep it small, current and owned by one named person.
What the control says
NIST SP 800-53 CM-2 asks for an up-to-date baseline configuration for the system, documented and under change control, reviewed on a defined schedule, when defined circumstances arise, and whenever components are installed or upgraded. Related CM-9 asks for a configuration management plan covering roles, how configuration items are identified, and which components are items under management.
What goes in a baseline
You do not need a giant document. For each system type, record:
- Operating system or base image and version.
- Installed software and versions that matter.
- Security settings: disk encryption, firewall rules, password and lock rules, logging agent.
- Network settings: open ports, allowed sources.
- Cloud settings: storage access, identity rules, regions.
- Owner and last review date.
For laptops, that might be a short list of managed settings. For a container service, it might be an image definition and a deployment manifest.
Prefer code over documents
A baseline that lives as infrastructure code, an image definition or a device management profile stays accurate because deployment uses it. A wiki page decays. Where you must use a document, link it to the thing that enforces it.
CM-2(2) points the same way: use automation to keep the baseline current, complete and accurate.
Keep previous versions
CM-2(3) describes retaining earlier baseline versions so changes can be rolled back. Version control gives you this for free if the baseline is code. Keep at least the last known good version.
Separate dev and test
CM-2(6) describes a separate baseline for development and test environments. Know what differs from production, so you do not assume a test result applies when a setting differs.
Use it to find drift
Once a month, or continuously where tools allow, compare running systems to the baseline. Differences fall into three groups: approved changes you forgot to record, harmless drift, and unauthorised change. Handle the first by updating the baseline through change control. Investigate the third.
Who owns it
One owner per baseline, with a named backup. Review when a major version changes, when a security issue affects a component, and at least on the schedule you wrote down. Link it with your change management policy so updates to the baseline go through the same approval path.
Safeguard's asset discovery can help find systems that have no baseline yet, and its SBOM and dependency scanning can list the components in software you build.
Quick check
Is a baseline the same as a hardening guide?
Not quite. A hardening guide is a recommended standard. Your baseline is what you actually adopted and approved, which may be a subset or a tailored version.
How many baselines do I need?
One per distinct system type, such as laptops, a standard server image, and a container platform. Fewer is easier to keep accurate.
Sources
- CM-2 Baseline Configuration, NIST SP 800-53 Rev. 5
- CM-9 Configuration Management Plan, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
