CM-2: Baseline Configuration

The cm-2: baseline configuration requirement is one of those controls that sounds simple until an assessor asks, “Show me the baseline,” then follows with, “How do you know it’s current, approved, and enforced?” CM-2 is less about writing down settings and more about running an operating model: define what “approved” looks like, record it in a durable way, put it behind change control, and continuously reconcile reality against that baseline.

For compliance leaders, CM-2 is a foundational dependency for vulnerability management, incident response, patch governance, and audit-ready system security plans. If you cannot prove what the system is supposed to look like, you cannot credibly prove it’s securely configured today or that changes were authorized. The fastest path is to scope the systems, choose baseline sources (build standards, secure configuration benchmarks, golden images, infrastructure-as-code), then implement a repeatable workflow that produces the same evidence every time.

This page gives requirement-level guidance you can hand to control owners and implementers: who owns what, the minimum set of artifacts to retain, common audit traps, and a practical execution plan that gets you to “assessor-ready” without boiling the ocean.

Regulatory text

Requirement (excerpt): “Develop, document, and maintain under configuration control, a current baseline configuration of the system; and” ¹

What the operator must do:

1. Develop a baseline configuration for each in-scope system (what components exist and how they must be configured).
2. Document that baseline in a form your organization can review, approve, and reproduce.
3. Maintain it so it stays current, and keep it under configuration control so changes are authorized and traceable. ²

Plain-English interpretation (what CM-2 really demands)

A baseline configuration is your organization’s answer to: “What is this system, what is installed, and what settings are approved?” CM-2 expects the baseline to be:

• Specific: not “harden servers,” but “these OS versions, these packages, these services enabled/disabled, these security settings, these approved ports, these standard agents.”
• System-scoped: tied to a defined system boundary (the same boundary you use in your SSP, ATO package, or security documentation set).
• Controlled: you can show who approved changes, when they occurred, and what changed.
• Current: it reflects the present authorized state, not last year’s architecture diagram.

CM-2 pairs naturally with change management and configuration monitoring. You can meet the spirit of the control with different technical patterns (golden images, IaC, MDM baselines, container policies), but you must be able to prove the baseline exists and is governed.

Who it applies to (entity and operational context)

CM-2 is most directly applicable to:

• Federal information systems and the teams operating them ²
• Contractor systems handling federal data, including cloud-hosted environments and managed services where you are responsible for security configuration decisions ²

Operationally, CM-2 applies anywhere you have “configuration” to control, including:

• Endpoints (managed laptops, VDI)
• Servers (on-prem and cloud IaaS)
• Network devices and security appliances
• Cloud control planes (IAM, logging, network constructs)
• Container platforms and Kubernetes clusters
• SaaS tenant settings where you administer security-relevant configuration

If you have shared responsibility with a cloud provider or other third party, CM-2 still applies to the parts you administer. The baseline can include references to third-party managed components, but your documentation should be explicit about responsibility boundaries.

What you actually need to do (step-by-step)

Use the workflow below to operationalize CM-2 without getting stuck in documentation debt.

1) Define the scope and “system”

• List in-scope systems and environments (prod, staging, dev if governed).
• For each system, define the baseline “object types” you will control: OS images, cloud accounts/subscriptions, network segments, cluster configs, endpoint profiles, core apps, and security tooling agents.
• Assign a control owner (accountable) and system custodians (operators).

Output: System inventory aligned to your security boundary, with baseline object types per system.

2) Choose baseline sources and standards

Pick the authoritative source(s) for what “approved” means:

• Golden images (VM templates, AMIs)
• Infrastructure-as-code repos (Terraform/CloudFormation)
• Configuration policies (GPO/Intune/Jamf)
• Kubernetes policies (OPA/Gatekeeper/Kyverno) and cluster config
• Secure configuration benchmarks you adopt internally (document the benchmark and your deviations)

Operator rule: If you cannot reproduce the configuration from the baseline source, it is not a baseline; it is a description.

Output: Baseline standard statement per system (“Baseline is defined by X, with exceptions tracked in Y”).

3) Establish configuration control (the governance mechanism)

“Under configuration control” should map cleanly to your change management:

• Require change tickets (or pull requests) for baseline changes.
• Define approval roles (system owner, security, operations).
• Require pre-deployment testing/validation where feasible.
• Record implementation evidence (merge commit, pipeline run, ticket closure).

Practical control test: Pick any recent change to a security-relevant setting. You should be able to show request → review → approval → implementation → post-change validation.

Output: Written procedure that ties baseline changes to your change control workflow, with required approvers and required records.

4) Capture the current baseline (“known good”) and approve it

This is the step teams skip. You need a point-in-time approved baseline that matches reality.

• Export configuration snapshots (cloud config export, device configuration profiles, server build manifests).
• Normalize them into a baseline record: components, versions, key settings, required agents, required logging and time settings, approved ports/services.
• Review and approve with the system owner and security.

Output: Baseline configuration record ¹ with approval and effective date.

5) Implement drift detection and reconciliation

CM-2 becomes defensible when you can detect deviation.

• Configure technical checks: configuration compliance rules, desired-state config, policy-as-code, CSPM checks, endpoint compliance.
• Define triage paths: when drift is allowed (emergency change) vs. when it is a defect.
• Track exceptions with owner, rationale, and expiration (don’t let “temporary” become permanent).

Output: Drift reports and a documented workflow for remediation or exception handling.

6) Keep the baseline current (maintenance cadence tied to change)

Update the baseline when:

• You release a new standard image or config profile
• You change system architecture materially
• You adopt new security tooling or logging requirements
• You approve exceptions that change the baseline intent

Output: Baseline revision history and change records that show it is maintained.

