Baseline Configuration | Retention of Previous Configurations

CM-2(3) is a practical control: if you cannot rapidly restore a prior baseline configuration, change becomes a reliability and security risk. The requirement is narrow but examiners will test it through operational reality. They will ask: “Show me the last baseline, the baseline before it, who approved both, and how you would roll back if today’s patch breaks production.”

This enhancement sits under baseline configuration management. Your “baseline configuration” should represent the approved, known-good configuration state for systems and components you operate (including cloud infrastructure, images, and critical security tooling). CM-2(3) adds a specific expectation: retain prior baseline versions, in a defined quantity, for rollback support. ¹

Operationalizing this quickly means you need three things: (1) a clear retention rule (what counts as a baseline version and how many are kept), (2) a technical mechanism that preserves prior versions with integrity and access control, and (3) runbooks and evidence that show you can roll back without improvising. If you already use infrastructure-as-code and Git, you’re close; the gap is usually definition, governance, and audit-ready traceability.

Regulatory text

Requirement (excerpt): “Retain organization-defined number of previous versions of baseline configurations of the system to support rollback.” ¹

What the operator must do:

• Decide and document the number of prior baseline versions you keep (the control leaves the number to you).
• Keep those prior versions in a way that supports rollback, meaning you can retrieve a specific prior baseline and restore it to the target system with controlled steps.
• Treat the retained baselines as controlled configuration items: protected from unauthorized change, linked to approvals, and available during an incident or failed change window. ¹

Plain-English interpretation

You need a “time machine” for approved configurations. Every time you update a baseline, you must preserve some number of older baselines so you can revert to a known-good configuration quickly. This is not the same as logging change tickets or keeping patch notes. Auditors want to see that the baseline artifacts themselves are retained and retrievable, not just described.

A usable interpretation that holds up in audits:

• A baseline is an approved configuration set for a system/component (OS build, hardened image, firewall policy, cloud landing zone config, endpoint policy set, etc.).
• A “previous version” is the exact prior approved baseline artifact, with its content intact (files, templates, parameter values, rulesets).
• “Support rollback” means you have a defined method to restore that previous baseline, and you can show it works in practice.

Who it applies to (entity and operational context)

Entity types: Cloud Service Providers and Federal Agencies implementing NIST SP 800-53 controls (including FedRAMP-authorized or aligned environments). ¹

Operational contexts where this becomes a real exam focus:

• Cloud infrastructure and platform services: VPC/VNet configurations, IAM policies, security groups, WAF policies, Kubernetes manifests, cluster baselines, and “golden” AMIs/images.
• Enterprise security tooling: EDR policy baselines, SIEM parsing rules and detection content, email security policies, PAM configurations.
• Network/security devices: Firewall rulebases, VPN configs, proxy policies.
• Endpoints and servers: Standard build baselines, CIS-aligned settings, configuration profiles.

If you depend on third parties (MSPs, managed SOC, SaaS admin consoles), you still own the requirement outcome. Your contracts and operating model should ensure you can obtain prior baseline versions and roll back without waiting on a human with tribal knowledge.

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

1) Define the retention rule (make it auditable)

Create a short, explicit standard that answers:

• What counts as a baseline configuration for each system class (cloud, network, endpoints, apps).
• The “organization-defined number” of prior baseline versions retained per baseline.
• How long you retain them, if your program also applies time-based retention (this control speaks to number of versions; time retention can be an internal extension).
• Where baselines live and who can approve changes.

Keep this in your configuration management policy/standard, and reference it in your SSP/control narrative where applicable.

2) Inventory baseline-controlled items

Build a list of “baseline objects” you will manage as versioned artifacts. Examples:

• Git repositories containing Terraform/CloudFormation and Kubernetes YAML.
• Image build pipelines and image IDs for approved “gold” images.
• Exported firewall rulebase files.
• JSON policy exports from SaaS admin consoles (where available).

A fast way to start is to take your current CM-2 baseline list and mark which entries already have versioning and which rely on screenshots, runbooks, or console state.

3) Implement a versioned, tamper-resistant repository

Pick a single pattern per artifact type:

Recommended patterns

• Infrastructure-as-code: Git with protected branches, pull request approvals, signed commits (where feasible), and tags/releases for approved baselines.
• Device configs: Automated exports to a repository with write restrictions; store “approved baseline” as a tagged release.
• SaaS policies: Scheduled exports (API-driven where possible) into version control or write-once storage, plus a documented restore method.

What auditors look for: immutable history, clear version identifiers, and access control that prevents quiet edits to “old baselines.”

4) Tie baseline versions to approvals and change records

For each baseline version you retain, you need traceability:

• Baseline version ID (tag/release name, image ID, config export hash).
• Approval evidence (CAB ticket, change request, PR approval trail).
• Implementation date and scope (which systems moved to that baseline).
• Rollback instructions and prerequisites.

This is where teams fall down: they have Git history but cannot show which commit was “the baseline” versus a work-in-progress. Use tags/releases and make “approved baseline” a formal state.

5) Make rollback executable, not aspirational

Write a rollback runbook per system class:

• Trigger conditions (failed deployment, availability issue, security regression).
• Steps to revert to baseline version N-1 (or another prior version).
• Validation steps post-rollback.
• Required access and separation of duties.

Then test it. You don’t need to run large-scale exercises for every system constantly, but you do need credible proof that rollback steps are correct and current.

