Baseline Configuration

The baseline configuration requirement means you must define the approved, current “known-good” build of your FedRAMP system (images, OS settings, packages, cloud resources, and security tooling), document it, and keep it under formal configuration control so changes are reviewed, approved, tracked, and recoverable. Auditors expect you to prove the baseline exists, matches production, and is kept current.

Key takeaways:

• A baseline is an auditable snapshot of what “approved” looks like for your system, not a set of informal build notes.
• “Under configuration control” means changes follow a governed workflow with approvals, versioning, and traceability.
• Your evidence must connect baseline definitions to real deployed state (IaC, image IDs, config exports, CMDB) and to change records.

For FedRAMP Moderate operators, “Baseline Configuration” is one of the controls that separates a repeatable, governable system from an environment that drifts over time. If you cannot name your approved baseline, you cannot reliably detect unauthorized change, rebuild cleanly after an incident, or demonstrate that security settings stayed intact across releases.

The operational goal is simple: establish a current, authoritative baseline for the system and keep it current through controlled change. The compliance goal is just as direct: show an assessor that (1) the baseline exists, (2) it is documented at the right level of detail for your architecture, (3) it is versioned and approved, and (4) the deployed environment can be shown to match (or deviations are known and approved).

This page translates the CM-2 requirement into implementable steps for a Compliance Officer, CCO, or GRC lead partnering with engineering, platform, and security teams. You’ll leave with a practical definition of “baseline,” what artifacts to request, how to set up configuration control, and what auditors commonly challenge.

Regulatory text

Requirement (excerpt): “Develop, document, and maintain under configuration control a current baseline configuration of the system.” ¹

Operator meaning:

• Develop: Decide what components and settings must be part of the baseline (system boundary, cloud resources, OS images, hardening settings, security agents, network rules, logging configuration, identity configuration).
• Document: Capture the baseline in an accessible, reviewable form that someone other than the builder can understand and validate.
• Maintain: Keep the baseline current as the system changes; retire old baselines and preserve historical versions.
• Under configuration control: Put the baseline itself and any changes to it behind a governed mechanism (version control, approvals, change tickets, and traceability from request → review → implementation → validation).

Plain-English interpretation (what CM-2 demands)

You need a “source of truth” that states: “This is what we run, and this is what we approve.” Then you need proof that changes to that source of truth are controlled and that production aligns to it.

In practice, a baseline configuration usually includes:

• Infrastructure baseline: accounts/subscriptions/projects, VPC/VNet design, subnets, routing, security groups, firewalls, load balancers, key management configuration.
• Compute baseline: approved VM images/AMIs, container base images, Kubernetes node/cluster configuration, autoscaling settings.
• OS and middleware baseline: CIS-aligned hardening choices (where applicable), installed packages, services enabled/disabled, time sync, crypto libraries, web server settings.
• Security tooling baseline: EDR/agent configuration, vulnerability scanner deployment approach, SIEM/log forwarding configuration, configuration scanning rules.
• Identity baseline: SSO/IAM patterns, privileged access model, MFA enforcement points, break-glass accounts, service account patterns.
• Application platform baseline (as scoped): runtime versions, required sidecars, secrets management approach, baseline configuration flags.

The baseline does not need to list every ephemeral instance. It must define the approved templates and configuration standards that produce those instances.

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating or authorizing systems under FedRAMP Moderate expectations for control CM-2. ¹

Operational context where this becomes real:

• Cloud-first environments with frequent releases, autoscaling, and managed services.
• IaC-driven deployments where Terraform/CloudFormation/Bicep/Ansible can act as the baseline definition.
• Container/Kubernetes platforms where base images and cluster settings drift quickly without governance.
• Multi-account/multi-subscription architectures where “one baseline” must be expressed as a controlled standard across environments.

If you are the compliance lead, your job is to ensure the baseline definition is complete for the system boundary and that engineering can produce evidence tying that definition to reality.

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

1) Define the system boundary and baseline scope

Create a short scoping statement that answers:

• Which environments are in scope (prod, staging, DR)?
• Which cloud accounts/subscriptions/projects are in scope?
• Which platform layers are in scope (network, compute, identity, logging, security tools, CI/CD runners)?

Deliverable: Baseline scope statement owned by the system owner and accepted by security/compliance.

2) Choose the baseline “source of truth” format

Pick formats that can be versioned and reviewed:

• IaC repositories for infrastructure and policy-as-code.
• Golden image pipeline definitions (Packer config, image build scripts) plus the approved image IDs.
• Configuration profiles (MDM, GPO analogs where relevant, Kubernetes manifests, Helm charts).
• Written baseline standard for items that aren’t represented as code (for example, a mandated logging configuration for a managed service that is configured via console but exported as JSON).

Rule of thumb: if it can be code, make it code. If it can’t, make it an exported configuration plus a controlled standard.

3) Establish configuration control (the governance mechanism)

“Under configuration control” is where many programs fail. Put these minimums in place:

• Versioning: baseline artifacts live in a controlled repository with immutable history.
• Access control: limit who can change baseline definitions; enforce peer review.
• Change workflow: every baseline change has a change record (ticket), approval, implementation notes, and validation evidence.
• Release tagging: baseline versions are tagged to releases or dates so you can prove what the baseline was at a point in time.

Practical mapping: your change management process should explicitly include “baseline impact” as a required field (Yes/No) with reviewer sign-off.

4) Build the initial baseline and obtain formal approval

Create “Baseline v1” as a complete package:

• Inventory of baseline-controlled components (by type and identifier).
• Configuration standards (what settings must be true).
• References to the exact code commits, image IDs, and policy bundles that implement the baseline.

