CM-2(2): Automation Support for Accuracy and Currency

CM-2(2) requires you to keep your system’s baseline configuration current, complete, accurate, and available by using automation (tools and integrations) to create, update, validate, and retrieve the baseline without relying on manual, error-prone steps. Operationalize it by defining what “baseline” covers, automating capture and drift detection, and retaining evidence that automation runs and results are reviewed. ¹

Key takeaways:

• Treat the “baseline configuration” as a controlled, versioned artifact that automation can generate and validate.
• Automation must support accuracy and currency: detect drift, reconcile approved changes, and prevent stale baselines.
• Evidence is as important as tooling: keep run logs, drift reports, approvals, and baseline versions tied to change records.

CM-2(2): automation support for accuracy and currency requirement is a configuration management expectation: your baseline configuration cannot be a one-time document that slowly becomes fiction. NIST’s intent is operational. You must maintain the baseline’s currency (it matches reality), completeness (covers what it should), accuracy (values are correct), and availability (people and systems can retrieve it when needed) by using automation rather than manual compilation. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn this into three things you can test: (1) a clear baseline scope statement per system boundary, (2) automated mechanisms that produce and validate baseline data, and (3) repeatable evidence that shows the mechanism runs, exceptions are handled, and the baseline stays aligned with authorized change. This control enhancement often fails in practice because teams “have a CMDB” or “have IaC,” but cannot prove the baseline is both accurate and current, or they cannot reproduce what the baseline was at a point in time.

This page gives requirement-level guidance you can hand to a control owner and assess against immediately.

Regulatory text

Control statement (excerpt): “Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using {{ insert: param, cm-02.02_odp }}.” ¹

Operator interpretation: You must use automated support (the “organization-defined parameter” in the control) to keep the baseline configuration reliable over time. In operator terms, automation must (a) produce baseline configuration data from authoritative sources, (b) detect and report drift between approved baseline and actual state, (c) preserve versions/history, and (d) make the baseline retrievable for operations and audits. ¹

Plain-English interpretation (what CM-2(2) is really asking)

Your baseline configuration is the approved “known-good” set of configurations for the system (or system components) within your authorization boundary. CM-2(2) adds a specific expectation: don’t rely on spreadsheets and screenshots to keep that baseline updated. Use automation so the baseline stays accurate and current as the environment changes.

A working baseline program answers four exam-grade questions at any time:

1. What is the approved configuration right now? (baseline, versioned)
2. What is the system actually running right now? (observed state, collected automatically)
3. What is the difference, and is it authorized? (drift + change linkage)
4. Can we retrieve the baseline quickly, including historical versions? (availability + traceability)

Who it applies to (entity and operational context)

Typical in-scope entities

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST 800-53 is flowed down contractually or through an assessment regime that maps to 800-53. ²

Operational contexts where auditors focus

• Environments with frequent change: cloud infrastructure, container platforms, CI/CD, and endpoint fleets.
• Systems where configuration drift creates security exposure: identity settings, network/security groups, encryption settings, logging, EDR configuration, and patch baselines.
• Decentralized ownership (DevOps + platform + app teams) where “baseline” can fragment across repos and tooling.

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

Use this sequence to implement the cm-2(2): automation support for accuracy and currency requirement with minimal ambiguity.

1) Define the baseline scope and “authoritative sources”

Create a one-page Baseline Scope Statement per system:

• System boundary and component categories (compute, network, IAM, OS baseline, platform services, key security tools).
• Where baseline truth lives (examples: IaC repositories, golden images, MDM profiles, secure configuration policies, CMDB entries).
• What is explicitly excluded and why (keep exclusions small and documented).

Deliverable: Baseline Scope Statement approved by the system owner and security.

2) Choose the automation mechanisms (the “automation support”)

Map each baseline category to an automated mechanism that can produce or validate configuration:

• IaC: baseline equals declared state; automation can render and version the desired state.
• Cloud security posture / config assessment tools: baseline equals policy-as-code rules and expected settings; automation evaluates actual settings continuously.
• Endpoint/MDM: baseline equals policy profiles; automation reports compliance and exceptions.
• CI/CD controls: baseline equals pipeline configuration + protected branch rules; automation enforces and audits changes.

You do not need a single tool for everything, but you do need a single story: automation pulls from authoritative sources and produces repeatable outputs.

Deliverable: Automation-to-Baseline Mapping table (see template below).

Template: Automation-to-Baseline Mapping

Baseline area	Authoritative source	Automation mechanism	Output artifact	Owner
Cloud network controls	IaC repo + approved modules	CI pipeline + policy checks	Drift/scan report + pipeline logs	Platform Eng
Endpoint hardening	MDM profiles	MDM compliance reporting	Compliance report + exception list	IT Ops
Logging configuration	Central logging config	Config scanner + alerting	Misconfig alerts + weekly summary	SecOps

3) Implement automated capture + versioning of baseline artifacts

Your baseline must be reproducible and retrievable:

• Store baseline artifacts in a controlled repository (version history, access control).
• For IaC, keep tagged releases that represent approved baselines.
• For tool-driven baselines (MDM/CSPM), export snapshots on a schedule or after approvals and store them as records.

Deliverable: Baseline Register with version identifiers and retrieval instructions.

4) Implement automated drift detection and exception workflow

Drift detection is where “accuracy and currency” becomes testable:

• Define what counts as drift for each baseline area.
• Configure automated evaluations (continuous where feasible; scheduled where necessary).
• Route findings into a ticketing system with required fields: affected asset, expected vs actual, risk severity, disposition (authorized change, exception, remediation), and due date.

Deliverable: Drift ticket workflow + sample closed tickets showing each disposition type.

5) Link drift and baseline updates to formal change control

Auditors will test whether baseline updates are controlled, not ad hoc:

• Approved changes should update the baseline (IaC merge, policy update, new golden image, updated MDM profile).
• Unauthorized changes should be remediated or formally accepted as exceptions with expiration.
• Baseline updates should reference the change record ID.

Deliverable: A traceable chain: Change record → baseline version update → drift resolution evidence.

6) Prove availability: make the baseline easy to retrieve

“Availability” here is practical:

• Document where baselines live and who can access them.
• Ensure read access for auditors/assessors can be granted quickly without admin access.
• Keep baseline exports readable without proprietary tooling where possible (PDF/JSON exports, repo tags, signed artifacts).

Deliverable: Baseline retrieval runbook + access control evidence.

7) Assign ownership and recurring evidence production

CM-2(2) fails when nobody owns the recurring outputs.

• Assign a control owner and technical operators per baseline area.
• Define what evidence is produced automatically and what requires human review.
• Run a recurring review meeting or async attestation that drift is addressed.

Practical fit: In Daydream, map CM-2(2) to a named control owner, an implementation procedure, and a recurring evidence checklist so you can pass assessments without rebuilding the story each cycle. ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates automation exists, runs, and is acted on:

• Baseline Scope Statement ¹
• Automation-to-Baseline Mapping (tooling + outputs + owners)
• Baseline Register (versions, dates, approvals, locations)
• Automated run evidence: scan/job execution logs, pipeline logs, scheduled export logs
• Drift reports/findings: dated outputs showing expected vs actual
• Tickets/records showing triage and closure (remediation, approved change linkage, or exception)
• Change management records linked to baseline updates
• Access and availability proof: repo permissions, runbook, sample retrieval within normal operations

Retention tip: store artifacts by system and by period so you can answer “what was the baseline at time X?” without manual reconstruction.

Common exam/audit questions and hangups

Expect these questions and prep the exact artifact to answer them:

1. “Show me your baseline configuration.”
   Provide the Baseline Register entry and the current baseline artifact (repo tag/export).

2. “How do you know it’s accurate and current?”
   Provide recent automated drift reports plus associated tickets demonstrating disposition.

3. “What automation is used?”
   Provide the Automation-to-Baseline Mapping and a sample of job logs or pipeline runs.

