Compliance as code for NIST 800-53 CM-6

How much compliance as code for NIST 800-53 CM-6 costs and takes

If a contract, agency or FedRAMP-style requirement asks for CM-6 evidence, the cost and timeline depend on three things: the baseline you are assessed against, the number of platforms in scope, and how mature your configuration evidence already is. No supplied fact gives a price or duration for this work, so treat any figure you see in a proposal as something to test against the written scope. SP 800-53 was published in September 2020, and NIST's current release is Release 5.2.0 of 27 August 2025, so confirm which release your contract references before you size the work.

CM-6, Configuration settings, is owned by your organization. You decide the common secure configurations, approve deviations and keep them documented. The implementation partner prepares SCAP or policy content, configures scanners and pipelines, and packages the results. Only an independent assessor issues findings. CM-6(1) and CM-6(2) apply only in the high baseline according to SP 800-53B Release 5.2.0, so a moderate-baseline system does not need to fund those enhancements unless the contract adds them. Confirm the selected baseline with the contracting officer or authorizing official before scoping.

One-time work includes selecting the benchmark profile, tailoring rules to your approved settings, writing exception records and building the scan pipeline. Recurring work includes running scans, reviewing drift, updating content when upstream profiles change and retaining results for each assessment cycle. Ask any proposal to split these costs, name who performs each task, state the number of platform types covered, and list what the client must supply, such as access to hosts, change records and a named control owner. A quote without these items is not comparable with another quote.

Who is paid for what in a CM-6 automation project

This table shows who is paid for each part of a CM-6 automation project, whether the cost is one-time or recurring, and what drives it up. No prices are supplied for this topic, so use the drivers and quote requests in the right-hand columns to compare written proposals. The main takeaway is that the organization keeps the controls and the assessor issues the findings, while the partner, the tooling and the ongoing scan work carry most of the recurring effort.

Cost component	Who is paid	One-time or recurring and main drivers
Internal staff time	Organization's own configuration, platform and security teams	Recurring. Drivers: number of system component types, change approval volume, and who signs off deviations under CM-6.
Content selection and tailoring	Implementation partner, with organization approval	One-time, then revisited on each content release. Drivers: chosen SCAP profile, number of approved deviations, and the baseline the system is categorized under.
Scan setup and evidence packaging	Implementation partner	One-time setup, with recurring evidence refresh. Drivers: number of hosts, Kubernetes clusters and Wazuh agents, and report format required by the assessor.
Tooling licenses or hosting	Cloud or data center costs, and any commercial support contracts the organization chooses	Mostly recurring. Drivers: the open-source components are free to license, but hosting, storage for reports and support contracts vary. Confirm each with the vendor.
Ongoing scan and remediation work	Organization's operations team, with optional partner retainer	Recurring. Drivers: scan frequency, number of failed rules, and how quickly configuration drift is corrected.
Independent assessor	Assessor or auditor engaged by the organization	Periodic. Drivers: assessment scope, depth of testing under SP 800-53A, and whether the assessor reviews automated evidence or samples manually.
Quote request	Ask every bidder to state each line above separately	Request named roles, hours or fixed deliverables, assumed scope, exclusions for remediation work, and retainer terms.

What makes CM-6 automation more or less expensive

The cost of automating CM-6 rarely comes from the scanner itself. It comes from how many platforms, baselines, deviations, environments, custom rules and evidence pipelines the program must cover. Each card below is a lever you can narrow or standardize before asking for a quote.

Number of platform types

Each operating system family or runtime needs its own content, its own scan profile and its own remediation path. A fleet of RHEL and Ubuntu hosts plus an OpenShift cluster and some Windows endpoints means several parallel evidence pipelines. Ask which platforms are truly in scope for CM-6 and whether they can share one golden image. Reducing platform types is usually the largest single saving.

Baseline selected