7) Make it audit-ready (control mapping + recurring evidence)

A common operational gap is “we do it, but we can’t prove it.” Map CM-2 to:

• Named owner(s)
• Implementation procedure
• Recurring evidence artifacts (what, where stored, who pulls it)

Daydream fits here as a practical control operations layer: teams use it to map CM-2 to an owner, document the procedure once, and generate a consistent evidence packet each cycle so audits don’t turn into a scavenger hunt.

Required evidence and artifacts to retain

Auditors typically want artifacts that prove existence, approval, control, and currency. Retain:

• Baseline configuration document/record per system (components, versions, key security settings)
• Baseline source of truth references (image IDs, repo links/commit IDs, configuration profile identifiers)
• Approval evidence (sign-off record, ticket approval, meeting minutes with decision)
• Change control records for baseline changes (tickets, PRs, CAB records)
• Exception register for deviations (rationale, compensating controls, expiry, approvals)
• Drift/compliance reports (CSPM findings, endpoint compliance status, desired-state compliance output)
• Revision history showing the baseline is current (versioning, last review date, changelog)

Store these in a controlled repository with access control and retention aligned to your audit requirements.

Common exam/audit questions and hangups

Expect these questions, and prepare concise, document-backed answers:

1. “Show me the baseline for System X.” Provide the baseline record plus the source of truth reference.
2. “How do you know this is current?” Show revision history and the last change record.
3. “What prevents unauthorized changes?” Walk through change control and permissions.
4. “How do you detect configuration drift?” Show tooling output and remediation workflow.
5. “How do you handle exceptions?” Show the exception register and expiring approvals.
6. “Does the baseline include cloud/IAM/logging?” If not, expect a finding; many teams limit baselines to OS builds and miss control-plane settings.

Hangup to avoid: providing a narrative document without demonstrable control. Assessors will look for traceability from baseline → changes → enforcement.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Baseline is a policy statement (“we harden servers”)	Not testable, not enforceable	Convert to build standards + specific settings + versioned artifacts
No explicit approval	No proof of “authorized” baseline	Add sign-off workflow tied to system owner/security
Baseline exists but is outdated	“Current” requirement fails	Require baseline updates as part of release/change workflows
Drift detection absent or ignored	Baseline doesn’t reflect operations	Implement compliance checks and track remediation/exceptions
Exceptions managed in chat/email	Not auditable, never expires	Central exception register with owner, expiry, and approvals
Scope gaps (cloud control plane)	Real risk sits outside OS configs	Baseline IAM, logging, network, key SaaS settings where you administer them

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-2, so this page does not cite specific enforcement actions.

Operational risk is still direct: without a controlled baseline, you increase the chance of misconfiguration, inconsistent hardening, and inability to prove security changes were authorized. During an incident, teams also lose time determining “what changed” because there is no reliable comparison point.

Practical 30/60/90-day execution plan

Use this as an execution plan you can hand to engineering and audit teams. Timelines are presented as phases; adjust based on system count and complexity.

First 30 days (Immediate stabilization)

• Assign CM-2 control owner and system-level custodians.
• Define system scope and baseline object types per system.
• Choose baseline sources (images/IaC/config profiles) and document where they live.
• Draft the baseline template (what fields every baseline must include).
• Stand up a single evidence repository and naming convention.

Deliverable: One pilot system with an approved baseline record and a documented change workflow.

Days 31–60 (Scale and instrument)

• Baseline the remaining high-risk systems first (internet-facing, sensitive data, privileged access).
• Integrate baseline changes into existing change management (tickets/PR approvals).
• Implement drift detection for the most important control points (IAM, logging, endpoint compliance, server configuration).
• Create the exception register and require expirations.

Deliverable: Baselines for priority systems, plus drift reporting and exception tracking.

Days 61–90 (Operationalize and audit-proof)

• Expand drift detection coverage and define SLAs for remediation vs. exception approval.
• Run an internal control test: sample changes and prove traceability end-to-end.
• Build the recurring CM-2 evidence packet (baseline list, approvals, recent changes, drift reports, exceptions).
• If you use Daydream, configure CM-2 to auto-request the evidence artifacts from owners on a schedule and keep a clean audit trail of submissions and approvals.

Deliverable: Repeatable CM-2 evidence cycle and ready-to-hand auditor packet.

Frequently Asked Questions

What counts as a “baseline configuration” in a cloud-native environment?

The baseline should cover both workload configuration (images, container configs, cluster settings) and cloud control plane settings you administer (IAM, logging, network). Anchor it to a source of truth like IaC plus approved policy configurations.

Do we need a separate baseline for dev, staging, and production?

If the environments differ materially, define separate baselines or a shared baseline with explicit environment-specific deltas. Auditors mainly care that production is governed and that differences are intentional and approved.

How detailed does the baseline need to be?

Detailed enough that you can test compliance and detect drift. Focus on security-relevant settings: identity, logging, time sync, patching configuration, endpoint agents, exposed services/ports, and encryption-related settings.

Can our baseline be “whatever is in Terraform”?

Yes, if Terraform (or equivalent) is treated as the controlled source of truth, changes require review/approval, and you can produce a readable baseline record for auditors. Pair it with drift detection to show the deployed state matches the code.

How do we handle third-party managed components where we can’t change settings?

Document shared responsibility clearly and baseline the configuration settings you can control (tenant settings, roles, logging). For what you cannot control, document the dependency and confirm the third party’s responsibilities through your third-party risk process.

What’s the minimum evidence set to satisfy most assessors?

A baseline record per system with approvals, a change history for baseline updates, drift/compliance reporting, and an exception register. If any one of those is missing, expect follow-up questions.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5