CM-2(3): Retention of Previous Configurations

A rollback plan is only real if you have something concrete to roll back to. CM-2(3) focuses on retaining previous versions of baseline configurations so teams can restore a known-good state when a change breaks security controls, availability, or core functionality. This control enhancement sits inside the NIST SP 800-53 Configuration Management family, so assessors expect it to connect cleanly to your broader baseline configuration (CM-2) and change control practices.

For a CCO, Compliance Officer, or GRC lead, the fastest way to make CM-2(3) “exam-ready” is to define three things in writing and in tooling: (1) what counts as a baseline configuration for your environment, (2) how many previous baseline versions you retain (and for which system components), and (3) how you demonstrate rollback works under controlled access. Once those are set, the rest is execution discipline: consistent versioning, protected storage, and evidence that your team can actually perform a restoration during an incident or failed deployment.

Regulatory text

Requirement (verbatim): “Retain {{ insert: param, cm-02.03_odp }} of previous versions of baseline configurations of the system to support rollback.” ¹

Operator translation: you must define the organization-determined parameter (ODP) for how many previous baseline versions you retain, then implement retention in a way that supports timely rollback. The word “retain” implies durability and retrievability, not just “we could probably reconstruct it from old tickets.” ²

Plain-English interpretation

You need a reliable “undo” for configuration. Specifically:

• A baseline configuration exists (approved, documented, and used as the reference point).
• Prior baseline versions are preserved.
• Those prior versions can be restored to the system (or relevant components) to recover from a bad change.

This is narrower than “backups” and broader than “Git history.” Backups might capture data and disk images, but not necessarily an approved configuration baseline. Git might capture code, but not always the full set of configuration items that constitute your baseline (cloud resources, firewall rules, IAM policies, OS hardening settings, SaaS tenant settings).

Who it applies to

CM-2(3) applies in any environment implementing NIST SP 800-53, including:

• Federal information systems
• Contractor systems handling federal data ¹

Operationally, you should apply it wherever configuration drift or failed change deployment can materially impact confidentiality, integrity, or availability. Typical in-scope components:

• OS and endpoint baselines (gold images, hardening profiles)
• Network/security devices (firewalls, routers, WAF policies)
• Cloud infrastructure (IaC templates, security groups, KMS/IAM policies)
• Container/Kubernetes baselines (cluster config, admission controls, network policies)
• Critical application and middleware configurations
• SaaS “baseline” admin configurations for high-impact tenants (SSO, MFA policies, logging, retention)

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

1) Define the ODP: “how many previous baseline versions”

CM-2(3) intentionally leaves the quantity as an organization decision (“ODP”). Your first operational decision is a retention rule that’s clear enough to test.

Create a short standard that answers:

• What is a baseline configuration for each major platform (OS, network, cloud, app)?
• What is a baseline version (monthly snapshot, release-based, change-window-based)?
• How many previous baseline versions are retained per system/component?
• What events trigger a new baseline (major release, security hardening change, architecture change)?

Write the rule so an engineer can follow it without interpretation.

2) Establish “system of record” storage for baselines

Pick storage that supports immutability, access control, and audit logging. Common patterns:

• Infrastructure-as-Code repo as the baseline record for cloud resources.
• Configuration management tooling exports (or desired-state definitions) for servers.
• Device configuration archives for network gear.
• Golden image registry for VM images or container base images.

Minimum operational requirement: for each baseline version, you can retrieve the exact configuration package and identify who approved it.

3) Standardize versioning and naming

Make versions unambiguous:

• Assign a baseline ID (e.g., PROD-NETWORK-BASELINE-2026-02).
• Tag with approval reference (change ticket ID, CAB approval record).
• Record “effective date/time” and applicable scope (system, environment, segment).

Auditors commonly fail teams here because artifacts exist but cannot be tied to a specific baseline version.

4) Lock down who can change, delete, and restore baselines

CM-2(3) is about rollback support, so protect baselines from accidental deletion or tampering:

• Restrict write access to baseline repositories.
• Separate duties: the person who deploys changes should not be the only person who can alter the baseline record.
• Log administrative access.

If you rely on a third party (managed service provider, cloud managed services), document their responsibilities and your verification checks as part of third-party oversight.

5) Build a practical rollback procedure

Document the exact restoration steps for each baseline type:

• Preconditions (maintenance window requirements, approvals, incident criteria).
• Execution steps (commands, runbooks, pipelines).
• Validation checks (security controls enabled, services healthy, logging intact).
• Post-rollback actions (root cause, corrective change, new baseline creation).

A rollback procedure that requires heroic effort is a weak control in practice. Keep it executable under stress.

6) Test rollback capability and capture evidence

CM-2(3) says “to support rollback.” Support implies you can do it, not just store files. Run periodic restoration tests (in lower environments where possible) and keep results:

• Test plan and scenario
• Baseline version restored
• Evidence of success (system state, config diff, monitoring screenshots/logs)
• Issues found and remediation actions

7) Map to control ownership and recurring evidence

Assign a single accountable owner (often Platform Engineering, IT Ops, or Security Engineering) and define the evidence cadence. A lightweight way to stay audit-ready is a monthly or release-based evidence bundle that shows: current baseline, retained prior baselines, and at least one restoration test record. This aligns with common best practice expectations for assessability ¹.

