CM-2(1): Reviews and Updates

The cm-2(1): reviews and updates requirement is one of those controls that looks “documentation-heavy” but is really about operational discipline: can you prove your baseline configuration stays accurate over time, across assets, and through change? If you cannot, every downstream control that assumes a known-good baseline (hardening, vulnerability remediation, access controls, monitoring) becomes harder to defend.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn CM-2(1) into a simple runbook with (1) a baseline definition per system boundary, (2) a repeatable review mechanism, and (3) a tight evidence bundle that a third party can validate without interviews. Your goal is not to create more paperwork. Your goal is to make “baseline review and update” a normal outcome of change management, engineering operations, and security governance.

This page gives requirement-level implementation guidance you can assign to an owner and audit within a quarter, with concrete steps, artifacts to retain, and the exam questions that typically expose gaps.

Regulatory text

Excerpt: “NIST SP 800-53 control CM-2.1.” ¹

Operator meaning: CM-2(1) is the enhancement to CM-2 (Baseline Configuration) that expects you to periodically review the baseline configuration and update it when conditions change. You should be able to show (a) a defined baseline, (b) documented reviews, and (c) controlled updates with approvals and traceability to the events that prompted the change. ²

Plain-English interpretation

• You maintain a “source of truth” for how the system is supposed to be configured (the baseline).
• You revisit that baseline on a defined schedule and also when meaningful changes happen.
• You update the baseline in a controlled way, so the baseline reflects reality and approved intent, not tribal knowledge.

Who it applies to (entity and operational context)

This control most directly applies to:

• Federal information systems and the programs that operate them. ³
• Contractor systems handling federal data, including cloud-hosted environments, shared services, and supporting corporate systems that fall inside the authorization boundary or are otherwise required by contract. ³

Operationally, CM-2(1) lands on teams that manage configuration state:

• Infrastructure and cloud platform teams (IaC, account/subscription governance, network/security tooling)
• Endpoint/server teams (gold images, MDM, standard builds)
• Application/platform engineering (deployment configurations, baseline dependencies)
• Security operations and GRC (control ownership, exception handling, evidence and reporting)

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

Use the steps below as an implementation checklist. Keep the scope tight: one system boundary at a time.

Step 1: Assign ownership and define the “baseline object”

Deliverable: a one-page control card/runbook for CM-2(1).
Include:

• Control owner (accountable), implementers (responsible), approver (security/architecture/change authority)
• Systems in scope (system boundary names) and where baseline artifacts live
• Review cadence and review triggers (events that force an out-of-cycle review)
• Exception process (how deviations are approved and time-bounded)

This addresses a common audit failure: teams can’t explain who runs the control or how often it runs. ¹

Step 2: Define what “baseline configuration” means for your system

Your baseline should be concrete enough that engineers can compare reality to intent. Common baseline elements:

• Asset inventory scope for the system boundary (hosts, containers, cloud resources, endpoints)
• Approved OS/container base images and hardening standards
• Required security agents and logging configuration
• Network patterns (segmentation, inbound/outbound controls, required ports)
• Identity configuration assumptions (SSO, MFA, service accounts, key management)
• “Must-have” configuration settings (time sync, encryption defaults, monitoring hooks)

Practical rule: if the baseline can’t be tested or checked, it’s too vague.

Step 3: Establish review triggers (don’t rely on calendar-only reviews)

Define triggers that force a baseline review and possible update. Examples:

• Material architecture change (new VPC/VNet, new cluster pattern, new identity provider integration)
• New or changed third party service integrated into the boundary
• Major version change to OS, database, Kubernetes, CI/CD platform, or security tooling
• Post-incident or post-audit findings that indicate baseline drift
• Significant policy changes (logging requirements, encryption standards)

Tie triggers to existing governance signals: CAB tickets, architecture review boards, security exceptions, incident postmortems, or procurement intake for third parties.

Step 4: Run the baseline review (repeatable agenda)

Each review should answer four questions:

1. What is the current approved baseline?
2. What changed in the environment since the last review (changes, incidents, new services)?
3. Does the baseline still reflect required security and operational expectations?
4. Do we need to update the baseline, or create/time-bound exceptions?

Mechanics that work in practice

• Pull change records and cloud change summaries for the period.
• Compare “baseline as documented” vs “baseline as deployed” using available configuration reports (cloud config rules, endpoint compliance, IaC diffs, image pipelines).
• Log deviations as either (a) remediation tasks to return to baseline, or (b) proposed baseline updates with rationale.

Step 5: Approve updates and publish the new baseline

Treat baseline updates like controlled changes:

• Document the change request (what changes, why, impact, backout considerations)
• Obtain the right approval (security architecture, system owner, CAB, or defined authority)
• Update the baseline artifact(s) and link them to the approval record
• Communicate changes to affected operators (runbooks, build pipelines, platform templates)

Step 6: Prove ongoing operation (control health checks)

Auditors and customer diligence teams look for sustained operation, not a single review memo. Run recurring health checks that confirm:

• Reviews occurred as scheduled or per triggers
• Identified actions were tracked to closure
• Exceptions have owners and expiration criteria