4. “What happens when drift is detected?”
   Provide the workflow and closed examples: one authorized change, one remediated, one exception with expiry.

5. “Who reviews this and how often?”
   Provide ownership assignments and evidence of review/attestation (meeting notes or ticket audit trail).

Frequent implementation mistakes (and how to avoid them)

• Mistake: Baseline exists only as a static document.
  Fix: treat baseline as versioned artifacts produced from IaC/policy exports; require baseline updates through change control.

• Mistake: Automation runs, but nobody can show outputs.
  Fix: centralize outputs (reports/logs) and index them in your evidence repository by system and date.

• Mistake: Drift findings don’t link to disposition.
  Fix: require every drift item to map to a ticket and a final disposition with approver.

• Mistake: Baseline scope is vague (“all configs”).
  Fix: define baseline categories that align to your threat model and operational ownership. Document exclusions explicitly.

• Mistake: Availability is ignored.
  Fix: add a retrieval runbook and test retrieval as part of readiness reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CM-2(2) primarily as an assessment and authorization risk: inability to demonstrate accurate, current baselines commonly leads to audit findings, loss of confidence in change control, and expanded sampling by assessors. ¹

Operationally, weak baseline control increases the chance that misconfigurations persist unnoticed and that incident responders cannot quickly determine “what changed” or “what should be true.”

Practical 30/60/90-day execution plan

First 30 days (establish control shape)

• Name the CM-2(2) control owner and technical operators per baseline area.
• Produce Baseline Scope Statement for the highest-risk system(s).
• Inventory where baseline truth currently exists (repos, tools, policies).
• Stand up the Automation-to-Baseline Mapping and identify gaps where automation is missing.

By 60 days (make automation outputs auditable)

• Implement or formalize automated drift detection per baseline area.
• Centralize outputs (reports/logs) and establish naming conventions.
• Build the ticket workflow for drift disposition and train operators on required fields.
• Start a baseline register with versioning and approvals tied to change records.

By 90 days (prove it runs and stays current)

• Demonstrate at least one full lifecycle per baseline area: drift detected → triage → authorized change linkage or remediation → baseline updated.
• Add a recurring review cadence and an evidence checklist (Daydream can host the mapping between requirement, procedure, owner, and recurring artifacts so it stays current across cycles). ¹
• Run an internal mini-assessment: sample baseline retrieval, sample drift evidence, and traceability to change control.

Frequently Asked Questions

Does CM-2(2) require a specific tool (like a CMDB or CSPM)?

No. It requires automation support that maintains baseline currency, completeness, accuracy, and availability. Your tooling can be IaC, endpoint management, cloud configuration assessment, or a combination, as long as it produces reliable outputs you can evidence. ¹

What counts as the “baseline configuration” for a cloud-native system?

Define baseline categories that match your boundary: IAM, network controls, logging, encryption, compute/container settings, and security agent configuration are common inclusions. The key is that the baseline is versioned and tied to authorized change, not an informal set of “defaults.”

How do we show “accuracy” to an auditor?

Show automated observed-state outputs (scan results, compliance reports) and a comparison to expected settings, plus tickets proving exceptions were resolved or approved. Accuracy is demonstrated by repeatable measurement and reconciliation, not by a one-time review. ¹

If we use IaC everywhere, is CM-2(2) automatically satisfied?

Not automatically. IaC helps, but you still need evidence of drift detection (including for out-of-band changes), versioned baselines, and traceability between approvals and baseline updates.

How do we handle third-party managed platforms where we can’t see all settings?

Scope the baseline to what you can control and observe, document constraints, and automate what you can (contracted configuration exports, provider APIs, or monitoring alerts). Keep exceptions explicit and time-bounded so assessors see governance rather than gaps.

What evidence is “minimum viable” for an assessment?

A current baseline artifact, automated run outputs showing observed state, a drift report with linked tickets, and at least one example where a change record updates the baseline. Missing recurring evidence is a common failure mode. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5