Required evidence and artifacts to retain

Use this checklist to build your CM-2(3) evidence folder:

Policy/standard (design evidence)

• Baseline configuration standard defining the ODP (how many previous versions)
• Baseline identification scheme and scope rules
• Access control standard for baseline repositories

Operational artifacts (run evidence)

• Inventory of systems/components with baseline location and owner
• Baseline version history (showing current and retained previous versions)
• Approval records for baseline changes (tickets, CAB minutes, e-approvals)
• Rollback runbooks / SOPs per platform
• Rollback test records (plan, execution logs, outcomes, remediation)

Technical proof (implementation evidence)

• Repo screenshots or exports showing tags/releases for baseline versions
• Storage configuration showing retention settings and restricted permissions
• Audit logs for baseline changes (who/what/when)

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me your current baseline and the previous versions you retained.” Have a single list per system, with links to artifacts.
2. “How did you decide how many versions to keep?” Point to your ODP rationale (risk-based, release frequency, recovery objectives).
3. “Demonstrate rollback.” Provide a completed test record or a controlled demonstration in a non-production environment.
4. “What prevents tampering or deletion?” Show permissions, immutability controls, and audit logs.
5. “Does this cover cloud and SaaS configuration too?” If those platforms are in scope, you need a baseline method for them, not only server configs.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating backups as baseline retention	Backups may not represent an approved baseline or be quickly restorable to a known-good config	Define baseline artifacts explicitly (IaC, golden images, device configs) and link them to approvals
No defined ODP	Assessors cannot verify compliance if “retain previous versions” is vague	Publish an internal standard stating the retention count/logic per system class 1
Baselines exist but aren’t protected	A malicious or accidental change can erase rollback capability	Enforce restricted write/delete permissions, immutable storage where feasible, and logging
“Rollback procedure” is tribal knowledge	Key staff absence turns rollback into downtime	Convert it into runbooks, train on it, and keep evidence
Version sprawl without traceability	You can’t prove which baseline was in effect on a date	Use consistent version IDs, tags, and approval references

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so you should treat CM-2(3) primarily as an assessment and authorization readiness issue under NIST-based programs rather than a control with a specific published penalty history in the provided data.

Operational risk is straightforward:

• Failed changes become outages when rollback is slow or impossible.
• Misconfigurations persist longer when teams cannot restore a known-good secure state.
• Investigations stall when you cannot reconstruct configuration history.

Practical 30/60/90-day execution plan

First 30 days (Immediate: make it decidable and auditable)

• Name the CM-2(3) control owner and backups (Ops + Security).
• Define your baseline scope by platform and environment (prod first).
• Write the ODP rule: how many prior baseline versions you retain per platform class.
• Identify the system-of-record locations for baseline artifacts; document gaps.

Next 60 days (Near-term: make it real in tooling)

• Implement versioning/tagging conventions in repos and config archives.
• Set access controls: limit who can modify/delete baselines; enable logging.
• Publish rollback runbooks for top critical systems (those with highest operational impact).
• Run a rollback tabletop plus at least one hands-on restoration test; store evidence.

By 90 days (Ongoing motion: prove sustained operation)

• Expand coverage across remaining in-scope systems.
• Add a recurring evidence routine: baseline inventory export, version history, and a periodic rollback test record.
• Integrate checks into change management: every baseline change produces a retained previous version and an approval record.
• If third parties manage key components, add contract/SOW language and a verification step for baseline retention and rollback support.

Where Daydream fits naturally: teams often meet CM-2(3) technically but fail on repeatable evidence. Daydream helps you map CM-2(3) to a clear owner, a documented procedure, and a recurring evidence bundle that stays consistent across systems and assessors ¹.

Frequently Asked Questions

What counts as a “baseline configuration” for CM-2(3)?

A baseline is an approved, documented configuration state used as the reference point for change control. Treat it as a restorable snapshot of configuration items for the system or component, not an informal “current settings” description.

Do we need to retain previous versions for every system, or only production?

Start with production and other high-impact environments, then expand based on your system boundary and risk. If a non-production environment supports security testing or incident recovery, retaining baselines there can still matter for rollback and validation.

Can Git history satisfy CM-2(3)?

Git can satisfy part of the requirement if it contains the baseline configuration artifacts and you manage releases/tags as “baseline versions.” You still need access controls, clear baseline identifiers, and a rollback procedure that restores from those versions.

How do we prove “support rollback” to an auditor?

Provide a rollback runbook plus at least one completed restoration test record that shows the baseline version restored and validation results. Auditors typically want evidence you can execute, not just retain files.

What if a third party manages our infrastructure configurations?

Document the third party’s responsibilities for baseline retention and restoration, then verify it with evidence (exports, logs, change records, or test results). Keep your own copy or assured access to prior baselines so rollback is not blocked by the third party.

Does CM-2(3) require immutable storage?

The requirement text does not mandate immutability, but you must protect retained baselines from alteration or deletion that would undermine rollback. If you cannot make storage immutable, compensate with tight permissions, logging, and monitoring of baseline repositories.

Footnotes

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

2. NIST SP 800-53 Rev. 5