CM-2 Baseline configuration: requirements and evidence

What CM-2 baseline configuration requires and why assessors care

CM-2 requires the organization to develop, document and maintain a current baseline configuration for each system under configuration control, and to keep that baseline under formal control so it reflects what the system actually runs. If an assessment is coming, the compliance lead needs a baseline document per system, a named owner, and evidence that the baseline was reviewed and updated on time. The control has three update triggers: a review at a frequency the organization defines, updates when defined circumstances require them, and updates when system components are installed or upgraded. Assessors test each trigger separately, so a baseline that was accurate at go-live but never revisited will fail even if nobody can point to a specific bad change.

Assessors care because drifting configurations are where undocumented risk accumulates. A baseline is the reference point that other controls depend on. Change control under CM-3 needs a baseline to measure a proposed change against, secure settings under CM-6 need a documented starting point to check for deviations, and the component inventory under CM-8 needs to match what the baseline says is deployed. When the baseline is wrong, those controls quietly test the wrong thing. The control also carries enhancements that matter for moderate and high baselines in SP 800-53B: CM-2(2) asks for automation that keeps the baseline accurate and current, and CM-2(3) asks the organization to retain previous baselines so it can roll back and show history.

The hard part is usually organizational rather than technical. Many systems have no single agreed baseline, and the configuration lives in three places: an architecture document, a build script and a running host that someone patched by hand. Where a baseline does exist, it often sits in a document last edited at deployment, with no link to the change records that should have updated it. Before the assessment, confirm who owns each system's baseline, which components it covers, what the defined review frequency is, and where the previous versions are kept. Then compare one live system against its documented baseline. The gap you find in that comparison is the work plan.

Which systems and baselines CM-2 applies to in scope

SP 800-53B selects CM-2 for the low, moderate and high baselines but not the privacy baseline, so the first scoping question is which impact level the system carries. The cards below cover the decisions that set how much baseline work lands on your team, from the system boundary to shared and third-party components.

Impact level sets the enhancements

CM-2 itself applies at low, moderate and high, so every in-scope system needs a current baseline. The enhancements are where impact level matters: CM-2(2) for automation that keeps the baseline accurate and current, and CM-2(3) for retaining previous configurations are selected at moderate and high, and CM-2(7) for configuring systems in high-risk areas also appears there. Confirm the impact level in your security categorization before estimating the enhancement work.

Privacy baseline does not select CM-2

Systems that handle only personally identifiable information under the privacy baseline do not pick up CM-2 from that baseline. Teams often assume a privacy-driven system is out of scope for configuration work, but the security baseline selected for the same system still governs it. Confirm which baseline your authorization package cites before scoping CM-2 as privacy-only work.

System boundary and component classes

A baseline must describe every component inside the boundary: operating systems, hypervisors, network devices, databases, containers, endpoints and the management tools themselves. Decide early which classes are in the authorization boundary and which are external services, because each class needs its own baseline definition and an owner. Gaps usually appear at the edges, such as backup appliances, jump hosts and monitoring agents.

Shared platforms and common controls

Shared hypervisors, identity services and logging platforms often serve several systems. Decide whether the baseline for a shared platform is documented once and inherited, or repeated per system with its own deviations. Inherited baselines reduce duplicate work but need a clear owner and a statement of which system owns each setting, so an assessor can trace evidence back to the platform.

Third-party managed components

Where a provider operates a component, such as a managed database or SaaS control plane, you still need to know its configuration state and how it changes. Ask the provider for its configuration baseline, change notification commitments and evidence of its own configuration control. Record where your baseline ends and the provider's begins, and agree in the contract how changes will be shared with you.

Components in high-risk areas

CM-2(7) asks for specific configuration of systems and components placed in high-risk areas, such as locations or environments where the risk of loss or tampering is elevated. Identify which components fall into that category through your risk assessment, and document the additional configuration measures applied to them separately from the general baseline. Confirm the definition of high-risk areas with your authorizing official.

How an assessor tests CM-2 under SP 800-53A

This table maps the parts of CM-2 that an assessor checks under SP 800-53A to the assessment method, the evidence usually requested and the common reasons a baseline review fails. Read it as a preparation checklist: each row shows what the assessor will ask to see and where organizations most often fall short.

