CM-2: Baseline Configuration

Quick-reference card

What this control requires

CM-02 requires organizations to develop, document, and maintain a current baseline configuration for every system under configuration control. A baseline configuration is the agreed-upon specification of a system’s hardware, software, firmware, network topology, and security settings at a given point in time. It serves as the reference point against which all future changes are measured, approved, and audited.

Without a documented baseline, teams cannot determine whether a system has drifted from its intended state. Drift detection depends on having a known-good starting point that captures connectivity, operational parameters, and communications architecture. Baseline configurations must reflect the current enterprise architecture and include security and privacy control implementations, component inventories, and logical placement of components within the network.

Maintaining a baseline is not a one-time activity. Organizations must review and update baselines at a defined frequency, whenever circumstances require it (for example, after a vulnerability disclosure or organizational restructuring), and whenever system components are installed or upgraded. Each update produces a new baseline that supersedes the previous version.

Why it matters

Organizations that lack documented baseline configurations cannot demonstrate control over their environment during an audit. Auditors and assessors look for evidence that the organization knows what its systems should look like and can prove it. Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings.

Gaps in configuration management compound over time. A missing baseline means configuration changes go untracked, drift accumulates, and incident responders lose visibility into what changed and when. The longer an organization operates without a formal baseline, the more expensive and disruptive remediation becomes.

Regulatory frameworks beyond NIST SP 800-53 increasingly expect documented baselines as a prerequisite for certification. FedRAMP, CMMC, and StateRAMP assessors all trace their configuration management requirements back to CM-02, making it a foundational control for any organization pursuing federal compliance.

What attackers exploit

• Configuration drift: Untracked changes create openings that vulnerability scanners and penetration testers routinely discover. Without a baseline to compare against, defenders cannot distinguish authorized changes from unauthorized ones.
• Undocumented components: Systems without baseline inventories often contain forgotten services, outdated libraries, or unauthorized software that attackers target.
• Inconsistent environments: When production, staging, and development environments lack a common baseline, security controls tested in one environment may not exist in another.
• Delayed patching: Organizations without documented baselines struggle to identify which systems are affected by a new vulnerability, slowing their response.
• Privilege creep in configurations: Without periodic baseline review, system permissions and access control lists expand over time, increasing the attack surface.

How to implement

For your organization

The primary challenge with CM-02 is not creating the first baseline but sustaining it. Many organizations document an initial configuration during system deployment and never revisit it, leaving the baseline stale within months.

The scope of that baseline depends on every system component within your authorization boundary. For each system, capture the operating system version, installed software and versions, network configuration, enabled services, security settings, and logical network placement. Store this information in a configuration management database or a version-controlled repository that supports change tracking.

Without a defined review cadence, baselines go stale. Set a schedule in your configuration management policy — at minimum annually, but adjust the frequency based on the system’s risk level and rate of change. High-impact systems that undergo frequent updates may require quarterly or even monthly reviews. Tie baseline updates to your change control process so that every approved change triggers a baseline revision.

In practice, manual baseline tracking does not scale, and human error introduces inaccuracies. Use configuration scanning tools to compare live system states against documented baselines and flag deviations automatically.

Common mistakes to avoid:

• Documenting baselines in spreadsheets that are not version-controlled
• Treating baseline creation as a project milestone rather than an ongoing process
• Failing to update the baseline after emergency or out-of-band changes
• Storing baseline documentation separately from the change control records, making correlation difficult during audits

For your vendors

Assessing CM-02 in your supply chain requires verifying that vendors maintain documented, current baselines for the systems that process, store, or transmit your data. Request evidence that baselines exist, are version-controlled, and are updated at a defined frequency.

What separates a credible vendor from a checkbox exercise is the supporting evidence. Ask for the vendor’s configuration management policy and a recent baseline review record. The policy should define who is responsible for maintaining baselines, how often they are reviewed, and what triggers an update. The review record should show that the process is actually followed, not just documented.

