CM-6: Configuration Settings

CM-6: configuration settings requirement means you must define, document, and maintain secure baseline configuration settings for every system component, and those settings must default to the most restrictive mode that still supports mission and business needs (NIST SP 800-53 Rev. 5 OSCAL JSON). Operationalize CM-6 by standardizing baselines, enforcing them technically, managing exceptions, and retaining repeatable evidence.

Key takeaways:

• Build secure, component-specific baselines and justify any setting that is less restrictive than the baseline.
• Enforce settings through technical mechanisms (policy-as-code, MDM, GPO, configuration management), not wiki pages.
• Treat exceptions as time-bound risk decisions with approvals, compensating controls, and continuous monitoring evidence.

CM-6 is one of the controls auditors use to test whether your “security hardening” exists as an actual operating practice or only as aspirational policy. The requirement is narrow but unforgiving: configuration settings for the components in your system must be established and documented, and those settings must reflect the most restrictive mode consistent with operational requirements (NIST SP 800-53 Rev. 5 OSCAL JSON). That single sentence drives a lot of day-to-day mechanics: how you set baselines, where you store them, how you push and validate settings, how you handle exceptions, and how you prove the control is running.

For a Compliance Officer, CCO, or GRC lead, the fastest path to “audit-ready CM-6” is to treat configuration settings as governed records tied to asset inventory and change control. You want a small number of standard baselines (by platform and role), clear ownership, and automated measurement. Your job is to make the requirement testable: an assessor should be able to pick any in-scope component, pull the applicable baseline, see the enforced settings, and see exception approvals where reality differs.

Regulatory text

Requirement (quoted): “Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using {{ insert: param, cm-06_odp.01 }};” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator translation:
You must (1) decide what “secure” configuration means for each in-scope component, (2) document those settings in a baseline, and (3) run the system so that the actual configuration matches the baseline by default. Where operations require a less restrictive setting, you must document the operational need and control the risk through an approved exception and monitoring. CM-6 is assessed by evidence, not intent (NIST SP 800-53 Rev. 5).

Plain-English interpretation (what CM-6 is really testing)

CM-6 tests whether you can answer four questions for any component (server, endpoint, database, firewall, SaaS tenant, container platform, etc.):

1. What are the approved configuration settings? (baseline)
2. Where are they documented and version-controlled? (governed record)
3. How do you enforce them and detect drift? (technical enforcement + monitoring)
4. How do you approve and track deviations? (exceptions with rationale)

Assessors commonly treat “most restrictive mode consistent with operational requirements” as a balancing test. If you are permissive by default, you need a defensible reason tied to operations and a clear risk acceptance trail (NIST SP 800-53 Rev. 5 OSCAL JSON).

Who it applies to (entity and operational context)

CM-6 is relevant anywhere NIST SP 800-53 is a requirement driver, including:

• Federal information systems and programs aligned to NIST SP 800-53 controls (NIST SP 800-53 Rev. 5).
• Contractor systems handling federal data where contractual or program requirements call for NIST SP 800-53 alignment (NIST SP 800-53 Rev. 5).

Operationally, CM-6 applies to:

• Infrastructure you manage (IaaS, on-prem, network devices).
• Endpoints (workstations, mobile devices, VDI).
• Platforms (Kubernetes, CI/CD runners, identity systems).
• Cloud/SaaS configurations where you control tenant settings (even if you don’t control the provider’s underlying OS).

If you have third parties operating components on your behalf (managed service providers, hosted platforms), CM-6 still matters. Your due diligence must confirm who sets baselines, who enforces them, and what evidence you receive.

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

Step 1: Define CM-6 scope and component classes

Create a component list grouped into classes you can baseline consistently:

• Servers (Windows, Linux) by role (web, app, DB)
• Endpoints (corporate-managed, BYOD if applicable)
• Network/security appliances (firewalls, WAF, VPN)
• Cloud resources (accounts/subscriptions, IAM guardrails, logging)
• SaaS tenants (SSO, MFA, sharing controls, audit logging)

Tie each class to an owner: Infrastructure, Endpoint Engineering, Cloud Platform, Security Engineering, or App Platform.