CM-6 is selected in the high baseline with enhancements CM-6(1) and CM-6(2), so a high-impact system carries automated management and response-to-change expectations that a low baseline system does not. Confirm the impact categorization with the system owner before scoping tooling. A system moved from moderate to high adds enhancement work, not just more rules.

Tailoring and deviation volume

Every approved deviation from a benchmark profile needs a documented justification, an approver and a review date. Each deviation also becomes a rule that the scanner must skip or report differently, so the rule set and the exception register must stay in sync. Ask how many deviations the program expects and who maintains the exception register after the initial build.

Number of environments

Development, test, staging and production each need configuration baselines, scan schedules and drift checks. Costs grow with the number of environments because each one needs its own inventory feed and its own results store. Consolidating non-production environments onto one shared baseline and promoting configuration through version control keeps the rule set single and the evidence traceable.

Custom policy needs

Stock SCAP profiles and Wazuh policies cover common benchmarks, but organization-specific settings require custom XCCDF or OVAL content, YAML policies or Kyverno policies. Each custom rule needs authoring, peer review, testing against known good and known bad hosts, and ongoing maintenance when the platform updates. Check whether the required settings already exist in upstream content before commissioning new rules.

Evidence maturity

Pass and fail output from a scanner is only a starting point for an assessor. Assessors also look for who approved each baseline, when drift was detected, how it was remediated and whether records are retained and protected. Programs with structured, timestamped, retained results and a documented change path need less manual reconstruction at assessment time. Ask the assessor which evidence formats they accept before building the pipeline.

Which automation tool fits which configuration evidence

OpenSCAP is the usual choice when the question is whether an individual Linux host matches a documented secure configuration. The oscap scanner evaluates a system against SCAP content written in XCCDF and OVAL, and the ComplianceAsCode project supplies that content for RHEL, Fedora, Ubuntu, Debian and SUSE. The scan reports pass or fail for each rule, and the output can be written as HTML, ARF or XCCDF reports, which are the artifacts you hand to an assessor. OpenSCAP is licensed under LGPL-2.1-or-later.

Source content: ComplianceAsCode publishes SCAP source data streams and profiles, so you select the profile that matches your baseline rather than writing rules from scratch.
Evidence form: ARF and XCCDF results carry the rule identifiers and results an assessor can trace back to the configuration baseline.
Remediation: the same content family also ships Ansible playbooks and Bash scripts, which you can review before applying.
Scope limit: a scan proves the state at scan time, so schedule recurring scans and retain the reports.
Tailoring: profiles are customized in XCCDF, and every deviation needs documented approval under CM-6.

Confirm in the OpenSCAP getting started guide which content and profile names your distribution version supports before you cite them in a system security plan.

How a CM-6 compliance as code project moves from scope to evidence

The sequence turns CM-6 from a written configuration policy into machine-checkable settings, recorded deviations and scan reports that an independent assessor can test. Each phase produces an artifact that the next phase depends on. The organization owns the decisions, and the implementation partner prepares the content, tooling and evidence.