Assessment element	What the assessor examines or tests	Evidence that usually passes	Where it commonly fails
Examine: plans and architecture	Whether the configuration management plan and enterprise architecture documentation describe how baselines are set, owned and updated for the system	Approved configuration management plan, current system architecture diagrams and a configuration document tied to the system boundary	Plan is generic, unsigned or not updated after architecture or boundary changes
Examine: component inventory and change records	Whether the baseline matches the components listed in the system component inventory and whether change control records show baseline updates	Inventory export reconciled to the baseline, dated change tickets that reference baseline updates	Inventory and baseline use different identifiers, or changes are made without a matching baseline update
Interview: configuration management personnel	Whether the people who own baselines can explain the review frequency, triggers for updates and how exceptions are handled	Consistent answers that match the written procedure and recent review records	Owners cannot name the review trigger, or responsibilities are split with no clear accountable role
Interview: system and network administrators	Whether administrators know which baseline applies to each component and how they deploy and verify it	Administrators describe the same build source and verification steps shown in the documentation	Administrators configure systems from memory or local images that differ from the approved baseline
Test: managing baseline configurations	Whether the organization's process for creating, updating and retaining baselines works in practice on sampled components	Sampled system compared to its baseline with recorded differences, approvals and remediation	Sampled production systems drift from the documented baseline with no record of the difference
Determination: review and update frequency	Whether the baseline is reviewed at the frequency the organization defined and after component installs or upgrades	Dated review records and change entries for recent installs or upgrades	Review records are missing for periods after an upgrade or after a component was added
Determination: previous configurations retained (CM-2(3), moderate and high)	Whether earlier baseline versions are kept so the organization can roll back or explain past states	Versioned baseline archive with dates and owners for each retained version	Only the current baseline exists, so prior states cannot be reconstructed
Determination: high-risk areas (CM-2(7), moderate and high)	Whether components in defined high-risk areas receive extra configuration before connection to the system	Documented high-risk area list and hardened configuration records for those components	High-risk areas are not defined, so no extra configuration can be shown
Illustrative finding	A sampled server runs a package version newer than its baseline, and no change ticket records the update	Assessor records a finding unless the baseline is updated or the change is traced to an approved request	Organizations often discover this gap only during the assessment, so sampling against the baseline before testing helps

Sequence for building and maintaining a CM-2 baseline

This sequence turns CM-2 from a document requirement into a living, controlled baseline that an assessor can trace from the approved configuration to the systems actually running. Each step produces an artifact that the next step depends on, so the baseline stays accurate as components change.

Define the system boundary and components in scope
Start by fixing which system the baseline describes: its hosts, containers, network devices, applications, databases and the management tools that touch them. The system security and privacy plan usually already states the boundary, and the owner of that plan confirms it here. Record any component that sits outside the boundary but connects to it, so the baseline can reference it. The output is a scoped system description that the configuration management team and the system owner both sign off on. You know this step is done when every component in the inventory has a clear inside or outside decision.
Agree baseline content and assign an owner
Decide what the baseline records for each component class, such as operating system version, installed packages, security-relevant settings, network services, and the approved software image or template. Name a single accountable owner for the baseline and a reviewer for each component class. The baseline content should point to the secure configuration settings in CM-6 and the software allowed under CM-7 rather than repeating them in full. The output is a baseline content specification and an owner assignment, recorded in the configuration management plan. Confirm the ownership model with your own governance team, since the required roles are set by your organization.
Capture the current state from authoritative sources
Collect the actual configuration of each in-scope component from the systems themselves, not from memory or from the design document. Use configuration management tools, agent-based inventory, cloud configuration exports, or infrastructure-as-code repositories, and reconcile the results against the inventory from CM-8. Where two sources disagree, investigate the drift before accepting either one. The output is a captured configuration record for every component, with the source and collection date noted. The step is complete when the record covers the full scoped inventory and each discrepancy has a documented resolution.
Approve the baseline and place it under configuration control
Compile the captured state into a baseline document or versioned configuration set, then route it through the approval body defined in the configuration management plan. Store the approved version in a repository with access restricted to authorized change personnel, so that every edit creates a traceable revision. Assign a version identifier and record the approver and approval date. The output is an approved, versioned baseline held under configuration control. Confirm with your assessor which repository and approval record format they will accept as evidence.
Set the review frequency and update triggers
Define how often the baseline is reviewed and which events force an immediate review. CM-2 requires a defined review frequency, defined circumstances, and an update whenever components are installed or upgraded, so write each of these down as a concrete rule. Typical triggers include a patch cycle, a new component class, a change to the security configuration standard, or a finding from a security assessment. Fix the frequency value in the configuration management plan and the procedures that support it. The output is a documented review schedule and trigger list that the change process and the owner both reference. The step is done when every trigger maps to a named owner and a recorded action.
Tie every baseline update to a change record
Connect each baseline revision to the change record that justified it, so the baseline and the change history can be read together. Under CM-3 each proposed change passes through impact analysis and approval before implementation, and the approved change then triggers a baseline update and a fresh capture of the affected components. Use ticket identifiers in the baseline version notes so an assessor can trace a configuration back to its authorization. The output is a linked record set showing each baseline version, the change that produced it, and the verification that the live system matches. The step is done when a sample of recent changes can be traced in both directions without gaps.