Then route it for approval (system owner, security, and platform owner). Keep that approval record.

5) Prove alignment between baseline and deployed state

Auditors will ask whether production matches the baseline. Prepare repeatable proofs:

• For IaC: show the repo, the approved commit/tag, and the deployed plan/applied state.
• For images: show image pipeline output, approved image IDs, and instance/container evidence that those images are in use.
• For managed services: export configuration (JSON/YAML/screenshots if needed) and show it matches the documented baseline.

This is where tooling helps. Many teams use continuous configuration monitoring to detect drift and generate evidence bundles. If you use Daydream, set it up to collect baseline definitions (code, policies, image inventories) and map them to change records and environment evidence, so the audit package is generated from the same workflow engineers already follow.

6) Keep it current: baseline maintenance rules

Define operational triggers that force baseline review:

• New service introduction in the boundary
• Major runtime upgrades
• Network architecture changes
• Identity model changes
• Security tooling changes

Also define how you handle exceptions: document deviations, approve them, and set an expiration or review point.

Required evidence and artifacts to retain

Keep evidence that shows definition, control, and currency:

Baseline definition artifacts

• Baseline configuration document (or equivalent) with version identifier
• Architecture diagrams and inventories that identify baseline-controlled elements
• IaC repositories and tagged baseline commits
• Golden image build definitions and approved image IDs
• Standard configuration profiles and policy bundles

Configuration control artifacts

• Change management procedure showing baseline changes are controlled
• Change tickets linking to baseline diffs/commits and approvals
• Access control records for baseline repos (who can approve/merge)
• Release notes that call out baseline-impacting changes

Validation artifacts

• Drift detection outputs or periodic configuration snapshots
• Deployment logs showing applied baseline commits
• Exports of key managed-service configurations
• Exception register for approved deviations and compensating controls

Common exam/audit questions and hangups

Assessors tend to probe the same gaps:

• “Show me your current baseline.” If you respond with a patchwork of wiki pages and tribal knowledge, expect a finding.
• “How do you know production matches it?” You need a reconciliation method, not a one-time screenshot.
• “What changed since the last assessment?” If you can’t name baseline versions over time, you’ll struggle to prove control.
• “Who approves baseline changes?” “Engineering did it” is not a governance answer; name roles and show approvals.
• “Do you have multiple baselines?” If prod and staging are materially different, explain why and show each baseline is controlled.

Frequent implementation mistakes (and how to avoid them)

1. Baseline equals “asset inventory.”
   An inventory lists what exists; a baseline defines what is approved. Keep both, but don’t confuse them.

2. No link between baseline and change management.
   Fix: add a required “baseline impact” check in change tickets and require a baseline version update when applicable.

3. Relying on console configuration without exports.
   Fix: export configurations or represent them as code; store exports under version control with change tickets.

4. Baseline created once and forgotten.
   Fix: define triggers for baseline review and make drift detection part of operations.

5. Over-scoping to the point nobody can maintain it.
   Fix: baseline the templates, images, and policies that produce the environment. Avoid enumerating every short-lived resource.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, CM-2 failures raise risk in three predictable ways:

• Security drift: hardening and logging controls degrade without visibility.
• Incident response friction: rebuilds take longer and root-cause analysis becomes speculative.
• Audit inability: you cannot prove a controlled environment, which creates assessment findings and remediation work.

Practical execution plan (30/60/90)

To follow the rules for this page, treat these as phases rather than calendar-day promises.

First phase: Immediate stabilization

• Confirm the system boundary and in-scope environments.
• Identify where baseline definitions already exist (IaC, image pipeline, cluster manifests).
• Stand up a single repository/folder structure for baseline artifacts and require version control.
• Add a baseline impact field to change tickets and define approvers.

Second phase: Near-term buildout

• Publish Baseline v1 with clear component coverage and references to code commits and image IDs.
• Implement a repeatable “prove it” method: export configs, record deployed versions, document reconciliation steps.
• Create an exceptions register and a simple workflow for approving deviations.

Third phase: Operationalization

• Add drift detection or periodic configuration snapshots tied to baseline versions.
• Train engineering and platform teams on what requires a baseline update.
• Run an internal mini-audit: pick a few baseline items (logging, IAM, network rules) and trace from baseline → change record → deployed evidence.

Frequently Asked Questions

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

The baseline is the approved templates and settings that define how the system is built and secured, plus identifiers that pin versions (for example, IaC tags and image IDs). It should be detailed enough that you can compare it to deployed state and detect drift.

Do we need separate baselines for prod and non-prod?

If the configurations are materially different, maintain separate baselines or a single baseline with documented, approved deltas. Auditors mainly care that each in-scope environment has an approved baseline and controlled change.

How do we prove the baseline is “current”?

Show that baseline artifacts are updated through your change process and that the latest baseline version matches what is deployed. Evidence usually includes recent approved change records, version tags, and exported configuration snapshots.

Is Infrastructure as Code sufficient as the baseline documentation?

Often yes, if it is readable, versioned, approved, and you can tie it to deployed state. Many teams still add a short baseline document that explains scope, ownership, and how to validate compliance against the IaC.

What should we do about one-off console changes already in production?

Either bring them under code (preferred) or export and document them as part of the baseline with a change record and approval. Then establish monitoring to prevent silent drift going forward.

Who should own CM-2, security or engineering?

Engineering typically owns the technical baseline artifacts, while security/GRC owns the governance requirements, evidence expectations, and audit readiness. Name both in your RACI so approvals and maintenance are unambiguous.

Footnotes

1. NIST Special Publication 800-53 Revision 5