Confirm baseline and system boundary
The organization confirms which system, its impact level and its SP 800-53B baseline, then defines the boundary that CM-6 applies to, including every component type in scope such as operating systems, container platforms and endpoints. Security and compliance owners sign off on the scope statement. The output is a written boundary and an inventory of component types, which the system security plan and the assessor will use as the starting point. Check that the inventory matches what the scanners will later discover, and record any gaps as open items.
Select and tailor common secure configurations
Owners choose the secure configuration benchmark or profile that defines the most restrictive settings consistent with operational needs, then document each tailored setting and its rationale. This is where the organization decides what counts as a defined common secure configuration for CM-6 and where it accepts a deviation. The output is a tailored profile with a version identifier, reviewed and approved by the system owner. Confirm that the high baseline's CM-6(1) and CM-6(2) enhancements are either in scope or documented as not applicable, since SP 800-53B selects them only at the high baseline.
Build or select compliance content
The team either adopts an existing SCAP source data stream, such as the ComplianceAsCode content that the community maintains for supported Linux distributions and Kubernetes platforms, or writes custom rules for systems the content does not cover. Each tailored setting is mapped to a rule that can be evaluated, and the mapping is stored under version control. The output is a content bundle with a changelog and a list of rules that cannot be automated, which need manual evidence. Ask the implementation partner to show how each rule traces back to the approved profile.
Deploy scanners in the target environment
The team installs the assessment engines inside the client environment, such as the oscap scanner for SCAP content, Wazuh configuration assessment agents for endpoints, and Kyverno for admission and background checks in Kubernetes. Access to scanners and their result stores is restricted and logged so that the scan records can be trusted later. The output is a tested deployment where each tool reads the approved content and writes results to a central location. Verify on a non-production system that a known misconfiguration produces a failing result.
Run baseline scans and record deviations
The team runs an initial scan across the boundary and compares results with the approved profile. Each failing rule is either remediated or entered into a deviation register with a named approver, a business justification and a review date. The output is a baseline scan report plus a deviation register, both retained as evidence. Confirm that the deviation approvals come from the people the organization has authorized to accept configuration risk, not from the implementation team.
Remediate and enforce through policy
Engineers correct the failing settings through the organization's change process, and the same content is then used to enforce settings going forward. Enforcement can take the form of automated remediation scripts, configuration management playbooks or Kubernetes admission policies that block or warn on noncompliant resources. The output is a rescan showing the remediated state and a set of enforcement policies tied to the approved profile. Changes to the profile itself should flow through the same review process that approves the baseline.
Package reports as assessment evidence
The team collects scan outputs, policy reports, the approved profile, the deviation register, change records and the content version used for each scan into a single evidence package for the boundary. Reports are dated and reference the system they cover so that an assessor can match them to the scope statement. The output is an indexed evidence set that maps each CM-6 assessment objective to the artifact that addresses it. Ask the partner to confirm that scanner reports are stored unaltered and that the retention period matches the organization's own policy.
Hand the evidence to the independent assessor
The organization gives the evidence package, the scope statement and access to the environment to its independent assessor, who selects samples, runs the SP 800-53A procedures for CM-6 and forms its own conclusions. The implementation partner answers technical questions and reproduces scans on request but does not issue findings or ratings. The output is the assessor's report, which is the only document that establishes the control's status. Organizations should expect the assessor to test whether scans are repeatable and whether deviations were approved by authorized staff.

What must be in place before the first scan counts as evidence

A scan result only supports CM-6 when something defined it first. The cards below cover the documents, owners, approvals, change links, access and test runs that turn a pass or fail list into evidence an assessor can trace back to a decision.

Documented configuration standard

CM-6 asks the organization to establish and document configuration settings that reflect the most restrictive mode consistent with operational requirements, using defined common secure configurations. Before scanning, confirm the standard names the baseline (for example, a specific SCAP profile from ComplianceAsCode or a Wazuh policy) for each component type, with its version and date. Check that the scanner's profile ID and the document refer to the same baseline. An assessor will ask which document a failed rule traces back to.

Named owner for each setting

Every configuration setting in the standard needs a named owner who can approve a change and answer for the result. Owners should be roles that outlive individuals, such as the platform team lead for Kubernetes admission settings or the endpoint engineering manager for Linux hardening. Check the register by sampling settings and asking who would sign off a change. If the answer is a group alias with no accountable person, the evidence will not hold up in an interview.

Deviation approval record

Some systems cannot meet a setting for valid operational reasons. CM-6 expects those deviations to be approved and documented rather than silently failing. Each deviation record should name the rule, the affected system, the compensating measure, the approver and an expiry or review date. Check that every failing rule in the first report either passes, maps to an approved deviation or is opened as a remediation item. Unexplained failures are the most common finding at this step.

Change control linked to rescans

