Baseline Configuration | Automation Support for Accuracy and Currency

To meet NIST SP 800-53 Rev 5 CM-2(2), you must keep your system baseline configuration current, complete, accurate, and available by using automated mechanisms you define and control. In practice, this means automated discovery, configuration capture, drift detection, and controlled updates to the baseline, backed by audit-ready evidence. ¹

Key takeaways:

• You need an automated way to keep the baseline accurate and up to date, not a static document updated by hand. ¹
• Auditors will look for continuous configuration inventory, drift evidence, and a repeatable workflow that updates the baseline through change control. ¹
• “Organization-defined automated mechanisms” means you must explicitly define the tools, scope, cadence triggers, and exceptions, then prove they operate as designed. ¹

Baseline configuration control breaks down in predictable ways: teams document a “gold build” once, infrastructure changes weekly, and the baseline becomes stale. CM-2(2) exists to prevent that failure mode by requiring automated mechanisms that maintain currency, completeness, accuracy, and availability of the baseline configuration. ¹

For FedRAMP and other NIST-aligned programs, treat the baseline as a living, system-scoped dataset: what is deployed, how it is configured, what versions are running, what security settings are enforced, and what “approved state” looks like for each asset type. Automation is the control, not a nice-to-have. You still need governance (who approves baseline changes, how exceptions work), but the day-to-day correctness comes from automated collection and comparison. ¹

This page tells a CCO, compliance officer, or GRC lead exactly how to operationalize the requirement: who owns what, what tools and workflows satisfy “automated mechanisms,” what evidence to retain, and what auditors commonly challenge.

Regulatory text

Requirement: “Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using organization-defined automated mechanisms.” ¹

Operator interpretation (what you must do):

• Currency: Your baseline must reflect the system as it is approved to run today, not last quarter. Automation should detect when reality diverges from the approved baseline and trigger action. ¹
• Completeness: The baseline must cover the full system scope you define (cloud accounts/projects/subscriptions, networks, compute, containers, endpoints, managed services, CI/CD, identity, and security tooling where in-scope). Automation should reduce blind spots created by manual inventories. ¹
• Accuracy: Captured configuration data must be correct and attributable (source of truth, timestamps, asset identity). Automation should pull directly from authoritative APIs/agents and reconcile duplicates. ¹
• Availability: Baseline records must be accessible to authorized staff and auditors, protected from tampering, and recoverable. Automation should publish baseline outputs to controlled repositories with retention and access control. ¹

Plain-English interpretation

You are required to run an automated, repeatable process that:

1. discovers what exists,
2. captures how it’s configured,
3. compares it to an approved baseline, and
4. keeps the approved baseline updated through your change control process.
   Manual spreadsheets can exist as supporting documentation, but they cannot be the main mechanism that keeps the baseline correct. ¹

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating systems under NIST 800-53 control baselines, including FedRAMP-authorized environments. ¹

Operational context where it bites hardest:

• Highly dynamic infrastructure (IaaS/PaaS), autoscaling, ephemeral workloads.
• Configuration managed through CI/CD, infrastructure as code (IaC), and managed services.
• Multi-account/multi-tenant environments where ownership is distributed across teams.
• Environments with frequent patching, image updates, or policy changes. ¹

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

1) Define what “baseline configuration” means for your system

Write a baseline definition that is specific enough to automate.

• Asset classes in scope: cloud accounts, VPC/VNet, security groups/firewalls, IAM roles/policies, OS images, container base images, Kubernetes config, databases, logging config, EDR agents, critical applications.
• Baseline attributes per asset class: version, critical settings, encryption flags, logging destinations, authentication requirements, approved ports, required agents, and tagging/ownership metadata.
• Source-of-truth hierarchy: IaC repo, golden images, MDM, cloud policy engine, CMDB.
  This becomes your “organization-defined” foundation. ¹

Deliverable: Baseline Configuration Standard (by asset class) + Baseline Scope Statement.

2) Select and document your automated mechanisms

The control does not require a specific tool category, but auditors will expect coverage and repeatability. Common patterns:

• Automated discovery/inventory: cloud asset inventory APIs, endpoint management inventory, Kubernetes inventory.
• Automated configuration capture: exporters/agents, cloud config snapshots, policy-as-code state dumps.
• Automated drift detection: comparison of actual vs approved (policy engine, config monitoring, IaC drift detection).
• Automated alerting + ticketing: create tickets for drift, route to owners, track closure.
• Automated baseline publishing: generate baseline reports and store them in controlled repositories. ¹

If you use Daydream for compliance operations, the cleanest approach is to map each baseline artifact to an owner, a system component, and an automated evidence feed so baseline updates and drift evidence stay current without manual screenshot collection.

Deliverable: “Automation Mechanisms Register” describing tools, what they collect, where outputs are stored, and who owns them.

3) Build the baseline lifecycle workflow (approved changes only)

Automation must support currency without turning every drift event into an ungoverned baseline update.

• Step A: Detect drift (automated).
• Step B: Triage (is it unauthorized drift, an emergency change, or an approved change not yet reflected?).
• Step C: Correct or approve:
  • If unauthorized, remediate back to baseline.
  • If legitimate change, run change control and update the baseline definition and/or templates.
• Step D: Reconcile: confirm drift is resolved or baseline is updated and republished.
• Step E: Record evidence: keep the before/after state and approval trail. ¹

Deliverable: Drift Handling SOP + Change control linkage (RFC templates include “baseline impact” field).

4) Make “complete and accurate” measurable

Define acceptance criteria you can show to an assessor:

• Completeness checks: every in-scope account/subscription reports inventory; every endpoint class reports; every cluster reports; missing feeds create an alert.
• Accuracy checks: timestamps, asset IDs, and config sources are consistent; duplicate assets are reconciled; exceptions are documented and time-bound.
• Availability checks: baseline outputs are stored in a controlled system with access control, backups, and retention. ¹

Deliverable: Baseline Quality Controls (checks, owners, and exception process).

5) Operationalize ownership and separation of duties

Assign named roles:

• Baseline Owner ¹: accountable for baseline definition and updates.
• Tool Owners: responsible for automation feeds and reliability.
• Service Owners: accountable for drift remediation in their components.
• GRC/Compliance: defines evidence requirements, samples operation, and tracks gaps. ¹

Deliverable: RACI for baseline maintenance and drift response.

Required evidence and artifacts to retain

Keep evidence that shows both design and operating effectiveness.

• Baseline definition artifacts: baseline standard, hardening standards, approved templates (IaC modules, golden images).
• System inventory outputs: automated asset inventory exports or dashboards with timestamps.
• Configuration snapshots: periodic system configuration exports and storage location details.
• Drift detection records: alerts, findings, diff reports, and associated tickets.
• Change control linkage: approved changes that modified baseline, with approvals and implementation records.
• Exception register: documented deviations, approvals, expiry dates, and compensating controls.
• Access and integrity controls: permissions to baseline repositories, audit logs, and retention settings. ¹

Common exam/audit questions and hangups

Auditors commonly press on these points:

• “Show me the baseline.” They want something concrete: templates, standards, and a published baseline package per environment. ¹
• “How do you know it is current?” Expect to show drift monitoring outputs plus a workflow showing baseline updates tied to approved change. ¹
• “What is automated vs manual?” Manual review can exist, but the maintenance mechanism must be automated and documented. ¹
• “Is your baseline complete?” They will sample assets and look for missing categories, orphan accounts, or unmanaged clusters.
• “Prove availability.” They will ask where baseline artifacts live, who can access them, and how you prevent tampering. ¹

Frequent implementation mistakes and how to avoid them

1. Treating a PDF as the baseline.
   Fix: make the baseline a set of machine-readable templates and exported configuration state, with a human-readable summary for auditors. ¹

2. Automation without governance (auto-updating baselines).
   Fix: drift detection can be automatic; baseline updates must flow through change control unless you have defined, approved “pre-authorized change” categories. ¹

3. Partial coverage (only servers, not cloud controls).
   Fix: baseline includes IAM, network rules, logging, encryption, and managed service configurations, not just OS settings. ¹

4. No evidence trail.
   Fix: store diffs, tickets, approvals, and republished baselines in systems with retention and access logging. Daydream can help by centralizing evidence mapping so each drift event and baseline update is traceable to the control requirement.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, CM-2(2) failures raise the likelihood of misconfigurations persisting unnoticed (exposed services, overly broad permissions, missing logging) and can drive audit findings, delayed authorizations, and increased monitoring scrutiny in NIST-aligned programs. ¹

Practical execution plan (30/60/90-day)

Because the requirement hinges on “organization-defined” automation, focus first on scope and evidence design, then expand coverage.

First 30 days (Immediate)

• Define in-scope system boundaries and asset classes for the baseline. ¹
• Publish baseline attributes for each asset class (what “approved” means).
• Inventory current automation: what tools already collect config/inventory, what is missing.
• Stand up a controlled baseline repository (access-controlled storage for baseline outputs and change records). ¹

Days 31–60 (Near-term)

• Implement automated inventory and configuration capture for highest-risk asset classes (IAM, network controls, logging, core compute). ¹
• Implement drift detection and alert routing to service owners.
• Tie drift tickets to change control, including baseline impact documentation.
• Define exception workflow with approval and expiry.

Days 61–90 (Operationalize)

• Expand automation coverage to remaining asset classes and edge cases (containers, clusters, managed databases, CI/CD config). ¹
• Add baseline quality checks (missing feeds, stale snapshots, orphan assets).
• Run an internal audit-style sample: pick assets, prove baseline, show drift history, show change approvals and baseline republishing. ¹
• Operational cadence: baseline review as part of release/change governance, with automated evidence collection centralized (Daydream-style evidence mapping reduces scramble during assessment).

Frequently Asked Questions

What counts as an “automated mechanism” for CM-2(2)?

Any defined tooling that automatically discovers assets, captures configuration state, and supports drift detection and baseline publishing can qualify. You must document what the automation does, what it covers, and how outputs are retained and protected. ¹

Can we satisfy this with IaC alone?

IaC is strong baseline definition, but you still need automated validation that deployed reality matches the approved templates and that out-of-band changes are detected. Assessors will expect evidence of drift monitoring, not just repo history. ¹

How do we handle emergency changes without breaking the requirement?

Allow emergency change paths in your change process, then require a follow-up step to either revert to baseline or update the baseline through documented approval. Retain the emergency approval and the baseline reconciliation evidence. ¹

What does “availability of the baseline configuration” mean in an audit?

Auditors look for baseline artifacts stored in an access-controlled system with retention and the ability to retrieve historical baselines and diffs. They may also test whether only authorized staff can modify the baseline records. ¹

Do we need one baseline per environment (dev/test/prod)?

You need baselines that reflect your approved configurations for each in-scope boundary. If environments have different approved settings, separate baselines reduce confusion and make drift results defensible. ¹

What evidence is most persuasive for CM-2(2)?

Time-stamped automated inventory outputs, drift reports with remediation tickets, and change records that show baseline updates were approved and republished. A clear linkage from tool output to stored evidence is often what decides the finding. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5