Which evidence shows a current, controlled CM-2 baseline

An assessor testing CM-2 looks for a baseline that exists, matches reality and changes on schedule and on trigger. The cards below cover the artifacts that prove this, and the routine that keeps each one current between assessments so it is not rebuilt for every audit.

Approved baseline documents per component class

Each class of component (for example, Linux application servers, container hosts, network devices and endpoint images) needs its own approved baseline document, owned by a named role and signed off by the change control body. The document should list OS and package versions, configuration files, enabled services and security settings. Check that every production component maps to exactly one baseline and that the approval date is later than the last material change. Store the documents in version control so the approval history is itself evidence.

Version history at the defined frequency

The assessor will compare the dates of baseline updates against the review frequency your organization defined in its CM-2 procedure, and against the dates of component installations and upgrades. Gaps are findings even when the current baseline is accurate. Keep a commit or revision log that records who changed what, why, and which change request authorized it. Confirm the frequency you wrote into policy is one you actually meet, because an unmet self-imposed schedule is easier to spot than a missing one.

Retained previous configurations (CM-2(3))

Where CM-2(3) is in scope (moderate and high baselines), the organization must keep earlier baselines so it can roll back a component or reconstruct its state at a past date. Evidence is a retained archive of prior baseline versions, with retention periods that match your rollback and incident needs. Test a restore from a retained version at least once and record the result. Confirm with your configuration management tool that old versions cannot be deleted silently by an administrator.

Automated comparison and drift output (CM-2(2))

CM-2(2) asks for automation that keeps baselines accurate and current. Evidence is the output of a scheduled comparison between the approved baseline and the running state, such as drift reports, failed checks and the tickets they generated. Keep several reporting cycles in the archive so an assessor can see the comparison ran continuously, not only the day before the assessment. Confirm which tool performs the comparison, which fields it checks, and how it treats unexplained differences.

High-risk area configuration records (CM-2(7))

CM-2(7) applies to systems in areas the organization has defined as high risk, such as internet-facing zones, administrative networks or systems handling regulated data. The evidence is a distinct, stricter baseline for those components, with records showing the extra restrictions applied and the reviews that confirmed them. Keep a list of which components sit in each high-risk area and check it against the inventory, because an assessor will test whether the scope definition is accurate.

Keeping evidence current between assessments

Build the evidence as a by-product of normal operations rather than a reconstruction. Generate baseline exports, drift reports and retention archives on a schedule, store them with timestamps in a write-once location, and review them at a fixed monthly or quarterly point. Assign an owner to the review and record exceptions. Before an assessment, the team checks coverage (every component, every class) rather than rebuilding documents. Ask any implementation partner to deliver this routine as a documented runbook so your own staff can operate it after handover.

What meeting CM-2 costs in money and effort