CM-6 requires organizations to monitor and control changes to configuration settings. A scan only shows drift if a change ticket triggers a rescan and the result is compared with the approved baseline. Test this with a harmless change on a non-production system: raise a ticket, apply the change, rerun the scan and confirm the report shows the change and the ticket reference. If the rescan is not tied to the change record, the scan proves the state on one day but not how it got there.

Scanner access and report retention

Scanner credentials should be read-only where possible, stored in a secrets manager and limited to the systems in scope. Reports need a retention period that covers the assessment window and must be stored in write-once or access-controlled locations so they cannot be edited after the fact. Confirm the retention period with your assessor and your own policy, then test retrieval by pulling a report from six months ago. Store the raw ARF or XCCDF output alongside any HTML summary, since the summary alone is harder to verify.

Dry run on a non-production system

Run the complete chain once on a non-production system that matches a production build: apply the standard, scan, record a deliberate drift, raise the change, rescan and produce the report. The dry run exposes gaps in profile selection, credential scope, parsing of results and deviation handling before a real assessment depends on them. Record what failed in the dry run and what was fixed, because that record itself shows an assessor that the process was tested before it was relied upon.

Questions buyers ask about CM-6 automation and assessment

Can we automate CM-6 in-house without an outside partner?

Yes, many teams can, provided they have engineers who understand the target operating systems, a change process that owns the approved settings, and time to maintain the content. The organization owns CM-6 either way. The work splits into choosing a baseline, tailoring rules, deploying the settings, running scans, and handling deviations. Outside help is usually most useful at the start, when the security baseline and scope are being agreed, and when evidence must be arranged for an assessor. Ask any partner to state in writing which steps it performs, which remain with your staff, and what it will not do, such as issuing an assessment result.

What skills and staff time does CM-6 automation require?

The work asks for three kinds of skill: platform administration for the systems being hardened, familiarity with SCAP or policy-as-code tooling, and change management to approve and record deviations. Staff effort recurs because each operating system release, Kubernetes version and application upgrade can change which settings apply. Effort is driven by the number of component types, how many environments exist, and whether results feed a ticketing or GRC system. Ask for a quote that lists component types in scope, the number of environments, and who approves configuration changes.

Does a clean OpenSCAP scan report satisfy CM-6 on its own?

No. A scan report is one piece of evidence. CM-6 also requires that the organization defines the settings it expects, implements them, approves and documents deviations, and monitors and controls changes to the settings. An assessor will look for the approved baseline, the record of who approved it, scan results over time, the list of accepted deviations with their justification, and the change records that show how settings were altered. The SP 800-53A assessment procedures describe which examine, interview and test methods an assessor may use, so ask your assessor which artifacts they will request before you build the evidence set.

How do Wazuh and Kyverno results differ from OpenSCAP results?

They measure different things at different points. OpenSCAP evaluates a host against SCAP content such as ComplianceAsCode profiles, and reports pass or fail for each rule in XCCDF, HTML or ARF output. Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, registry keys and processes. Kyverno writes PolicyReport resources for Kubernetes resources, from admission events and periodic background scans that reflect current cluster state. Each tool covers a different asset class, so most programs use more than one and must reconcile their rule sets. Confirm which benchmark or profile each tool enforces before counting results together.

What changes between the moderate and high baselines for CM-6?

The difference is in the enhancements. According to the NIST SP 800-53B Release 5.2.0 profiles, CM-6(1), which covers automated management, application and verification of settings, and CM-6(2), which covers responding to unauthorized changes, are selected in the high baseline only. The base CM-6 control applies at both levels. For a moderate system, the automated verification and response expectations in those enhancements are not required by the baseline, although many organizations adopt them anyway. For a high system, expect the assessor to test whether automated checks run, whether they detect unauthorized changes, and whether responses are documented. Confirm the impact level and baseline in your system security plan before scoping the work.

How should we choose between an implementation partner and an assessor?

