CM-8(6): Assessed Configurations and Approved Deviations

To meet the cm-8(6): assessed configurations and approved deviations requirement, your system component inventory must record (1) the assessed/approved configuration baseline for each component and (2) any approved deviations from what is currently deployed. Operationalize it by linking each asset record to its configuration assessment results and to formally approved exceptions with owner, scope, and expiry. ¹

Key takeaways:

• Your inventory must show “what it should look like” (assessed baseline) and “how it actually differs” (approved deviations), per component. ¹
• Approved deviations are not informal waivers; they require traceable authorization, scope, and lifecycle control tied back to the inventory.
• Auditors will test completeness and traceability: asset ↔ baseline ↔ assessment evidence ↔ exception approval ↔ current state.

CM-8 is the NIST SP 800-53 control family anchor for system component inventory. Enhancement CM-8(6) tightens what “inventory” means: it is not enough to list components and owners. Your inventory must also carry configuration intelligence that proves you know what configuration was assessed for that component and where you have allowed deviations from the deployed state. The regulatory text is short, but the operational work spans configuration management, vulnerability management, change control, and GRC evidence discipline.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat CM-8(6) as a data-model requirement: every component record in inventory needs fields (or linked records) for (a) assessed configuration identifier and assessment date/result, and (b) approved deviation(s) with approval metadata and review/expiration. Once those links exist, you can drive repeatable reporting for assessors and stop “spreadsheet exception hell,” where exceptions live in email threads and can’t be reconciled to assets.

This page gives requirement-level implementation guidance you can hand to control owners and then audit for evidence without guesswork, aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

Text (CM-8(6)): “Include assessed component configurations and any approved deviations to current deployed configurations in the system component inventory.” ¹

What the operator must do

You must ensure the system component inventory contains, for each component:

1. Assessed component configuration: the configuration baseline or specification that was assessed/authorized (for example, an image version, hardening baseline revision, or configuration profile ID), and
2. Approved deviations: any formally approved exceptions from the current deployed configuration state, recorded in a way that is traceable and reviewable. ¹

In plain terms: if you cannot show an assessor “this server was assessed against baseline X, and here are the approved deviations from what’s deployed,” you are not meeting CM-8(6).

Plain-English interpretation of the requirement

CM-8(6) turns your inventory into a configuration accountability register. An asset list that only tracks hostname, owner, and location is incomplete under this enhancement. You need to capture:

• The assessed configuration (what your security team says is acceptable and was evaluated), and
• The exception record when reality differs from that assessed configuration, including explicit approval. ¹

A practical way to interpret “assessed configuration” is: the baseline you would present during an assessment to justify the component’s security posture (hardening standard, gold image, configuration profile, or desired-state policy set). A practical way to interpret “approved deviation” is: a time-bound, scoped exception that explains why a component is not in the assessed baseline state.

Who it applies to (entity and operational context)

This requirement applies most directly to:

• Federal information systems implementing NIST SP 800-53 controls, and
• Contractor systems handling federal data where 800-53 alignment is contractually required (for example, via an agency ATO boundary or security requirements in an agreement). ¹

Operational contexts where CM-8(6) becomes high-friction:

• Hybrid environments where CMDB, endpoint tools, and cloud inventories disagree.
• Teams with “standard build” documentation but no machine-readable baseline mapping per asset.
• Exception processes that exist in policy but are not tied to inventory records.

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

Step 1: Define the inventory system of record and scope

Decide what system is authoritative for your component inventory (CMDB, asset management platform, cloud asset inventory, or a federated inventory with reconciliation rules). Then define the component types in scope (servers, endpoints, network devices, containers, managed databases, SaaS configurations, etc.) consistent with your system boundary.

Operator tip: You can meet CM-8(6) with federated sources, but only if you can produce one joined view per component: component → assessed configuration → approved deviations.

Step 2: Establish what counts as an “assessed configuration”

Create a controlled list of configuration baselines that can be referenced from inventory records. Examples:

• Gold image IDs for workstation and server builds
• CIS-aligned hardening baseline revisions (if used internally)
• Cloud policy bundles (desired-state policies) and their versions
• Network device standard configs by model/role

Minimum data fields for an assessed configuration record:

• Baseline/config name and unique identifier
• Version/revision
• Where it is stored (repo path, policy-as-code location, config management reference)
• Assessment date and result status (pass/conditional/failed) tied to your assessment process

You do not need every knob and setting embedded in the inventory entry. You need a durable pointer to the assessed baseline plus proof it was assessed.

Step 3: Add deviation tracking to the inventory data model

Extend inventory records to support one-to-many deviations per component. Each deviation entry should include:

• Deviation description (what differs and why)
• Risk statement (plain language, specific to the deviation)
• Compensating controls (if any)
• Approver name/role (and approval ticket/reference)
• Approval date
• Scope (component, time window, environment)
• Review cadence or expiration trigger (event-driven is acceptable if defined)
• Status (active, expired, remediated)

CM-8(6) requires that approved deviations are included in the inventory. ¹ If exceptions live only in a separate GRC module, you still need a direct link from the asset record to the exception record.

Step 4: Reconcile “current deployed configuration” to the assessed baseline

Implement a way to compare deployed state to baseline. This can be done through:

• Configuration management tooling (desired state reporting)
• Endpoint management compliance reports
• Cloud configuration posture management output
• Network configuration compliance checks

Your goal is not perfect real-time accuracy. Your goal is consistent detection of drift and a workflow that either:

• Remediates drift back to baseline, or
• Creates/updates an approved deviation record tied to the component inventory.

Step 5: Create an exception approval workflow that produces inventory-ready records

Define the workflow stages and required approvals. Keep it simple:

1. Request deviation (component + baseline + deviation description)
2. Security review (risk and compensating controls)
3. Approval (named authority)
4. Implementation verification (deviation exists as described)
5. Review/closure (remediate or renew)

Make the workflow output structured data that can be attached to the asset record. If you use Daydream, set CM-8(6) to a named control owner and configure recurring evidence requests so your exceptions and baseline mappings are collected in a consistent format across teams.

Step 6: Operate the control with recurring checks

Run periodic reconciliation:

• Inventory completeness (components missing baseline mapping)
• Drift without approved deviation
• Deviations past review/expiry
• Baselines that changed but inventory mappings did not

Tie findings to change management: changes that affect baseline or deviations should update the inventory record as part of the change closure criteria.

Required evidence and artifacts to retain

Assessors look for traceability more than volume. Keep:

• System component inventory export showing, per component: baseline reference and deviation link(s). ¹
• Configuration baseline catalog (list of approved/assessed baselines with versions and storage location).
• Assessment records proving the baseline was assessed (scan results, configuration compliance reports, or documented assessment outcomes).
• Deviation approvals (tickets/workflow records) showing approver, rationale, scope, and disposition.
• Drift detection outputs (reports/screenshots/exports) and the remediation or exception decision trail.
• Procedures: configuration assessment procedure, deviation approval procedure, and inventory update procedure.

Practical evidence test: pick a random component from your inventory and produce its baseline, last assessment evidence, current drift status, and any approved deviations in one thread.

Common exam/audit questions and hangups

Expect these questions:

• “Show me how an asset record indicates the assessed baseline for that component.”
• “How do you detect configuration drift, and what happens when drift is found?”
• “Show me deviations for this component and the approvals.”
• “Who can approve deviations, and how do you prevent indefinite exceptions?”
• “How do you ensure the inventory is complete for cloud-native components (containers, managed services)?”

Common hangup: teams confuse “approved deviation” with “known issue.” An issue is not a deviation unless it is explicitly approved and recorded against the component inventory. ¹

Frequent implementation mistakes and how to avoid them

Mistake 1: Inventory has baselines at a fleet level, not per component

Fix: store baseline mapping at the component record or enforce inheritance rules that are machine-verifiable (for example, tag-based inheritance) and can be exported per component.

Mistake 2: Exceptions are approved but not tied to specific assets

Fix: require asset IDs (or cloud resource IDs) as mandatory fields in exception requests. No ID, no approval.

Mistake 3: Deviations never expire and are not revisited

Fix: implement an explicit review trigger (time-based or event-based). Make renewal a conscious decision with updated risk context.

Mistake 4: “Assessed configuration” is a PDF that no one can map to reality

Fix: treat the baseline as a versioned artifact with a stable identifier and a link to how it is enforced (policy-as-code, MDM profile, configuration management state).

Mistake 5: Drift detection exists, but the workflow does not produce auditable records

Fix: define closure criteria that update inventory fields and attach evidence (report snapshots, ticket IDs). Daydream-style recurring evidence collection helps stop last-minute evidence hunts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-8(6). Your practical risk is assessment failure or ATO friction: if you cannot demonstrate traceable configuration baselines and approved deviations at the inventory level, assessors typically treat it as weak configuration governance. That exposure increases the chance of unmanaged configuration drift, which can turn into exploitable conditions and delayed incident response because teams cannot quickly answer “what’s different and why.”

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Assign a CM-8(6) control owner and RACI across CMDB/IT, Security Engineering, and GRC.
• Identify inventory system of record and define in-scope component classes for the system boundary.
• Define baseline identifiers and a minimum baseline catalog format (name, version, location, assessment reference).
• Draft the deviation record template (fields listed above) and approval authority.

Days 31–60 (build and connect)

• Add baseline and deviation fields/links to the inventory (or implement a joinable mapping table).
• Pilot drift-to-deviation workflow on a limited set of components (one environment or one platform).
• Establish evidence capture: inventory exports, baseline catalog, sample deviation approvals, and drift reports stored in an audit-ready location.

Days 61–90 (operate and prove)

• Expand to remaining component classes and enforce “no baseline mapping, no production” for new builds where feasible.
• Run a reconciliation cycle and remediate: missing baseline links, unapproved drift, stale deviations.
• Conduct a tabletop audit: sample components and walk the traceability chain end-to-end; document gaps and fix.

Frequently Asked Questions

What exactly counts as an “assessed configuration” for CM-8(6)?

It is the specific baseline or configuration profile you evaluated and accepted for that component, recorded with a stable identifier and version. The inventory must reference that assessed baseline for each component. ¹

Can approved deviations live in a GRC tool instead of the CMDB?

Yes, if each component inventory record includes a direct link or reference to the approved deviation record. CM-8(6) is an inventory inclusion requirement, so the relationship must be traceable from the inventory. ¹

How do we handle ephemeral assets like containers or auto-scaled instances?

Track baselines and deviations at the template level (image, launch template, IaC module) and ensure the inventory can map running instances back to that assessed configuration source. Record deviations against the template or control plane object when that is the true “component” in your boundary.

What if drift is detected but we plan to fix it soon; do we still need an approved deviation?

If the deployed configuration differs from the assessed configuration, you either remediate quickly through normal change control or document an approved deviation for the period it remains out of baseline. The key is that unapproved variance should not persist without traceability. ¹

Who should be allowed to approve deviations?

Set an approval authority aligned to risk ownership (often the system owner with security review). Auditors care that approvals are explicit, attributable, and consistent, not that a specific title approves every deviation.

What evidence is most persuasive to an assessor?

A component inventory export that shows baseline IDs and deviation links, plus a sampled set of records where you can open the baseline artifact, show assessment output, and show the approved deviation with scope and status. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5