Daydream can help by turning CM-2(1) into a living control card, collecting the minimum evidence bundle per cycle, and tracking remediation items to validated closure so you can answer diligence requests without rebuilding the story each time. ¹

Required evidence and artifacts to retain

Build an “evidence bundle” that stands alone. Minimum recommended artifacts:

• CM-2(1) control card/runbook (owner, scope, cadence, triggers, exception rules)
• Baseline configuration artifact(s) (documents, IaC repos, gold image definitions, configuration profiles)
• Review records: meeting notes or sign-off memo, agenda, attendees, date, scope reviewed
• Inputs to the review: change ticket list, architecture decisions, incident learnings, configuration drift reports
• Outputs:
  • List of deviations and remediation tickets with owners and status
  • Approved baseline update requests and approvals
  • Updated baseline version and publication location
• Exception register entries for accepted deviations, including rationale, approver, and expiration/reevaluation trigger

Retention location: store artifacts in a system that preserves timestamps and access controls (GRC tool, ticketing system, controlled repository), and make sure links are stable.

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your evidence:

• “Show me the baseline for System X and who approved it.”
• “Show me the last review. What inputs did you consider?”
• “What events trigger an out-of-cycle update?”
• “How do you detect drift from baseline?”
• “Show examples where a change caused a baseline update.”
• “How do you manage exceptions, and how do they expire?”

Hangups that cause findings:

• Baseline exists, but no proof it’s reviewed.
• Reviews happen, but outputs don’t change anything (no tickets, no approvals, no updates).
• Updates happen, but you can’t tie them to a controlled approval path.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Baseline stored in a static doc with no versioning	You can’t show what changed and when	Put baselines in version-controlled repos or a controlled document system; require approvals
Calendar-only reviews	Reviews miss real-world changes	Add trigger-based reviews tied to change management and architecture governance
“Baseline” is a narrative	You can’t test it or measure drift	Define baseline as testable settings, templates, images, and policies
No exception discipline	Drift becomes permanent	Maintain an exception register with owner, rationale, and reevaluation conditions
Evidence scattered across tools	You lose time in audits	Define a minimum evidence bundle and a single evidence location per system

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-2(1).

Risk-wise, CM-2(1) failures usually surface as audit findings and customer due diligence failures, because reviewers cannot confirm that your stated security posture matches current operations. The operational impact is real: outdated baselines drive inconsistent hardening, gaps in logging coverage, and uncontrolled configuration drift across cloud and endpoint fleets. ³

A practical 30/60/90-day execution plan

Use this as an execution sequence you can assign and track. Adjust scope by system criticality and boundary size.

First 30 days (foundation)

• Name an accountable owner per system boundary and define approvers.
• Draft the CM-2(1) control card: cadence, triggers, evidence bundle, exception rules.
• Inventory where baseline artifacts already exist (IaC repos, image pipelines, MDM profiles, cloud org standards).
• Choose the evidence “home” (GRC record, controlled folder, or Daydream workspace) and standardize naming.

Days 31–60 (first operating cycle)

• Normalize the baseline: convert narrative docs into versioned artifacts where possible (templates, config profiles, standards with specific settings).
• Define trigger hooks: which tickets, incident types, and architecture decisions require review.
• Run the first baseline review using the repeatable agenda; record inputs and decisions.
• Open remediation items and baseline update requests; route them through approvals.

Days 61–90 (prove sustainment)

• Publish updated baseline versions and communicate changes to engineering operators.
• Close or replan remediation items with documented rationale and due dates.
• Run a control health check: confirm evidence completeness and that exceptions are tracked.
• Prepare an “audit-ready packet” per system boundary so you can respond quickly to assessors and customers.

Frequently Asked Questions

What counts as a “review” for CM-2(1)?

A review is a documented activity where you evaluate whether the approved baseline is still correct, given changes and operating reality. Your evidence should show inputs reviewed, decisions made, and whether the baseline was updated or exceptions were recorded.

Do we need to update the baseline every time we patch?

No. You need defined triggers and a cadence that keep the baseline current. Treat routine patching as an input to the review process; update the baseline when patching changes the approved standard build, hardening settings, or supported versions.

We use Infrastructure as Code. Is that our baseline?

IaC can be a strong baseline artifact if it represents the approved intended configuration and is controlled through reviews and approvals. You still need CM-2(1) review records that show you assessed changes and updated the baseline when needed.

How do we handle deviations from baseline that are “known and accepted”?

Track them as exceptions with a named owner, rationale, and reevaluation condition. If the deviation becomes permanent and broadly acceptable, fold it back into the baseline through a controlled update.

What evidence is most persuasive to auditors?

A tight evidence bundle: baseline version, review record, inputs (change/incident summaries), outputs (tickets and approvals), and the updated baseline location. Auditors prefer artifacts that stand alone without interviews.

How can Daydream help operationalize CM-2(1)?

Daydream can structure CM-2(1) as an owned control with defined triggers, collect the minimum evidence bundle per cycle, and track remediation and exception items through validated closure so you can respond to audits and diligence with less scramble.

Footnotes

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

2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5