Choose the implementation partner to build and evidence the configuration controls, and choose an independent assessor to test them. Only an independent assessor issues assessment results. An implementation partner prepares systems, scripts, baselines and evidence, and its work does not count as an assessment. Compare candidates on written scope, named deliverables, the evidence they hand over, and their experience with your operating systems and cloud or Kubernetes platforms. For the assessor, confirm its qualifications and whether it has a conflict with the partner. Ask each party to describe its role in the same document so responsibilities do not overlap.

How to choose a partner for CM-6 automation work

Automating CM-6 touches the system, the evidence and the assessment at once, so the people you hire need clear roles. The cards below separate the party that builds the controls from the party that tests and attests them, and list what to request in writing before work starts.

Separate builder from assessor

An implementation partner configures systems, applies SCAP or policy content and prepares evidence. Only an independent auditor, assessor or certification body issues findings or attestations. Ask each bidder to state in writing which of these roles it covers, and confirm that your assessor is not the same firm that wrote your baselines. Your organization still owns the CM-6 settings and the deviation approvals.

Require a written scope

Ask for a scope that names the systems, operating system versions, the chosen baseline profile and the number of hosts or clusters in each environment. The document should list deliverables such as the tailored profile, the remediation playbooks, the scan schedule and the evidence pack, along with the dates agreed for each. Fixed-scope agreements make it clear what you are paying for and what happens when a change request arrives.

Check platform experience

Ask which platforms the partner has hardened with OpenSCAP and ComplianceAsCode content, whether it has deployed Wazuh configuration assessment, and how it has used Kyverno policy reports on Kubernetes. Ask for the specific distribution versions involved and how custom rules were validated. A general claim of Linux experience does not show that the team can tune a profile without breaking production services.

Request sample content and evidence

Before signing, ask to see a sample XCCDF or OVAL result, a Wazuh policy extract and a Kyverno PolicyReport from a comparable environment, with any client data removed. Check whether the results show the rule identifiers, pass or fail status and remediation text an assessor will need. Request the format of the evidence pack, including how scan results are versioned and how deviations are recorded.

Confirm who attests

Ask the partner to confirm in writing that it will not issue an audit report, assessment result or authorization decision on your behalf. Confirm that your independent assessor will test CM-6 and its enhancements using the SP 800-53A procedures and will receive the evidence directly from you. Ask how the partner will support questions from that assessor after the engagement closes.

Plan for ongoing support

Ask what the partner does after handover: updating content when new releases are published, retesting after operating system upgrades and reviewing deviations each cycle. Ask whether these tasks are included in the fixed scope or sit under a separate retainer, and what triggers a new quote. Recurring work tends to cost more over time than the initial hardening, so it should appear in the proposal.

How DeployOpen scopes and prepares CM-6 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the configuration baselines, scanning content and evidence pipelines that CM-6 work depends on. Your organization keeps ownership of its controls, while DeployOpen prepares the systems and evidence for an independent assessor to review.

How we scope

Written scope lists which systems, operating systems and Kubernetes clusters fall under the CM-6 baseline.
Agreed deliverables name the selected SCAP profiles, Wazuh policies and Kyverno policy sets before work starts.
Scope records which deviations you approve and who in your organization owns each approval decision.

How we build

Configuration content is built from ComplianceAsCode and tailored to the settings your organization has documented.
OpenSCAP scans, Wazuh configuration assessments and Kyverno policy reports are wired to run on a repeatable schedule.
Test runs confirm that scans fail on deliberate misconfigurations before the pipeline is treated as ready.

How we hand over

Handover includes the configuration baseline documents, policy source files and scan configuration in version control.
Sample ARF, XCCDF and HTML reports and Kyverno PolicyReport output are delivered as examples of the evidence produced.
Runbooks describe how to rerun assessments, review failed rules and record approved deviations for the assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover updates to SCAP content and policy sets when the baseline or platform versions change.
Confirm with DeployOpen in writing which assessor-facing questions support covers and which remain with your team.