This table breaks down the cost components of keeping a CM-2 baseline current, marks which items are one-time and which recur, and names the drivers that raise or lower each one. Use it to shape a written scope and to know what to ask for in a quote, since NIST does not publish cost figures for this control.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it
Baseline build and reconciliation	Internal engineers, with an implementation partner if engaged for scope	One-time, then recurring at each review	Number of component classes, count of distinct builds, and how far current documentation matches live systems
Configuration tooling and licenses	Tool vendor or open-source project maintainers, plus internal operators	Setup is one-time, licenses or support may recur	Open-source tools remove license spend but still need hosting, integration and tuning effort
Automation of baseline capture (CM-2(2))	Engineers building pipelines and drift checks	One-time build, recurring maintenance	Heterogeneity of platforms and how often the automation must be updated as components change
Retention of previous baselines (CM-2(3))	Operations staff and storage owners	Recurring storage and periodic review	Retention period set by the organization and the volume of snapshots kept per component
Baseline updates on component change	Change owners and reviewers	Recurring, tied to change frequency	Release cadence, patch volume and how many changes route through formal change control (CM-3)
Evidence upkeep for assessors	Compliance leads and system owners	Recurring at each assessment cycle	Number of systems in scope and whether baseline records are generated automatically or assembled by hand
External review and assessor sampling	Independent assessor or certification body, paid by the organization	Recurring at each assessment	Sample sizes the assessor selects, quality of the baseline record, and how many findings need rework
Configuration for high-risk areas (CM-2(7))	Security engineers and system owners	One-time hardening, recurring checks	Number of high-risk components, the hardening standard chosen, and the depth of separate testing

Which open-source tools produce CM-2 evidence

Wazuh's Security Configuration Assessment (SCA) module is the most direct source of evidence that endpoints match a documented configuration. It scans monitored endpoints against YAML policy files that check files, directories, registry keys and running processes, then reports which checks pass or fail and what remediation to apply. Because the policies are mostly based on CIS benchmarks, the output is a set of measured deviations from a published reference. The organization still has to decide which of those settings form its own approved baseline.

Policy-based checks: Each YAML policy lists the checks applied to a target, so the policy file itself becomes part of the baseline record.
Scan results over time: Stored scan results show whether endpoints drifted from the baseline between assessment periods.
Custom policies: Organization-specific baseline settings can be written as additional policies so the checks reflect the approved configuration, not only the reference benchmark.
Remediation guidance: Failed checks include recommended fixes that can feed the change control record required by CM-3.
License note: Wazuh is licensed under GPL-2.0-only, so confirm how the license applies to any modifications you make.

Confirm which policy files and versions were active for each scan period, and whether your custom policies were reviewed and approved as part of the baseline.

Where CM-2 programs usually fall short

Most CM-2 findings are not about a missing document. They come from baselines that drift away from production, review cycles nobody owns, and records that cannot show what the system looked like at a given date. Each card below names one gap and the action that closes it.

Baselines drift from production

The baseline is written once during deployment and then production changes without it. An assessor compares the documented baseline against the live configuration, so any unrecorded package, port or setting is a finding. Close the gap by generating the baseline from a reviewed source of truth and checking live systems against it on a schedule. Ask who signs off each update and whether the baseline names the components it covers.

No defined review frequency

CM-2 requires a review and update at a frequency the organization defines, plus updates when components are installed or upgraded. Many programs never set that frequency, so the assessor has no yardstick to test against. Write the interval into the configuration management plan and the procedures, then keep dated review records. Confirm that the frequency in the document is the one teams actually follow.

Previous configurations not retained

CM-2(3) asks for retention of previous baseline versions so that the organization can roll back and reconstruct the state of the system at an earlier date. Overwriting the baseline in place removes that history. Keep each approved version in version control or a configuration store with its approver and date. Ask whether retention periods are defined and whether older versions can be restored during an incident.

Baselines not tied to change records

A baseline that changes without a matching change ticket cannot be justified during assessment. CM-3 change records, CM-4 impact analyses and the CM-2 baseline should reference each other, so that every approved change maps to a new baseline version. Close the gap by requiring the change identifier in the baseline commit and by reconciling the two sets of records at each review. Ask whether unapproved drift triggers an alert.

High-risk components left out

CM-2(7) asks that systems and components used in high-risk areas receive additional configuration, such as stricter settings or restricted functions, before deployment there. Programs often apply one baseline to every host and never document what makes a high-risk area different. Define the high-risk areas in the system security plan, list the components that serve them, and document the extra configuration for each. Confirm the enhancement applies in the moderate and high baselines.

How long, how costly and how much work CM-2 takes

How much effort does building the first CM-2 baseline take?