Deliverable: CM-6 scope statement + component class matrix mapped to owners.

Step 2: Establish secure baseline settings per class

For each class, define:

• Baseline name + version
• Settings list (what must be on/off, minimums, allowed protocols/ciphers, logging)
• Rationale for restrictive defaults and any permitted relaxations
• Implementation method (GPO/Intune, Ansible, Terraform, MDM, config profiles)
• Validation method (CIS checks, SCAP-like scanning, cloud posture rules, scripts)

Keep baselines “operator-usable”: implementable settings, not generic statements like “systems are hardened.”

Deliverable: Baseline documents (or policy-as-code repositories) per class, with version history.

Step 3: Document how baselines are approved and changed

CM-6 collapses quickly if engineering changes settings informally. Put baselines under change control:

• Approval workflow (Security + system owner)
• Versioning (Git tag or document version)
• Emergency change path (with after-the-fact review)
• Back-out plan for high-risk changes

Deliverable: Configuration baseline governance procedure tied to your change management process.

Step 4: Enforce settings technically (make drift hard)

Pick enforcement mechanisms appropriate to the component:

• Endpoints: MDM configuration profiles, device compliance policies
• Windows: GPO / configuration management tooling
• Linux: configuration management (Ansible/Puppet/Chef) and hardened images
• Cloud: Terraform modules, org policies, guardrails, policy-as-code checks
• Kubernetes: admission controls, baseline pod security settings, hardened node images
• SaaS: tenant policy settings + conditional access rules

Document the enforcement mapping: baseline control → tool → deployment scope.

Deliverable: “Baseline-to-enforcement” mapping table and proof of deployment scope.

Step 5: Monitor for compliance and configuration drift

You need ongoing detection, not point-in-time screenshots:

• Scheduled configuration compliance scans
• Cloud configuration posture rules with alerting
• File integrity/config drift monitoring for critical components
• Exception-aware reporting (so known deviations don’t cause noise)

Define what happens when drift is found:

• Triage (is it malicious, operational, or misconfiguration?)
• Remediation SLA targets (define internally as policy)
• Ticketing and closure evidence

Deliverable: Drift monitoring runbook + sample drift reports + remediation tickets.

Step 6: Build an exception process that auditors accept

You will have exceptions. Make them governable:

• Document the specific setting(s) deviating
• Operational requirement (business justification)
• Risk assessment and compensating controls
• Approvals (system owner + Security)
• Expiration date and review cadence
• Evidence that the exception is implemented as documented

Deliverable: Exception register with approvals and periodic review evidence.

Step 7: Package evidence so assessments are fast

Prepare an assessor-ready binder (or GRC control record) that includes:

• Scope and component inventory mapping
• Baselines and versions
• Enforcement and monitoring proof
• Exceptions and risk decisions
• Change records showing updates to baselines over time

Where Daydream fits naturally: Daydream helps teams map CM-6 to a named control owner, a repeatable implementation procedure, and a recurring evidence checklist so you stop rebuilding the same artifact set for every assessment (NIST SP 800-53 Rev. 5 OSCAL JSON).

Required evidence and artifacts to retain (audit-ready checklist)

Use this as your minimum evidence set:

• CM-6 control narrative (what you do, who owns it, what tools enforce it)
• Component class inventory and in-scope boundary statement
• Baseline configurations per class (versioned)
• Baseline approval records (change tickets, pull requests, CAB notes)
• Technical enforcement evidence (policy assignments, IaC repos, deployment logs)
• Configuration compliance/drift reports (most recent + trend view if available)
• Exception register with approvals, compensating controls, and expirations
• Remediation records (tickets showing drift closure)
• Access controls for baseline repositories (who can edit, who can approve)

Common exam/audit questions and hangups

Auditors and assessors tend to probe these areas:

• “Show me the baseline for this specific server / cloud account.”
  Hangup: you have a “standard” but can’t show which baseline applies to which asset.

• “Prove the baseline is enforced, not optional.”
  Hangup: baselines live in PDFs; enforcement is manual and inconsistent.