6) Operationalize through automation and guardrails

Build guardrails that reduce human error:

• CI/CD pipelines that promote only tagged baseline releases to production.
• Policy checks that block drift from baselines (config compliance tools, desired state checks).
• Alerts when configuration changes occur outside approved workflows.

If you use Daydream to manage compliance evidence, treat baseline versions, approvals, and rollback tests as a standing evidence collection. Map each baseline object to its evidence sources (Git tag, ticket, pipeline run, export job logs) so you can answer audits without a manual “war room.”

Required evidence and artifacts to retain

Keep evidence that proves definition, retention, protection, and rollback support:

Core artifacts

• Baseline configuration standard stating the organization-defined number of prior versions retained. ¹
• Baseline inventory/list of configuration items under baseline control.
• Repository records showing retained prior baseline versions (tags/releases, immutable object versions, export archives).
• Access control records for baseline repositories (who can approve, who can write, who can read).
• Change/approval evidence linking each baseline version to authorization (change tickets, PR approvals).
• Rollback runbooks per system class.
• Rollback test evidence (ticket/work order, pipeline logs, validation screenshots or monitoring checks, after-action notes).

Quality indicators auditors like

• A “baseline release note” template that captures scope and rollback pointer.
• A simple index (“baseline register”) mapping baseline version IDs to dates and approvals.

Common exam/audit questions and hangups

Expect questions like:

• “What is your defined number of previous baseline versions retained, and where is that documented?” ¹
• “Show me the current baseline and prior baseline for this system. Who approved each?”
• “How do you prevent modification of prior baselines?”
• “Demonstrate rollback steps for a representative system.”
• “How do you handle baselines managed by a third party or in a SaaS console?”
• “How do you know production matches the approved baseline (drift detection)?”

Hangups:

• Teams confuse “backup” with “baseline version.” Backups help restore data; CM-2(3) is about configuration baselines that were approved and can be reinstated.
• “We keep history in Git” without identifying which commits are approved baselines.

Frequent implementation mistakes and how to avoid them

1. No organization-defined number.
   Fix: Put the number in your standard and apply it consistently. The control explicitly requires an organization-defined number. ¹

2. Baselines exist only as documents or screenshots.
   Fix: Store machine-restorable artifacts (code, exports, image IDs) and keep documents as supporting references.

3. Old baselines can be edited.
   Fix: Use protected tags/releases, object lock, and restricted write permissions. Treat baselines as records.

4. Rollback depends on a single engineer.
   Fix: Write runbooks, require peer review, and test restoration steps.

5. You retain versions but cannot map them to deployed state.
   Fix: Record “baseline deployed to environment X on date Y” and keep pipeline evidence.

Risk implications (why auditors care)

Without retained prior baselines, recovery becomes improvisation. A misconfiguration can create outages, weaken security controls (for example, opening network access or disabling logging), or slow incident containment. Retained baselines also support forensic confidence: you can show what “known good” looked like, and you can restore it quickly.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Write the baseline retention standard: define baseline types and the organization-defined number of previous versions retained. ¹
• Identify the highest-risk systems (production network controls, IAM, logging, key workloads) and list their baseline artifacts.
• Choose storage patterns (Git tags/releases for IaC; automated exports for devices/SaaS).
• Lock down repository permissions and approval workflow for baseline changes.

By 60 days (Near-term)

• Backfill retained prior baseline versions for top systems (capture and tag current baseline, and capture prior state where feasible).
• Publish rollback runbooks for each system class and run at least one tabletop or hands-on rollback validation for a representative system.
• Create a baseline register that maps baseline version IDs to approvals and deployment events.
• Start evidence collection in Daydream (or your GRC system) with links to tags, tickets, and pipeline logs.

By 90 days (Operationalized)

• Extend baseline retention and rollback patterns across remaining in-scope systems.
• Automate exports for console-managed configurations and verify restores.
• Add drift checks or configuration compliance monitoring tied to the baseline register.
• Run a periodic review cadence: verify retained versions remain accessible, approvals are complete, and rollback steps still match current architecture.

Frequently Asked Questions

What is a “baseline configuration version” in practice?

It’s an approved, identifiable configuration snapshot you can restore, such as a Git tag/release of IaC, an approved image ID, or an exported firewall policy file. It must be retained in a way that preserves its content and integrity. ¹

How many previous versions do we need to retain?

CM-2(3) requires an organization-defined number, so you must pick and document a number that supports rollback for your change volume and risk. Auditors will focus on whether the number is defined, consistently applied, and operationally sufficient for rollback. ¹

Do backups satisfy this requirement?

Not by themselves. Backups restore data and sometimes systems, but CM-2(3) is about retaining prior approved baseline configurations specifically so you can roll back configuration state. ¹

We manage a lot of config in SaaS consoles. How do we retain prior baselines?

Use vendor-supported export mechanisms or APIs to capture configuration snapshots on a schedule and on approved changes, then store them as versioned artifacts. Pair that with a documented restore method and evidence of retrieval. ¹

What evidence is most convincing in an audit?

A documented retention rule, a repository showing tagged prior baseline versions, approval records for each baseline, and a rollback runbook with a test record. Auditors want to see you can retrieve a prior baseline and follow a controlled rollback process. ¹

How does this interact with change management?

Treat “baseline update” as a specific change type that requires explicit approval and a baseline version identifier. Your change ticket should reference the baseline version promoted and the rollback baseline version retained. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5