Configuration Baselines

You meet the configuration baselines requirement by defining an approved, secure “known-good” configuration for your IT and OT assets, applying it consistently, and keeping it current as systems and risks change. Operationally, that means documented standards, controlled build images/templates, tracked deviations with approvals, and evidence that baseline drift is detected and corrected. (Cybersecurity Capability Maturity Model v2.1)

Key takeaways:

• A baseline is a specific, approved configuration state for each asset class, not a generic “hardening guideline.”
• The exam-ready proof is change control plus drift detection: show what the baseline is, where it’s applied, and how exceptions are governed.
• OT needs separate treatment: safety, availability, and vendor constraints change how you baseline, patch, and validate.

“Configuration Baselines” is a deceptively short requirement with a large operational footprint: you must know what “secure” looks like for the systems you run, and you must be able to prove your environment matches that intent on an ongoing basis. In C2M2 terms, the requirement is explicit that this covers both IT and OT assets, so a baseline program that stops at servers and laptops will fail the expectation. (Cybersecurity Capability Maturity Model v2.1)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this is to treat baselines as governed standards tied to asset inventory and change management. You need (1) a baseline per major platform or “asset class,” (2) a controlled way to deploy it (gold images, configuration profiles, templates), (3) a way to measure drift (configuration monitoring), and (4) a formal exception process for when operations cannot meet the baseline. Your goal is repeatability and auditability, not perfection on day one.

Regulatory text

Requirement (excerpt): “Configuration baselines for IT and OT assets are established and maintained.” (Cybersecurity Capability Maturity Model v2.1)

What the operator must do

• Establish means you create a defined, approved configuration baseline for relevant IT and OT asset types (for example: Windows servers, Linux servers, network devices, hypervisors, endpoints, PLC engineering workstations, historians). (Cybersecurity Capability Maturity Model v2.1)
• Maintain means you keep baselines current and effective as technology, threats, and operational constraints change, and you track/resolve deviations rather than letting the baseline become a “binder document.” (Cybersecurity Capability Maturity Model v2.1)

Plain-English interpretation

A configuration baseline is your organization’s “known-good build” for a given asset class: what services are enabled, how authentication works, what logging is required, what remote access is allowed, which management ports must be closed, and what security agents or controls must be present. You must be able to answer two questions with evidence:

1. What is the approved baseline for this system type?
2. How do you know systems match it (or have an approved exception)?

If you cannot measure drift, you cannot credibly claim you “maintain” baselines. If you cannot show governance (approval, versioning, and exception handling), you cannot credibly claim you “established” baselines.

Who it applies to

Entity types

• Energy sector organizations and critical infrastructure operators using the C2M2 framework. (Cybersecurity Capability Maturity Model v2.1)

Operational context (where auditors will focus)

• IT assets: endpoints, servers, identity systems, network/security appliances, cloud workloads, virtualization platforms.
• OT assets: control system servers and workstations (SCADA, DCS, EMS), engineering workstations, historians, jump hosts in industrial zones, industrial network infrastructure, and any supporting systems that directly affect OT operations. (Cybersecurity Capability Maturity Model v2.1)

Ownership model

This is not only an IT security task. Expect shared accountability across:

• Security/GRC for standard definition, governance, and evidence.
• IT Ops/Platform teams for gold images and configuration management.
• OT engineering/operations for OT-safe baselines, validation, and exception decisions.
• Change management for approvals and traceability.

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

1) Define asset classes and baseline scope

Start by grouping assets into manageable categories that share configuration patterns. A practical starting point:

• Windows workstation, Windows server, Linux server
• Network device class (router/switch), firewall, VPN/remote access
• Hypervisor/virtualization, cloud workload baseline (if applicable)
• OT: engineering workstation, OT jump host, historian, SCADA/DCS application server

Output: an “asset class → baseline document/template” mapping that ties back to your asset inventory.

2) Write baselines as enforceable configuration standards