The effort depends mainly on how many components the system has, how much of their current configuration is already documented, and how many separate environments must be baselined. NIST does not estimate compliance costs or timelines, so no published effort figure applies to your system. Expect the work to cover four things: listing the components in scope, capturing each component's configuration (operating system, hardware, software versions, and security settings), recording the result in a document or repository under configuration control, and getting the owner of the system to approve it. Systems with many heterogeneous components, undocumented legacy hosts, or several production and test environments take longer. Ask any partner to break the estimate down by component group and environment.

Can our team build the CM-2 baseline without an outside partner?

Yes, if your team has the skills to read and document system configurations and the authority to approve them. The control is written to be implemented by the organization, and the organization owns it. An outside partner is useful when internal staff are fully loaded, when no one has done configuration capture across the environments before, or when you need evidence arranged for an independent assessor. Any partner prepares systems, configurations and evidence, but only an independent assessor issues an assessment result. Whichever route you choose, agree on who signs the baseline and who maintains it after handover.

What does CM-2 need from system owners and administrators?

System owners need to accept the baseline as the approved configuration for their system, and administrators need to supply accurate facts about what is actually running. In practice this means system owners confirm scope and the intended role of each component, while administrators provide configuration data, change history and exceptions. Plan for review time from both groups, and make sure someone with authority can resolve disagreements between the documented and the actual state. Assessors typically interview the people who manage configuration, so those people must be able to explain the baseline and how it is kept current.

How often must a CM-2 baseline be updated?

CM-2 requires the baseline to be reviewed and updated at a frequency the organization defines, when defined circumstances require it, and when components are installed or upgraded. The control leaves the review interval to you, so the figure you set and the one your assessor expects must match your own documented policy. Recurring work includes reviewing the baseline on schedule, updating it after each approved change, and recording exceptions. Ask your assessor which interval they will accept and what evidence shows that the defined frequency is followed.

Can CM-2 be automated, and what does the automation enhancement require?

Parts of CM-2 can be automated. The control has an enhancement for automation support to keep the baseline accurate and current, and tools can collect configuration data, compare it with the approved baseline, and flag drift. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies. Fleet policies ask yes or no questions of devices through osquery and show which devices pass or fail. GLPI and Zabbix can hold component inventory data that feeds the baseline record. Automation does not remove the need for an approved baseline and a documented process. Confirm each tool's capabilities against your environment before relying on it as evidence.

What should a written scope for CM-2 work include?

A written scope should name the systems and environments covered, the components in each, the baseline format and storage location, the owners who approve it, and the update triggers. It should also state which NIST SP 800-53 baseline applies (low, moderate or high, since CM-2 is in all three but not the privacy baseline), whether the enhancements for automation, retention of previous configurations and high-risk areas are in scope, and what evidence will be delivered. Ask for deliverables, acceptance criteria, responsibilities for each party, and what happens if the system changes during the work. A fixed-scope agreement fixes these items before work starts, so the quote follows from them rather than from guesswork.

How DeployOpen prepares CM-2 baselines and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the baseline configurations and evidence that CM-2 assessors examine. Your organization keeps ownership of its controls, and an independent assessor decides whether CM-2 is met.

How we scope

Engagements are fixed-scope, with systems, components and baseline targets agreed in writing before work starts.
The written scope names which systems fall under configuration control and which baseline tier, such as low, moderate or high, applies.
Scope also states whether CM-2(2), CM-2(3) or CM-2(7) enhancements are in or out, based on your selected baseline.

How we build

We document a current baseline configuration for each in-scope platform component under your configuration control process.
Where tooling allows, we configure automated checks that compare live systems with the approved baseline and flag drift.
We set review triggers for the defined frequency, for significant changes, and for component installs or upgrades.

How we hand over

You receive baseline documents, configuration records and the review schedule, mapped to the examine, interview and test items in SP 800-53A.
Previous baseline versions are retained in a location you control, supporting the retention expectation in CM-2(3).
Handover includes a short walkthrough so administrators can explain baselines to an assessor, who then tests the evidence independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover periodic baseline reviews, updates after component changes and refreshes after NIST releases new control content.
Support scope, response expectations and review frequency are confirmed in writing before any retainer begins.

CM-2 Baseline configuration