What CM-6 configuration settings require and why audits fail on them
CM-6 asks an organization to establish and document configuration settings for its system components that reflect the most restrictive mode consistent with operational requirements, using defined common secure configurations as the reference. The organization must implement those settings, approve and document any deviations, and monitor and control changes to them. For a compliance lead or platform engineer, the practical question is simple: can you show, for every component in scope, which settings apply, who approved any exception, and when a setting last changed? Drift is what makes that question hard to answer. A cluster of hosts, containers, databases and network devices can each be correct on the day they are built and wrong six months later after a hotfix, a vendor update or an engineer's troubleshooting change that never reached the change record.
Audits tend to fail on the gaps between documentation and reality. Common findings include a secure configuration baseline that exists in a policy document but is not tied to any checklist the platform team uses, undocumented exceptions that were granted verbally, and settings changed outside change control that nobody detected. Assessors working from the SP 800-53A procedures for CM-6 typically examine the configuration management plan, the common secure configuration checklists, the component inventory, deviation approvals and change control records, then interview the people who run configuration management and test whether the process works. Before any engagement, confirm which checklists your organization has adopted as its common secure configurations and whether each one can be compared against live settings.
Scope also matters. CM-6 is selected in the low, moderate and high security control baselines but not in the privacy baseline, so its obligations depend on the impact level your systems were categorized at. Of its four numbered enhancements in Release 5.2.0, only two are current: CM-6(1), on automated management, application and verification of settings, and CM-6(2), on responding to unauthorized changes. The high baseline selects both. Confirm with your assessor whether your authorization boundary requires them, because automated drift detection is the usual route to producing evidence that the settings remain as approved.
Which systems and teams CM-6 configuration settings apply to
CM-6 applies wherever a system is in the authorization boundary, but the impact level, the component types and the owning teams decide how much work it creates. The cards below cover the decisions that set that scope and the related controls that read from the same settings records.
Impact level sets the baseline
SP 800-53B selects CM-6 for the low, moderate and high baselines, so the impact categorization of the system decides whether the control applies and how much of its enhancement set comes with it. Confirm the categorization in the system security plan before scoping settings work, because a change in impact level changes the required scope. Record which baseline and any tailoring decisions the authorizing official accepted.
High baseline adds enhancements
Only the high baseline selects CM-6(1) for automated management, application and verification and CM-6(2) for responding to unauthorized changes. Systems at high impact should plan tooling that pushes settings, verifies them and raises alerts on drift, not only manual checklists. Ask whether the chosen tooling can produce verification records that an assessor can examine.
Privacy baseline does not select CM-6
The privacy baseline does not select CM-6, so a system that handles only privacy-scoped data at a lower impact level does not inherit this control on that basis alone. Security baselines still govern the settings of the same components, so teams should not treat the privacy baseline as a reason to drop settings documentation. Confirm which baseline applies to each system in the boundary.
Component types in scope
CM-6 covers the system components whose settings affect security, including operating systems, hypervisors, databases, network devices, container images, cloud service configurations and endpoints. Build the list from the component inventory rather than from memory, and flag components that are managed by a provider and cannot be configured directly. Those components need inherited or documented responsibility statements.
Teams that own settings
Settings are usually owned in parts: the platform team for servers and clusters, the endpoint team for workstations, the cloud team for account and network policy, and application teams for their own services. Write down which team owns each setting group and who approves a deviation. Unclear ownership is the most common reason a settings baseline drifts from what is deployed.
Related controls read the same records
CM-2 baselines, CM-3 change control, CM-7 least functionality and CM-8 component inventory depend on the same settings records that CM-6 produces. An inconsistent value in one place creates a finding in several controls at once. Keep one authoritative settings source and check that each related control points to it.
How assessors test CM-6 configuration settings
This table maps the SP 800-53A examine, interview and test methods to the objects an assessor will request for CM-6 and the findings that commonly appear. Read each row as a question the assessor will ask and the evidence you should have ready before fieldwork begins.
| Assessment method | Objects the assessor will request | Common findings |
|---|---|---|
| Examine: configuration management plan and settings documentation | Configuration management plan, documented configuration settings for each component type, and the defined common secure configurations the organization has chosen | Settings documented only at a general level, or no defined common secure configuration named for a component type |
| Examine: common secure configuration checklists | Checklists or benchmarks in use, dated versions, and records showing which settings were adopted and which were tailored | Checklist versions older than the platform in production, or no record of why a setting differs from the benchmark |
| Examine: component inventory and deviation approvals | System component inventory cross-referenced to the applicable settings, and signed approvals with justification and expiry for each deviation | Components in the inventory with no assigned settings baseline, or deviations that were discussed but never formally approved |
| Examine: change control records for settings | Change tickets, approvals, impact analyses and implementation records for settings changes over a defined review period | Settings changed outside the change process, or tickets that close without showing what was actually changed |
| Interview: personnel with configuration management responsibilities | Owners of the baseline, the people who approve deviations, and administrators who apply settings to components | Administrators who cannot name the approved settings for their systems, or unclear ownership between platform and security teams |
| Test: settings compared to documented configuration | A live sample of component settings compared against the documented checklist, using scanner or agent output or manual verification | Live settings that differ from the checklist without an approved deviation, or drift that monitoring did not flag |
| Test: detection and response to unauthorized changes | Evidence that settings are monitored, that alerts are generated for unapproved changes, and that responses are recorded | Monitoring that exists but does not cover all component types, or alerts that are generated and never reviewed |
Implementing CM-6 configuration settings in order
The sequence below moves a system from choosing a secure configuration source to a documented, verified and change-controlled settings baseline that an assessor can trace from requirement to evidence.
Select common secure configuration sources per component class
Start by listing every component class in scope, such as operating system images, container hosts, network devices, databases and application servers. For each class, the engineering lead and the security team select the common secure configuration source they will work from, such as a vendor hardening guide or a recognized community benchmark, and record why it was chosen. CM-6 asks for defined common secure configurations, so the organization must name them rather than adopt settings ad hoc. Output: a source register that maps each component class to its chosen configuration source and version, approved by the system owner.
Write the settings baseline with the most restrictive values
For each component class, the engineering team turns the selected source into a settings baseline. Each setting is set to the most restrictive value that operations still allow, and any setting the business cannot accept is flagged for a deviation rather than quietly relaxed. Operations staff confirm the values work for the workload. Output: a checklist per component class listing each setting, its approved value, the source it came from and any operational constraint noted beside it.
Apply settings through automated configuration
Implement the baseline using configuration management tooling, golden images or infrastructure-as-code templates so that the same values are applied to every new and existing component of that class. Manual changes are kept to a minimum because they are hard to repeat and hard to evidence. Output: versioned configuration code or image definitions stored in a controlled repository, with the baseline version recorded against each deployed component.
Verify applied settings against the baseline
Run an automated comparison between the approved checklist and the live state of each component. Failed checks are either remediated or moved into the deviation process. Security configuration assessment tooling, such as an agent that evaluates files, registry keys, processes and services against YAML policies, can produce this comparison, but the team should confirm which checks it supports and map them to the baseline. Output: a verification report per component class showing passing and failing settings, the date of the scan and the baseline version tested.
Document and approve deviations with owner and rationale
Every setting that does not match the baseline becomes an entry in a deviation register. Each entry names the component, the setting, the value in place, the business or technical reason, the risk accepted, the compensating measure if any, the owner and the approver. The approver should be someone with authority over the risk, not only the person who wants the exception. Output: a deviation register that an assessor can sample, with each approval traceable to a named decision.
Connect configuration changes to change control
Any change to a baseline value, a deviation or a configuration template goes through the same change control path used for other system changes. The request records the setting affected, the security impact analysis, the approver and the implementation date. Changes made outside this path show up in the monitoring step as drift. Output: change records linked to baseline versions, so that each current setting can be traced to an approved change.
Monitor for drift and respond to unauthorized changes
Schedule recurring verification runs and alert on any setting that differs from the approved baseline without a matching change record or deviation entry. The team investigates each alert, restores the approved value or opens a change, and records the outcome. Where the high baseline applies, this step also covers automated response to unauthorized changes. Output: a drift log with each alert, its disposition and the linked change or deviation, reviewed at a frequency the organization defines.
Evidence that passes CM-6 configuration settings testing
An assessor testing CM-6 looks for a documented standard, proof that it is applied to each component, and a record of every exception and change. The cards below cover the artifacts that connect those three points and how to keep each one current between assessments, so the evidence reflects the system as it runs today.
Configuration management plan
The plan names who owns configuration settings, which components are in scope and how settings are approved, changed and reviewed. It gives the assessor the frame for every other artifact. Check that it references the current common secure configurations and the deviation process by name, and that its roles match the people an interviewer will meet. Review it on a set schedule and after any reorganization of the team that operates the system.
Common secure configuration checklists
Each component type, such as Linux servers, container hosts, databases and network devices, needs a written checklist of the settings that define the most restrictive mode consistent with operations. Record the source benchmark or internal standard for each checklist and the version it was taken from. Assessors compare these checklists against the running system, so keep a dated revision history and note every item the organization changed from the source.
Component inventory linked to settings
A checklist only proves something if you can show which checklist applies to which component. Reconcile the system component inventory with the settings baseline so every component has a named configuration profile and an owner. Run this reconciliation whenever components are added, retired or rebuilt, and before each assessment, so an assessor cannot find a host that is in production but absent from the inventory or the baseline.
Approved deviation records
Where a component cannot meet a setting, the deviation record states the setting, the reason it cannot be met, the compensating measure, the approver and an expiry date. Every deviation needs an expiry date and a named approver. Review open deviations at a defined interval and close those whose underlying reason has gone. Ask the assessor's expectations for review frequency in advance, since the plan should set it.
Change control records tied to settings
Records of each change to a configuration setting show the request, the impact review, the approval, the implementation date and the person who made it, and whether the post-change scan confirmed the result. Link each entry to the ticket that authorized it. Sample a few changes from the reporting period and confirm each one traces from request through verification, since gaps between a change and its ticket are a common finding.
Scan and verification results
Scan output shows the current state of settings on each component and is the strongest evidence that the documented standard is applied. Schedule automated scans, keep their results with timestamps, and retain the history so that assessors can see drift over time. Open-source tools such as Wazuh Security Configuration Assessment, which runs YAML policies mostly based on CIS benchmarks, and Fleet, which reports the devices passing or failing each osquery policy, can produce this evidence. Confirm each tool's policy coverage against your own checklists before relying on its output.
What CM-6 configuration settings cost to meet
This table breaks down the cost components of meeting CM-6 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. No dollar figures are supplied for this control, so use it to shape a written scope and quote request, and read the drivers column to see where spend concentrates. Licenses are the cost most often removed by self-hosted open source, while staff time for settings, deviations and evidence remains.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling or licenses | Tool vendor or none for open source | Recurring if licensed, otherwise none | Number of endpoints and server types covered, and whether scanning content is commercial or community |
| Engineering time to define settings | Internal staff or implementation partner | One-time, then recurring on change | Number of component types, and how many common secure configurations the organization adopts |
| Applying and hardening settings | Internal platform or systems engineers | One-time per component type, then per new build | Degree of existing automation, such as configuration management code or golden images |
| Verification and scanning operations | Internal security operations staff | Recurring | Scan frequency, number of monitored endpoints, and triage volume of findings |
| Deviation administration | Change control owners and approvers | Recurring | Number of approved deviations, and whether each one needs documented risk acceptance |
| Unauthorized change response (high baseline) | Security operations and platform engineers | Recurring, plus one-time setup of alerting | Whether CM-6(1) and CM-6(2) apply, which depends on the high baseline selection |
| Evidence upkeep | Compliance lead and system owners | Recurring | Frequency of assessments, number of systems, and how much evidence is generated automatically |
| External testing or review | Independent assessor or testing firm | Periodic | Scope of the system boundary and how many configuration samples the assessor selects |
| Auditor sampling time | Independent assessor | Periodic | Sample sizes for settings, deviations and change records, and quality of the evidence index |
Where CM-6 configuration settings programs usually fall short
Most CM-6 findings are not about missing a hardening guide. They come from settings that drift from the documented baseline, deviations that never expire, and changes that bypass the records an assessor will sample. The cards below pair each common gap with the action that closes it, so the configuration checklist, the deviation register, the inventory and the change records all describe the same running systems.
Checklists that drift from live settings
A common secure configuration checklist is approved once and then left alone while the systems it describes keep changing. Assessors compare the checklist against what the components actually run, and any gap between the two becomes a finding. Schedule a recurring comparison of the documented settings against live configuration on a sample of components, and record which checklist version each system was last verified against. Where the mismatch is caused by an unreviewed vendor update, route the update through change control before the checklist is changed.
Deviations approved informally or never expired
Teams often accept a weaker setting for a legacy application with an email or a chat message, and nobody records the justification, the approver or the end date. CM-6 expects approved and documented deviations, and an assessor will ask for the evidence behind each one. Keep a deviation register that names the setting, the affected components, the business reason, the compensating measure, the approver and a review date. Remove or renew each entry on its review date, and treat an undated deviation as an open finding.
Settings changed outside change control
Administrators sometimes adjust a security setting directly on a server, in a cloud console or through a one-off script to fix an outage, and the change never reaches the change record. The configuration then differs from the baseline without any explanation. Require that emergency changes still generate a ticket within a defined window, and compare current settings against the last approved baseline to surface changes that have no matching record. The goal is that every setting change can be traced to an approval or an emergency record.
No link between inventory and settings records
A configuration record that does not name the components it applies to cannot show coverage. When the component inventory lists systems that the configuration records omit, or the reverse, the organization cannot prove that every in-scope component was configured. Tie each configuration baseline to inventory identifiers, so a new host either inherits a baseline or appears on an exception list. Check the match between the two sources during each review cycle.
Unclear ownership across platform and application teams
Operating system settings may belong to the platform team, while application and database settings belong to product owners, and gaps appear at the boundary. Each team assumes the other has set or verified the control. Write a responsibility matrix that assigns each setting group to one owner, names the reviewer, and states who signs off on deviations. Assessors will interview the people in these roles, so the matrix should match what those people say they do.
No response procedure for unauthorized changes
Detecting a changed setting is only useful if someone knows what to do with the alert. Without a defined procedure, a drift alert may sit in a queue, be closed without investigation, or be reverted without a record. CM-6 enhancement CM-6(2) in the high baseline addresses responding to unauthorized changes. Define who receives each alert, the triage steps, when a change is reverted automatically or escalated to incident response, and where the outcome is recorded. Test the procedure with a planted change to confirm the alert reaches the right owner.
Open-source tools that produce CM-6 configuration settings evidence
Wazuh's Security Configuration Assessment module checks monitored endpoints against YAML policies and reports the result of each check, with remediation guidance for failing items. For CM-6, the output is a per-endpoint record of measured settings that can be compared with the organization's documented common secure configurations. Each check reads files, directories, registry keys or running processes, so the record shows the actual state of the setting rather than a statement that it was applied.
- Policy-level evidence: Each policy groups checks by benchmark or custom area, so the exported results show which settings were measured on which endpoints and on which date.
- Remediation records: Keep each recommendation with the change ticket that fixed it, so a corrected setting traces back to the approved change process.
- Custom policies: Settings your organization approved but that the shipped content does not cover can be written as custom policies, which makes them testable.
- Coverage gap: The shipped policies are based mostly on CIS benchmarks. A passing check shows conformance to that benchmark, not to your own approved settings, so map each check to a named approved setting in writing.
- License caveat: Wazuh is licensed GPL-2.0-only. Ask counsel how those terms apply if you modify the software or share modified copies outside the organization.
Confirm with Wazuh which policy versions were in use on each assessment date, and keep those versions with the results.
Fleet policies are yes or no questions asked of devices as osquery queries. The policies page shows which devices in each fleet pass or fail each policy. For CM-6, this gives a current, device-by-device view of whether a specific setting holds, which suits workstations and laptops where settings drift between scans. The result is only as good as the question asked, so each policy needs a clear expected value.
- Single-setting questions: Write each policy to test one approved setting with an explicit expected value, so a failing result points to one setting.
- Per-fleet pass and fail views: The policies page shows passing and failing devices for each fleet, a record an assessor can sample during CM-6 testing.
- Fleet membership: Group devices into fleets that match the configuration they must follow, so each pass or fail result is tied to the correct baseline.
- Coverage limits: A policy tests only what its query asks. Settings that no query checks, and settings held only inside application configuration, will not appear in the results.
- License caveat: Fleet is MIT licensed, a permissive license. Confirm with the vendor which features and terms apply to your deployment, because any separately offered capability falls under its own terms.
Before relying on a policy, test that its query returns the expected result on each operating system you run, and store the query text with the results.
SP 800-53A lists examine objects for CM-6, including the configuration management plan, common secure configuration checklists, the system component inventory, evidence supporting approved deviations and change control records. Neither scanning tool produces all of these on its own. The assessor needs them packaged so that each determination statement traces to a named source, and the pack should be built from the assessor's sampling list rather than assembled after fieldwork begins.
- Checklist and version pairing: Export the approved checklist together with the policy or query version and the run date, so the assessor can see which standard each result was measured against.
- Inventory linkage: Tie endpoint results to the component inventory so the assessor can confirm every in-scope component was measured and none were skipped.
- Deviation evidence: Record each approved deviation beside the failing check it explains, with the approver, the reason and the review date.
- Change records: Link each remediation to its change ticket so the assessor can see the setting changed through the approved process.
- Interview and test support: Prepare the staff who own configuration management to explain the process, and keep a documented test showing that a deliberately changed setting is detected.
Ask the assessor which examine objects and interviewees they plan to sample, and confirm that each sampled item exists in the pack before fieldwork starts.
Questions buyers ask about CM-6 configuration settings
How much effort does CM-6 take to meet?
The effort depends on how many system component types you run, how many distinct configurations they need, and how much of the hardening is already documented. CM-6 asks for documented settings that reflect the most restrictive mode consistent with operations, using defined common secure configurations, plus approved and recorded deviations and change control over those settings. Most of the work is the first baseline: choosing the benchmark you will follow, tailoring it to operational needs, and proving it is applied across the estate. Ongoing effort is the recurring cost of reviewing deviations and checking drift. NIST does not publish effort or cost figures for SP 800-53 controls, so ask any partner to size the work from your component inventory and written scope.
Can we implement CM-6 in-house?
Yes, many organizations do. CM-6 is an organizational requirement, so your team owns the settings decisions, the deviation approvals and the evidence. What you need is someone who can translate a secure configuration benchmark into settings for each platform, a way to apply and verify them, and a process that routes deviations to an approver. Teams that lack automation or capacity often outsource the platform work, such as building configuration checks, deploying an assessment agent or documenting the baseline, while keeping approval authority in-house. Confirm internally who will sign off on deviations before you decide what to outsource.
What does our organization need to provide for CM-6?
You need a current component inventory, a configuration management plan that names roles and processes, a chosen set of common secure configurations, and a change control route for setting changes. You also need named people responsible for security configuration management who can answer assessor interviews. Evidence is specific: checklists or baseline documents, records of approved deviations with their justification, change control records, and results from configuration checks run against real systems. Access to the systems, their logs and your ticketing or change records is required so that an assessor can sample them. Gaps in any of these usually surface during assessment rather than during design.
How long does CM-6 take to implement?
No supplied source gives a duration for implementing CM-6, so this page does not state one. The time depends on the number of component types, the maturity of your current hardening, whether a benchmark already exists for each platform, and how quickly approvals move through your change process. Ask any implementation partner for a timeline built from a written scope that lists platforms, environments and deliverables. Your assessor's schedule will add its own lead time, which you should confirm with them directly.
Can a partner issue the CM-6 assessment result?
No. An implementation partner prepares systems, settings, checks and evidence, but only an independent assessor or auditor issues an assessment result or report. Under the NIST framework, the organization owns its controls and the authorizing official makes the risk decision, so the assessment outcome comes from the assessor. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Confirm with your sponsoring agency, contract or FedRAMP process which assessor is acceptable before work begins.
Which baselines select CM-6?
SP 800-53B Release 5.2.0 selects CM-6 for the low, moderate and high baselines, but not for the privacy baseline. Its enhancements are treated differently. CM-6(1), which covers automated management, application and verification of settings, and CM-6(2), which covers responding to unauthorized changes, are selected only in the high baseline. CM-6 has four numbered enhancements in Release 5.2.0, but CM-6(3) and CM-6(4) are withdrawn, leaving two current enhancements. Check your baseline profile in the NIST OSCAL content for the exact selection that applies to your system's impact level.
What should we ask for in a CM-6 quote?
Ask for a written scope that names the platforms, environments, number of component types and benchmarks in scope, and the deviation and change control processes that will be built or documented. A useful quote separates one-time work, such as baseline documentation and hardening, from recurring work, such as drift checks, benchmark updates and deviation reviews. Ask which deliverables are evidence artifacts you will keep, who approves deviations, how the partner handles findings it cannot close, and whether the quote covers assessor support. Ask what changes would require a new quote. Fixed scope and written deliverables make comparisons between partners practical.
How DeployOpen prepares CM-6 configuration settings for assessment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the secure configuration settings CM-6 asks for are defined, applied and evidenced before an assessor arrives. Your organization owns the control and approves the settings, while DeployOpen prepares the systems and evidence that an independent assessor then examines.
How we scope
- The written scope names the in-scope system components, the baseline configuration sources and the environments covered by CM-6.
- We agree which common secure configuration benchmarks you adopt, such as CIS-based or vendor hardening guides, before any settings change.
- The scope states who on your side approves configuration settings and deviations, and who signs off on the documented baseline.
How we build
- We document the most restrictive settings consistent with operations for each component type, with the operational reason for any relaxed setting.
- We apply settings through versioned configuration code so every applied value can be traced to an approved baseline.
- We configure monitoring that checks endpoints against the approved settings and records drift for review, using tools such as Wazuh or Fleet where they fit.
How we hand over
- You receive the configuration settings documentation, the deviation register with approvals, and the scan results mapped to CM-6 objects.
- We deliver a walkthrough of how change control records link to configuration settings changes, so your staff can answer assessor interview questions.
- Runbooks cover how to respond to unauthorized changes and how to re-baseline a component after an approved change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so settings stay current as benchmarks and components change.
- Retainers can include periodic review of deviations and checks that evidence still reflects the live configuration.
- Assessment decisions, reports and certifications remain with your independent assessor, and we confirm the evidence package before they test it.
