Configuration Baselines

“Configuration baselines” is a requirement about operating your environment from a controlled standard state, not a documentation exercise. In C2M2, the objective is straightforward: establish and maintain configuration baselines for IT and OT assets so they run in a known, secure state (Cybersecurity Capability Maturity Model v2.1). For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this is to treat the baseline as a governed artifact with a lifecycle: create it, approve it, apply it, monitor for drift, and update it when the environment changes.

This requirement also forces a practical question: what is “the asset” in your program scope? In OT, baselines often include PLC logic versions, HMI configurations, historian settings, and engineering workstation controls. In IT, baselines are typically OS builds, endpoint hardening, server roles, cloud account guardrails, and network device configurations. Your job is to ensure (1) baselines exist for the scoped asset classes, (2) changes and exceptions do not silently invalidate them, and (3) you can show an assessor a clean chain of evidence from standard → change → updated standard (Cybersecurity Capability Maturity Model v2.1).

Regulatory text

C2M2 v2.1 ASSET-2.A (MIL1) excerpt: “Configuration baselines for IT and OT assets are established and maintained.” (Cybersecurity Capability Maturity Model v2.1)

Operator interpretation (what you must do):

• Established means you have defined, documented, and approved baseline configurations for in-scope IT and OT asset types (Cybersecurity Capability Maturity Model v2.1).
• Maintained means baselines stay current as systems are installed, changed, removed, or granted exceptions, and you can demonstrate that maintenance with records (Cybersecurity Capability Maturity Model v2.1).

Plain-English requirement summary

You need a written, approved “known-good configuration” for each important asset class in your IT and OT scope, and you must keep it accurate over time. If the environment drifts away from the baseline, you need a way to detect it, manage it (change or remediate), and update the baseline when the approved standard changes (Cybersecurity Capability Maturity Model v2.1).

Who it applies to

Entity scope

This applies to organizations using C2M2 to assess and improve cybersecurity capability, especially energy sector organizations and critical infrastructure operators (Cybersecurity Capability Maturity Model v2.1; DOE C2M2 program; DOE C2M2 Program (U.S. DOE CESER)).

Operational scope (what systems)

Apply it to the defined C2M2 assessment scope: a business unit, environment, or function that includes IT and/or OT assets (Cybersecurity Capability Maturity Model v2.1). In practice, you should prioritize:

• High-impact IT: identity systems, endpoint fleet standards, server tiers, virtualization platforms, network infrastructure, cloud landing zones.
• High-impact OT: control system networks, PLCs/RTUs, HMIs, historians, engineering workstations, jump hosts, remote access gateways, safety-adjacent systems.

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

Step 1: Define asset classes and baseline “units”

Create a short list of baseline categories that map to how your environment is built and managed. Good baseline units are “things an engineer can implement” and “things an auditor can test,” such as:

• Windows server build (by role)
• Linux server build (by distro/role)
• Network device baseline (by platform)
• Endpoint baseline (corporate, privileged, kiosk)
• OT engineering workstation baseline
• OT HMI baseline
• PLC/RTU configuration standard (versioning rules, secure settings)

Output: Baseline scope matrix (asset class → baseline owner → where stored → how tested).

Step 2: Specify baseline content that is testable

Each baseline should include enough detail that a reviewer can verify compliance. Minimum content that holds up in assessments:

• Configuration settings (hardening settings, services, protocols, logging, time sync)
• Allowed/required software and versions (including OT engineering tools)
• Account and access assumptions (local admin policy, service accounts, remote access)
• Security tooling expectations (EDR where feasible, logging agents, integrity monitoring)
• Build method (gold image, infrastructure-as-code, group policy, MDM profile)
• Deviations prohibited by default (what requires an exception)

Keep it structured (tables/controls), not narrative paragraphs.

Step 3: Approve the baselines with clear ownership

Baselines must be governed like standards:

• Assign an owner per baseline (IT infrastructure lead, OT operations lead, etc.).
• Define an approver (security, architecture, OT governance).
• Record effective date and version.
• Store in a controlled repository (GRC library, controlled wiki, or document management with change history).

Step 4: Bind baseline updates to change management

This is where programs usually break. You need an explicit rule: any approved change that alters the standard must trigger a baseline review and, if needed, a baseline version update (Cybersecurity Capability Maturity Model v2.1). Implement these mechanics:

• Change ticket template includes a “baseline impact” field: no impact / temporary deviation / permanent change to standard.
• If “permanent change,” require a linked task: “Update baseline artifact + approval.”
• For installs/removals, define how records stay current so the baseline does not become detached from reality (Cybersecurity Capability Maturity Model v2.1).

Step 5: Create an exceptions process that doesn’t destroy the baseline

You will have OT constraints, legacy platforms, and vendor-managed appliances. Handle them with controlled exceptions:

• Require business justification and risk acceptance.
• Set compensating controls (segmentation, monitoring, restricted access).
• Track expiration or review trigger (e.g., next maintenance window, end of support milestone).
• Ensure exceptions are searchable by asset and baseline category.

Step 6: Monitor for configuration drift and reconcile findings

“Maintained” implies you can detect misalignment. Choose a method appropriate to the environment:

• IT: configuration compliance tools, scripts, MDM/IdP policies, cloud policy-as-code checks.
• OT: read-only configuration checks where possible, controlled audits, vendor tools, and scheduled verification by OT engineering.

