Configuration Settings

To meet the FedRAMP Moderate configuration settings requirement, you must define, document, and enforce secure configuration settings for every in-scope system component, using your standard secure baselines and running each component in the most restrictive mode that still supports operations (NIST Special Publication 800-53 Revision 5). Auditors will look for documented baselines, approved exceptions, and evidence that your actual settings match what you claim.

Key takeaways:

• “Configuration settings” is a baseline-and-enforcement problem: define the secure standard, then prove systems stay on it (NIST Special Publication 800-53 Revision 5).
• “Most restrictive mode” means disabling unnecessary services, accounts, ports, protocols, and features unless you can justify them for business need (NIST Special Publication 800-53 Revision 5).
• You need durable evidence: baseline documents, change approvals, drift reports, and exception/risk acceptances tied to assets.

CM-6 (Configuration Settings) is one of the fastest ways an assessor distinguishes “we have policies” from “we control production.” FedRAMP Moderate expects you to establish and document configuration settings for components in your system, align them to common secure configurations, and operate them in the most restrictive mode consistent with operational requirements (NIST Special Publication 800-53 Revision 5). That phrase hides the operational hard part: you must standardize secure baselines across heterogeneous tech stacks (cloud services, OS images, containers, network devices, databases, SaaS admin consoles) and keep them enforced as systems change.

A workable CM-6 program has three layers. First, a written baseline per component type (what “secure” means here). Second, technical enforcement and monitoring (how you prevent drift or detect it quickly). Third, a controlled exception process (how you allow a deviation without losing control). If you get these three right, CM-6 becomes an engine that supports other control families: vulnerability management, change control, access control, logging, and incident response.

Regulatory text

Requirement (excerpt): “Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using organization-defined common secure configurations.” (NIST Special Publication 800-53 Revision 5)

What the operator must do:

1. Identify the “components employed within the system” that fall in scope for your FedRAMP boundary.
2. Define “organization-defined common secure configurations” (your standard baselines) for those components.
3. Document the required settings and ensure they run in a restrictive-by-default posture.
4. Allow deviations only when operations require it, and control those deviations through approvals and evidence.

Plain-English interpretation

CM-6 requires you to decide what “secure configuration” means for each technology you run, write it down, and keep production aligned to it. “Most restrictive mode” means you start from deny-by-default: turn off what you do not need, and explicitly justify what you keep. If you cannot show a baseline and proof that systems conform (or have approved exceptions), you will struggle in assessment.

Who it applies to

Entities: Cloud Service Providers and Federal Agencies operating systems assessed under FedRAMP Moderate (NIST Special Publication 800-53 Revision 5).

Operational context (where CM-6 shows up):

• Cloud infrastructure: VPC/VNET defaults, security groups, NACLs, IAM policies, managed service configuration.
• OS and endpoints: hardened images, local security policies, services/daemons, remote administration settings.
• Containers/Kubernetes: admission controls, network policies, pod security, image provenance policies.
• Databases and middleware: TLS requirements, auth modes, audit settings, unsafe features disabled.
• SaaS/admin consoles used in the boundary: tenant-wide security settings, authentication, sharing defaults.

If it’s in your authorization boundary and you administer it, assume CM-6 applies.

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

1) Define scope: build the component inventory you will baseline

Create an inventory that maps each in-scope component to:

• Owner (system/service owner)
• Environment (dev/test/prod within boundary)
• Technology class (Linux, Windows, firewall, Kubernetes, managed DB, etc.)
• Configuration authority (who can change it)
• Baseline identifier (which secure configuration applies)

Practical tip: Assessors will ask how you know you didn’t miss anything. Tie inventory to your CMDB, cloud asset inventory, and IaC repositories so “components employed within the system” is defensible.

2) Create “common secure configurations” (baselines) by component class

For each component class, write a baseline standard that includes:

• Settings list: the actual parameters (not just “harden the server”).
• Rationale: why a setting exists, especially if it is restrictive.
• Implementation method: GPO, MDM, configuration management, IaC module, cloud policy, etc.
• Verification method: how you test/measure compliance (queries, scripts, scanner profiles).
• Exception triggers: what operational need might require deviation.

Keep baselines “common” by standardizing at the platform level. Example: one Linux baseline per major distro family, not a bespoke baseline per app server.

3) Encode baselines into build pipelines and automation

Documented settings are necessary, not sufficient. Operationalize by making the secure configuration the default path:

• Golden images: bake OS baselines into images; version them.
• Infrastructure as Code: define restrictive defaults in modules (security groups deny broad ingress; encryption on; logging on).
• Configuration management: enforce packages, services, file permissions, registry keys, and local policies.
• Cloud policy controls: require specific settings (for example, prevent public exposure, require encryption flags, block risky API calls).

Evidence goal: you can show the baseline, and you can show the mechanism that applies it repeatedly.

4) Implement drift detection and response

You must be able to detect when real-world settings diverge from documented baselines:

• Schedule configuration compliance checks (agent-based, API-based, or scanner-based).
• Generate drift reports that identify asset, setting, expected value, actual value, and severity.
• Assign drift findings into your ticketing workflow with ownership and due dates.
• Define what requires immediate rollback vs. planned remediation.

Operational nuance: Some drift is “normal” during incident response or urgent fixes. CM-6 expects you to control it afterward through change records and re-baselining or exception approvals.

5) Establish an exception process tied to operational requirements

“Most restrictive mode consistent with operational requirements” implies exceptions will exist. Make them controlled:

• Require a written justification tied to a business/mission need.
• Require compensating controls if the deviation increases exposure.
• Require time bounds or periodic review.
• Record risk acceptance with approver identity and date.

A clean exception register often saves an audit. A messy one guarantees follow-up questions.

6) Align CM-6 to change management

CM-6 will fail if change management is separate from configuration control:

• Any configuration change should reference a baseline control, or explicitly declare it an exception.
• Emergency changes need post-implementation review against baseline.
• Baseline updates should follow review/approval and be versioned like code.

7) Prepare the assessment narrative (how you explain the control)

Write a short control implementation statement that maps:

• Component classes in scope
• Baseline documents and where stored
• How applied (automation points)
• How monitored (drift tooling, cadence)
• How exceptions are handled

This becomes your consistent “single story” across engineering, security, and the assessor.

Required evidence and artifacts to retain

Keep evidence that proves three things: baseline exists, baseline is enforced, deviations are controlled.

Baseline documentation

• Secure configuration standards per component class (versioned)
• Mapping of components to applicable baselines
• Configuration parameter lists (or references to code/policy as the source of truth)

Enforcement and validation evidence

• Build artifacts (golden image pipeline outputs, IaC module versions)
• Configuration management policies and recent compliance results
• Drift/compliance reports showing current state vs baseline
• Samples of system configurations demonstrating key settings applied

Exception management

• Exception request/approval records
• Risk acceptances and compensating controls
• Exception register with status and review history

Change management linkage

• Change tickets referencing configuration changes
• Approvals and post-change verification notes

Common exam/audit questions and hangups

• “Show me your secure configuration baseline for each major component type in the boundary.”
• “How do you ensure new instances inherit the baseline by default?”
• “How do you detect configuration drift, and what do you do when you find it?”
• “Where are exceptions documented, who approves them, and how do you review them?”
• “Prove this specific production asset matches the documented baseline.”
• “How do you ensure ‘most restrictive mode’ while still supporting operational requirements?” (Expect to explain your exception logic.)

Hangup to anticipate: teams can describe hardening but cannot produce a parameter-level baseline or evidence that it is continuously enforced.

Frequent implementation mistakes and how to avoid them

1. Writing a policy instead of a baseline.
   Fix: require setting-level standards (what value, where set, how verified).

2. Baselines that are not “common.”
   Fix: standardize by platform class; allow app-specific config in separate app runbooks.

3. Manual configuration as the default.
   Fix: move baseline into images/IaC/config management so it is repeatable and testable.

4. No credible drift story.
   Fix: run compliance checks continuously; track remediation tickets; retain reports.

5. Exceptions handled in email/DMs.
   Fix: centralize exceptions with approvals, rationale, and review triggers.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, CM-6 failures still create real exposure: permissive defaults, undocumented admin console settings, and one-off “temporary” configuration changes are common root causes of unauthorized access paths and audit findings. Treat CM-6 as the control that prevents insecure defaults from returning after every deployment.

A practical 30/60/90-day execution plan

First 30 days: establish control ownership and minimum viable baselines

• Assign a CM-6 owner and platform owners for each component class.
• Produce the in-scope component inventory and baseline-to-asset mapping.
• Publish initial baselines for the highest-risk component classes (internet-facing gateways, IAM, logging, and core OS images).
• Stand up an exception register with an approval workflow.

By 60 days: enforce by default and start measuring drift

• Embed baselines into golden images and IaC modules.
• Implement at least one automated compliance/detection method per component class.
• Begin generating drift reports and tracking remediation through tickets.
• Run a tabletop assessment with a mock auditor: pick assets and prove baseline alignment end-to-end.

By 90 days: mature the program and make it sustainable

• Expand baselines to remaining component classes in the boundary.
• Add periodic exception reviews and retire stale exceptions.
• Integrate CM-6 checks into CI/CD gates where feasible (prevent known-bad settings from deploying).
• Produce an assessor-ready evidence pack: baselines, drift reports, sample configs, exception records, and change linkages.

Where Daydream fits: If your bottleneck is collecting evidence across teams and tools, Daydream can act as the system of record for baseline documents, exception approvals, and recurring evidence requests, with structured checklists that map artifacts back to CM-6.

Frequently Asked Questions

Do we need a separate configuration baseline for every application?

No. CM-6 expects “common secure configurations,” so baseline by component class (OS, database engine, Kubernetes, cloud account) and keep app-specific settings in application runbooks with controlled exceptions where needed.

What does “most restrictive mode consistent with operational requirements” mean in practice?

Start from restrictive defaults (disable unused services, close ports, require strong auth, least privilege) and open only what the service needs. If you must relax a setting, document the operational need and approve it as an exception.

Are Infrastructure as Code templates acceptable as “documented configuration settings”?

Yes, if the templates are controlled, versioned, and clearly represent the intended baseline, and you can show deployed infrastructure matches them. Keep a readable baseline standard that points to the relevant modules/policies as the source of truth.

How do we handle managed cloud services where we can’t change all underlying settings?

Document what you can configure, set those options to restrictive defaults, and record shared-responsibility boundaries in your baseline. Your evidence should show the settings you control, and monitoring for the ones you can verify via provider APIs.

What evidence is most persuasive to an assessor?

A parameter-level baseline document plus automated compliance results that show real assets conform, along with a clean exception register for deviations. Screenshots alone are weaker unless they’re clearly tied to asset identity and date.

How often should we review configuration settings?

Review whenever platforms change (new services, major version upgrades, new threat-driven hardening) and as part of normal governance cycles. The key is to show baseline version control, change approvals, and continuous drift monitoring rather than relying on a once-a-year review.