The gap that auditors actually find most often is a lack of drift detection. Evaluate whether the vendor uses automated tools to identify configuration drift. If a vendor cannot demonstrate that deviations from the baseline are detected and remediated in a timely manner, that gap increases your third-party risk exposure.

Beyond assessment, CM-02 compliance should be a contractual requirement in your vendor agreements. Specify that the vendor must notify you of material changes to baseline configurations that affect systems handling your data. UpGuard Vendor Risk helps teams continuously monitor vendor security posture and identify configuration management gaps before they become audit findings.

Common mistakes to avoid:

• Accepting a vendor’s assertion of compliance without requesting supporting evidence
• Reviewing vendor baselines only during initial onboarding and never reassessing
• Failing to define what “material change” means in the context of baseline updates
• Not including baseline configuration requirements in service-level agreements

Evidence examples

Cross-framework mapping

Organizations pursuing multiple certifications should map CM-02 requirements against these overlapping controls to reduce duplicated effort. ISO 27001 Annex A 8.9 addresses configuration management broadly, while NIST SP 800-171 narrows the scope to controlled unclassified information in nonfederal systems.

Related controls

• AC-19 (Access Control for Mobile Devices): Baseline configurations for mobile devices must account for access control policies that govern how these devices connect to organizational systems.
• AU-06 (Audit Record Review, Analysis, and Reporting): Audit log analysis depends on baseline configurations to distinguish expected system behavior from anomalous activity.
• CA-09 (Internal System Connections): Documenting internal system connections in the baseline ensures that authorized interconnections are tracked and unauthorized ones are detected.
• CM-01 (Policy and Procedures): The configuration management policy established under CM-01 defines the requirements and processes that CM-02 baselines must follow.
• CM-03 (Configuration Change Control): Every approved change under CM-03 should trigger a corresponding baseline update to keep the documented configuration current.
• CM-05 (Access Restrictions for Change): Restricting who can modify system configurations directly supports the integrity of documented baselines.
• CM-06 (Configuration Settings): Configuration settings are a subset of the baseline, specifying the specific parameters applied to system components.
• CM-08 (System Component Inventory): The component inventory feeds directly into the baseline, providing the list of hardware and software that the baseline must document.
• CM-09 (Configuration Management Plan): The configuration management plan governs how baselines are created, maintained, reviewed, and updated over time.
• CP-09 (System Backup): System backups should align with baseline configurations so that restored systems return to a known-good state.

Frequently asked questions

What is NIST SP 800-53 CM-02?

CM-02 is the baseline configuration control within the NIST SP 800-53 framework. It requires organizations to develop, document, and maintain a current baseline configuration for each system, then review and update that baseline at defined intervals and whenever system components change. The control applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal information systems.

What happens if CM-02 is not implemented?

Failure to implement CM-02 introduces audit risk and may result in certification withdrawal or regulatory findings. Without a documented baseline configuration, organizations cannot prove that their systems are in a known, authorized state. Assessors evaluating NIST 800-53 compliance will flag the absence of baseline documentation as a significant deficiency, potentially delaying or blocking authorization to operate.

How do you audit CM-02?

Auditing CM-02 starts with verifying that a current baseline configuration document exists for each system in scope. Assessors review whether the baseline is maintained under configuration control, updated at the organization’s defined frequency, and revised when system components are installed or upgraded. They examine change control records to confirm that baseline updates correspond to approved changes and check automated scan reports that compare live configurations against the documented baseline.

How often should baseline configurations be updated?

The update frequency depends on your organization’s defined cadence and the system’s risk profile. At minimum, you should review baselines annually, but systems with frequent changes or higher impact levels typically require quarterly reviews. Beyond scheduled reviews, you must update baselines whenever system components are installed, upgraded, or removed, and whenever organizational circumstances require it, such as after a significant security incident or architectural change.