Each baseline should be specific enough to test. Avoid vague statements like “harden systems.” Include:

• Account and authentication settings (local admin controls, MFA requirements where supported, password policies where relevant)
• Service/port posture (required services enabled, unnecessary services disabled, management interfaces restricted)
• Logging and time (time sync, log retention targets as internal requirements, security log sources enabled)
• Endpoint protections (EDR/AV presence where feasible, application control for high-risk OT workstations where feasible)
• Remote access rules (approved tools, jump host requirement, session logging expectations)
• Configuration of security tools (not just “install EDR,” but “EDR must be healthy and reporting”)
• OT-specific constraints (vendor support limits, safety/availability constraints, maintenance windows, validation requirements)

Governance: version each baseline, record approvers (security + operations/OT), and document the effective date.

3) Build “standard builds” that implement the baseline

Auditors will treat a Word document baseline as weak unless you can show deployment control. Use what fits your environment:

• Gold images for servers/workstations
• GPO/MDM profiles for endpoints
• Infrastructure-as-code templates for cloud/server builds
• Network configuration templates for devices
• OT build packages for engineering workstations and jump hosts (often more manual, but still controlled)

The operational goal: new systems come online compliant by default.

4) Measure and manage configuration drift

“Maintain” requires you to detect when systems fall out of baseline and to drive them back or document why not. Implement:

• Continuous or scheduled configuration assessment against baseline controls (IT commonly automated; OT may be scheduled and segmented).
• Drift tickets routed to the right operations queue with remediation steps.
• Documented handling for systems that cannot be remediated due to operational constraints.

In OT, define safe methods for scanning/assessment and get OT ops sign-off on cadence and tooling so you do not disrupt operations.

5) Create an exception process that auditors will accept

You will have exceptions. Make them controlled:

• Exception request must include asset identity, baseline item(s) not met, business/operational justification, risk statement, compensating controls, and expiration/next review trigger.
• Approvals should include the system owner and security; OT exceptions should include OT operations/engineering.
• Track exceptions in a register and tie them to assets.

6) Connect baselines to change management

Baselines fail when changes bypass control. Require that:

• Changes that alter baseline-relevant settings go through change control (standard/normal/emergency as your process allows).
• Approved changes update one of: the baseline (new version), the system configuration (remediate drift), or the exception register (approved deviation).

7) Review and update baselines based on real drivers

Define triggers that force a baseline review:

• Major OS/application version changes
• New remote access method
• Significant security event or control failure
• OT vendor guidance changes or supportability constraints

Keep the process simple: review, update version, communicate, enforce.

Required evidence and artifacts to retain

Auditors typically want proof in four buckets: definition, deployment, monitoring, and governance.

Baseline definition

• Baseline documents/standards per asset class with version history and approvals
• “Minimum configuration requirements” checklist that is testable

Deployment and enforcement

• Gold image build records or templates (GPO/MDM profiles, IaC repos, network templates)
• New build runbooks showing baseline steps
• Sample system configuration outputs showing baseline applied (screenshots/exports/config snippets)

Drift monitoring and remediation

• Configuration assessment reports or dashboards
• Drift tickets with timestamps, actions taken, and closure evidence
• Exception register tied to specific assets and baseline controls

Governance and change control

• Change records that show baseline-impacting changes were reviewed/approved
• Meeting minutes or approvals for baseline updates (where applicable)
• Ownership/RACI showing who maintains each baseline

Common exam/audit questions and hangups

1. “Show me the baseline for OT engineering workstations, and show me two devices that match it.”
   Hangup: OT baselines exist “in principle” but aren’t documented or tested.

2. “How do you know baselines are maintained?”
   Hangup: no drift detection, or drift detection exists but remediation is informal.

3. “How do you handle systems that can’t meet baseline?”
   Hangup: exceptions are ad hoc, with no expiry or compensating controls.