• “Explain this less restrictive setting.”
  Hangup: no operational requirement documented, or exceptions never expire.

• “How do you detect drift and respond?”
  Hangup: you scan, but there’s no workflow proving remediation happens.

• “How do you keep baselines current?”
  Hangup: no governance, no reviews, no version history.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails CM-6	Fix
One baseline for “everything”	Doesn’t reflect operational requirements by component role	Create baseline families by platform + role
Document-only hardening	No proof the setting exists in production	Map every baseline item to an enforcement mechanism
Exceptions via email/Slack	No auditable approvals, no expiration	Use a standard exception form and a register
Drift alerts without closure	Findings repeat forever	Tie drift to tickets and require closure evidence
Baseline changes without approvals	Settings become ad hoc	Put baselines under change control with versioning
Ignoring SaaS tenant settings	Major control gaps in modern environments	Treat SaaS configs as components with baselines

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for this requirement, so you should treat CM-6 as an assessment-readiness and control-effectiveness expectation rather than a standalone enforcement trigger in this write-up.

Practically, CM-6 gaps create predictable failure modes:

• Unhardened defaults expand attack surface (open services, weak logging, permissive IAM).
• Inconsistent settings across fleets make incident response slower because you can’t trust what’s deployed.
• Exceptions without expiry become permanent “shadow standards.”

If you want CM-6 to reduce operational risk, anchor it to two measurable outcomes: baseline coverage (what portion of in-scope assets are under a baseline) and drift closure (how reliably you remediate deviations). Keep those measures internal if you can’t source benchmark numbers.

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it testable)

• Name a CM-6 control owner and backups; confirm engineering counterparts per platform.
• Define in-scope component classes and map them to your inventory.
• Select a small set of baseline templates (even if incomplete) for the highest-risk classes.
• Stand up an exception register and require it for any known deviations.
• Produce an assessor packet for one pilot class (baseline + enforcement + drift evidence).

Next 60 days (enforce and instrument)

• Convert baseline documents into enforceable configurations (GPO/MDM/IaC/config management).
• Implement drift monitoring for the pilot classes and route findings to tickets.
• Add baseline governance: approvals, versioning, and an emergency change path.
• Expand to additional component classes, prioritizing internet-facing and identity components.

By 90 days (scale coverage and normalize operations)

• Standardize baseline-to-enforcement mapping across all major classes.
• Operationalize exception reviews and expirations; close stale exceptions.
• Run an internal “mock selection test”: pick random assets and prove baseline, enforcement, and drift handling.
• Integrate CM-6 evidence collection into your recurring GRC rhythm (monthly/quarterly evidence pulls based on your assessment cycle).

Frequently Asked Questions

What counts as a “configuration setting” under CM-6?

Any security-relevant parameter you can define and enforce for a component, including OS hardening, IAM guardrails, logging settings, network services, protocol settings, and SaaS tenant security controls (NIST SP 800-53 Rev. 5).

How do we justify “most restrictive mode consistent with operational requirements”?

Write down the operational requirement, name the specific setting that must be less restrictive, and document compensating controls plus approvals in an exception record. Auditors accept tradeoffs when the documentation is specific and the exception is governed (NIST SP 800-53 Rev. 5 OSCAL JSON).

Do we need CIS benchmarks to meet CM-6?

CM-6 does not require a specific benchmark by name in the provided text. You do need documented baselines and proof they are enforced and monitored (NIST SP 800-53 Rev. 5 OSCAL JSON).

How should we handle third parties that manage infrastructure for us?

Treat them as operators of your components. Require contract language or due diligence evidence that they maintain baselines, enforce them, monitor drift, and provide evidence on request.

Are screenshots acceptable evidence?

Screenshots can support point-in-time validation, but assessors usually want repeatable evidence such as policy assignments, configuration exports, drift reports, and tickets that show ongoing operation.

What’s the minimum exception process that won’t get challenged?

A centralized register with setting-level deviation details, business rationale, risk/compensating controls, approvals, and a defined expiration and review trigger. If you can’t show expirations and re-approvals, exceptions tend to look like permanent bypasses.