Tie drift results to remediation/change tickets. Keep reconciliation evidence showing the baseline remains accurate and is actively managed (Cybersecurity Capability Maturity Model v2.1).

Step 7: Run periodic baseline reviews (and prove you did)

Set a review cadence for each baseline category based on change rate and criticality. Document:

• reviewer,
• what changed,
• what stayed the same,
• approvals,
• links to supporting change records.

This is central to demonstrating “maintained” without debating semantics.

Required evidence and artifacts to retain

Assessors typically want proof of definition, governance, and operation. Retain:

• Baseline documents per asset class (versioned, dated, approved).
• Baseline scope matrix (what assets are covered, owners, repositories).
• Change management records showing baseline impact analysis and updates (Cybersecurity Capability Maturity Model v2.1).
• Exception register (approved deviations, compensating controls, approvals).
• Drift/compliance reports or check results, plus remediation tickets.
• Periodic review evidence (meeting minutes, review checklists, approval records) (Cybersecurity Capability Maturity Model v2.1).
• Reconciliations that demonstrate baseline and environment alignment over time (Cybersecurity Capability Maturity Model v2.1).

Practical tip: In Daydream, store the baseline artifact, the control owner, and the evidence links together so an auditor can traverse baseline → sample assets → drift results → change tickets without manual stitching.

Common exam/audit questions and hangups

Expect these:

• “Show me your baseline for OT engineering workstations and how you keep it current.”
• “How do you know production assets match the baseline? Show drift evidence.”
• “Walk me through a recent change that required a baseline update.”
• “How do you control exceptions, and who accepts the risk?”
• “Which assets are in scope, and which baselines map to them?”

Hangups that cause findings:

• Baseline exists, but no proof it is applied or tested.
• Baselines exist for IT but not for OT, even though OT is in scope.
• Exceptions are informal (“everyone knows that box is different”).
• Change management does not require baseline impact assessment.

Frequent implementation mistakes (and how to avoid them)

1. One baseline for everything.
   Fix: define baselines per asset class/role so they are implementable and testable.

2. Baselines stored as static PDFs with no lifecycle.
   Fix: require versioning, ownership, and an approval workflow.

3. No binding between change tickets and baseline updates.
   Fix: add baseline impact fields and a mandatory linked task for baseline updates (Cybersecurity Capability Maturity Model v2.1).

4. OT treated as “too hard” and skipped.
   Fix: start with what you can control: engineering workstations, jump hosts, remote access gateways, and segmented OT zones. Expand from there.

5. Drift detection without remediation governance.
   Fix: drift findings must generate tickets and close with evidence; otherwise drift reports become shelfware.

Enforcement context and risk implications

No public enforcement cases were provided for this C2M2 requirement in the supplied sources. Practically, configuration baseline weaknesses increase operational and compliance risk because systems drift from approved states and you cannot reliably assert what configurations are running during audits, customer diligence, or regulator review (Cybersecurity Capability Maturity Model v2.1). In OT environments, unmanaged drift can also translate into safety and availability impacts if changes bypass engineering controls.

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Confirm C2M2 assessment scope: which IT/OT environments and asset classes are in scope (Cybersecurity Capability Maturity Model v2.1).
• Build the baseline scope matrix with owners and repositories.
• Draft the first set of baselines for the highest-impact asset classes.
• Add “baseline impact” and “exception required” fields to change tickets.

Days 31–60 (make it operational)

• Route baselines through approval and publish controlled versions.
• Implement an exceptions register with approvals and compensating controls.
• Pilot drift checks on a small sample of IT assets and at least one OT baseline category.
• Train change managers and engineers on the baseline impact workflow.

Days 61–90 (prove it works)

• Expand drift monitoring to broader coverage for in-scope systems.
• Run the first periodic baseline review cycle; capture review evidence.
• Perform a reconciliation: baseline vs. actual for a set of representative assets, document gaps, and track remediation (Cybersecurity Capability Maturity Model v2.1).
• Package an “audit-ready” evidence set: baseline docs, approvals, exception samples, drift samples, and change records.

Frequently Asked Questions

Do we need a baseline for every single asset?

Define baselines by asset class and role, then map assets to those baselines. Auditors usually care that every in-scope asset is covered by an appropriate baseline, not that each device has a bespoke document.

What counts as “maintained” for a baseline?

You can show “maintained” by tying baseline updates to change management and retaining review/reconciliation evidence over time (Cybersecurity Capability Maturity Model v2.1). If changes happen without baseline updates or exceptions, the baseline is not maintained.

How do we handle vendor-managed OT systems where we can’t change settings?

Put them under an explicit exception with compensating controls (segmentation, monitored access paths, restricted remote access) and a review trigger. Keep the exception approval and the rationale with the baseline evidence set.

Can we meet this requirement with CIS benchmarks alone?

Benchmarks can inform your baseline, but you still need your own approved baseline artifact, scope mapping, exception handling, and evidence of ongoing maintenance for your environment (Cybersecurity Capability Maturity Model v2.1).

What evidence is most persuasive in an assessment?

A clean chain from baseline document → approval record → sampled assets mapped to the baseline → drift check results → remediation or approved exception → change ticket showing baseline impact and updates (Cybersecurity Capability Maturity Model v2.1).

Where should baselines live: GRC tool, ITSM, or engineering repository?

Put the authoritative baseline in a controlled repository with version history and approvals, then link it into ITSM change workflows and your GRC control record. Daydream works well as the system-of-record for the requirement, with pointers to engineering and ITSM evidence.