4. “Who approves baseline changes?”
   Hangup: security writes baselines without operational sign-off, especially in OT.

5. “How does this tie to asset inventory?”
   Hangup: baselines exist, but you can’t show which assets fall under which baseline.

Frequent implementation mistakes (and how to avoid them)

• Mistake: baselines are generic hardening guides.
  Fix: convert narrative guidance into testable settings with clear pass/fail.

• Mistake: IT-only program; OT is excluded due to complexity.
  Fix: start with OT “supporting” assets (jump hosts, engineering workstations, historians) where baselining is achievable without touching PLC logic.

• Mistake: no exception lifecycle.
  Fix: require expiration or a review trigger, and track exceptions against assets and specific controls.

• Mistake: baseline updates break operations.
  Fix: add validation steps and operational acceptance for OT and high-availability systems before rolling baseline changes broadly.

• Mistake: drift is detected but ignored.
  Fix: treat drift like vulnerability management: triage, ticket, remediate or accept risk with compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement. Practically, configuration baseline failures increase the likelihood of preventable incidents: exposed services, weak authentication paths, inconsistent logging, and unmanaged remote access. In OT, unmanaged configurations can also create operational safety and reliability risk if “quick fixes” accumulate without governance.

Practical execution plan (30/60/90)

Use these phases as an execution scaffold; adjust scope to your environment and operational constraints.

First 30 days (Immediate)

• Assign owners for IT baselines and OT baselines; document decision rights.
• Define asset classes and pick a small initial scope (one IT class, one OT-supporting class).
• Draft baseline standards for the selected scope; get security + operations approval.
• Stand up an exception intake workflow (even if manual) and a simple exception register.

Next 60 days (Near-term)

• Convert baselines into deployable controls (gold image/GPO/MDM/template) for the initial scope.
• Implement drift checking for the initial scope (tool-based or scripted exports reviewed on a set cadence).
• Start collecting evidence: sample compliant builds, drift reports, remediation tickets, and signed exceptions.

By 90 days (Operationalized)

• Expand to additional asset classes, prioritizing high-risk and high-volume systems.
• Integrate baseline checks with change management and provisioning workflows.
• Create baseline update triggers and publish a baseline versioning cadence that operations can follow.
• Prepare an audit packet: baseline documents, approvals, drift evidence, exceptions, and a mapping from baselines to asset inventory.

Where Daydream fits (practical use)

If you manage many third parties that support IT/OT environments (MSPs, OEMs, integrators, remote support providers), Daydream can centralize baseline-related due diligence evidence: require third parties to attest to and provide artifacts for their standard builds, remote access configurations, and exception handling, then map those submissions to your internal baseline controls for faster audits.

Frequently Asked Questions

What counts as a “configuration baseline” versus a security policy?

A baseline is specific and testable for a system type (settings, services, logging, access controls). A policy sets expectations; the baseline is the concrete build standard you can measure on real assets.

Do we need a unique baseline for every single asset?

No. Define baselines by asset class, then map each asset to the right class. Create exceptions only where a specific asset cannot meet the class baseline.

How do we handle OT systems where the vendor restricts configuration changes?

Document the vendor constraints, define an OT-safe baseline that includes what you can control (accounts, remote access paths, logging, network segmentation dependencies), and use exceptions with compensating controls for what you cannot change.

What evidence is strongest in an audit?

A signed, versioned baseline standard plus proof of enforcement: deployment templates/profiles, drift reports, remediation tickets, and an exception register tied to named assets.

How do we prove we “maintain” baselines over time?

Show drift detection and resolution, plus baseline version history with approvals and clear triggers for review (platform upgrades, incidents, remote access changes).

Can we meet the requirement if we only baseline new builds and not existing systems?

You can start that way operationally, but you still need a plan and evidence for bringing in-scope existing assets into alignment or documenting exceptions; otherwise you cannot credibly claim baselines are maintained across the environment.