CM-6(2): Respond to Unauthorized Changes

To meet the cm-6(2): respond to unauthorized changes requirement, you must define what systems/configuration items are in scope, detect unauthorized configuration changes, and take predetermined actions (contain, revert, investigate, document, and prevent recurrence). Operationalize it by wiring change detection into incident response with clear decision criteria, owners, and evidence. ¹

Key takeaways:

• Predefine “unauthorized change” and the required response actions, then make teams follow them every time. ¹
• Tie configuration monitoring to incident handling: triage, rollback, root cause, and corrective action must be repeatable and logged. ²
• Auditors look for proof: alerts, tickets, approvals, rollback records, and post-incident learnings mapped to assets. ²

CM-6(2) is a configuration management enhancement focused on what happens after a configuration change occurs outside your approved change control. You can have strong baselines and change approvals and still fail CM-6(2) if unauthorized changes are detected but handled inconsistently, informally, or without evidence.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CM-6(2) is to treat unauthorized changes as a defined event type with mandatory response steps, the same way you treat malware detections or privileged access anomalies. You are building a closed loop: detect, validate, respond, recover, and improve.

This requirement becomes high-friction in hybrid environments (cloud + on-prem), where “change” can occur through infrastructure-as-code, consoles, emergency break-glass accounts, third-party managed services, or automated scaling. Your job is to translate CM-6(2) into: (1) unambiguous scope, (2) a playbook with decision points, (3) system integrations that produce audit-ready artifacts, and (4) recurring review so the response stays reliable as systems evolve. ²

Regulatory text

NIST CM-6(2) (Respond to Unauthorized Changes): “Take the following actions in response to unauthorized changes to {{ insert: param, cm-06.02_odp.02 }}: {{ insert: param, cm-06.02_odp.01 }}.” ¹

What the operator must do with this text

The OSCAL excerpt uses organization-defined parameters (ODPs). That means you must fill in two blanks in your control implementation:

1. What configuration items are covered (the “unauthorized changes to [scope]” part).
2. Which actions you will take when unauthorized changes occur (the “take the following actions” part).
   Assessors will test that your written ODPs match real operations: alerts trigger tickets, actions occur within your defined workflow, and you retain evidence. ¹

Plain-English interpretation (requirement intent)

CM-6(2) requires a standard, documented, repeatable response when someone or something changes a configuration without authorization. “Respond” means more than noticing. You must (a) validate whether the change is truly unauthorized, (b) contain impact, (c) restore an approved state, (d) investigate how it happened, and (e) prevent recurrence through corrective action.

This is a control about operational discipline and traceability. The quickest way to fail is to treat these as “ops noise” handled in chat, with no ticket, no rollback record, and no root-cause follow-up. ²

Who it applies to (entity and operational context)

Entity types (common applicability):

• Federal information systems
• Contractor systems handling federal data (including many service providers supporting federal workloads) ¹

Operational contexts where CM-6(2) shows up most:

• Production infrastructure (cloud accounts/subscriptions, hypervisors, network devices)
• Identity and access systems (directory services, SSO settings, conditional access rules)
• Security tooling configurations (EDR policies, SIEM routing, firewall rules)
• CI/CD and infrastructure-as-code pipelines (pipeline definitions, deployment policies)
• Third-party managed environments (MSP-managed networks, SaaS admin consoles)

If a third party can change your configuration (managed services, SaaS admin, outsourced DevOps), CM-6(2) still expects your program to respond consistently, even when the change occurred outside your direct tooling. Contracting does not remove accountability; it changes how you detect and collect evidence. ²

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

Step 1: Define the two ODPs (scope and actions)

Create a CM-6(2) control appendix with two fields:

ODP A — In-scope configuration items

• Critical servers and endpoints (or all production compute)
• Network security controls (firewalls, WAF, security groups)
• Identity policy objects (MFA enforcement, privileged role assignments)
• Logging/monitoring configurations
• Application runtime configs that affect security (encryption flags, debug mode)

ODP B — Required response actions Use a fixed set of actions your teams must perform. A practical minimum set:

1. Triage and validate (false positive vs unauthorized change)
2. Contain (disable offending account/token, stop automation, isolate host if needed)
3. Revert or remediate to an approved baseline (rollback change, redeploy approved template)
4. Record and escalate (ticket, severity, notifications)
5. Investigate root cause (how change occurred, what access path was used)
6. Corrective action (policy update, IAM fix, pipeline guardrail, training, vendor action)
7. Close with approvals (security sign-off for closure on high-impact changes)

Write these as “must” statements, not suggestions. Assessors will look for determinism. ¹

Step 2: Connect detection to response (tooling to workflow)

You need a reliable way to detect change drift and route it into a response workflow:

• Detection sources: configuration monitoring, file integrity monitoring, cloud configuration change logs, privileged access monitoring, endpoint configuration drift tooling.
• Workflow: your ITSM/ticketing system or incident platform becomes the system of record.

Minimum operational pattern:

• Alert generates a ticket with asset, change details, actor (if known), and timestamp.
• Ticket template forces responders to choose: “authorized” (link to approval) or “unauthorized” (trigger response checklist).
• Unauthorized path forces rollback plan and root cause fields before closure.

Step 3: Build a decision matrix that responders can follow

Create a one-page matrix for common change types:

Change type	Validation question	Default action	Escalation
Firewall/security group opened to public	Is there an approved change record?	Revert immediately; capture evidence	Security incident if exposure occurred
IAM privileged role granted	Was it approved and time-bound?	Remove role; rotate credentials	Notify IAM owner + Security
Logging disabled or routing changed	Was there a maintenance window approval?	Restore logging; preserve logs	Treat as high severity for investigation
Server baseline drift	Did automation apply an approved patch?	Redeploy known-good baseline	Escalate if repeated drift

The point is consistency. The matrix prevents “it depends” decisions that don’t stand up in audits.

Step 4: Implement rollback and “known-good state” mechanics

Response is hard without a safe restore method:

• Golden images, baseline templates, configuration-as-code, or approved configuration snapshots.
• Document who can execute rollback and under what approvals (especially for production).

Common examiner hangup: you detected unauthorized change but left the environment in a questionable state because rollback was “too risky.” Your CM-6(2) design should include a safe remediation path for high-risk assets. ²

Step 5: Add recurrence prevention and governance

Unauthorized changes should produce improvements:

• Access path fixes (remove standing admin, enforce MFA, tighten service principals)
• Change control tuning (emergency change procedure with retroactive approval)
• Monitoring rule improvements (reduce false positives, add context)
• Third-party corrective actions (contractual requirements, reporting SLAs)

Track trends in a recurring forum (security operations review, change advisory board). CM-6(2) is easier to defend when you can show learning, not just firefighting.

Step 6: Assign ownership and produce recurring evidence

At minimum define:

• Control owner (often Security GRC + Configuration Management lead)
• Operators (SecOps, IT Ops, CloudOps, IAM)
• Approvers (system owners, security owner)
• Evidence cadence (continuous collection, periodic review)

If you use Daydream, treat it as the place where you map CM-6(2) to a named control owner, the exact procedure, and the recurring evidence set, then track collection status and exceptions without chasing screenshots at audit time. ¹

Required evidence and artifacts to retain

Keep evidence that proves: detection happened, response followed your ODP actions, and closure was authorized.

Core artifacts

• CM-6(2) procedure/playbook with the two ODPs (scope + response actions) ¹
• Configuration monitoring/detection rule set or control description (what generates unauthorized change events)
• Tickets/incidents for a sample of unauthorized change events:
  • Alert payload (what changed, when, where, actor)
  • Validation notes (why unauthorized)
  • Containment actions taken
  • Rollback/remediation record
  • Root cause analysis
  • Corrective action and closure approval
• Change management records that show the “authorized vs unauthorized” distinction (approvals, emergency changes with retroactive review)
• Access logs or privileged session evidence supporting the investigation

Nice-to-have artifacts

• Metrics dashboard (counts are fine internally, but don’t claim industry benchmarks without a source)
• Post-incident review notes for major events
• Third-party notifications and remediation commitments when changes were introduced by a provider

Common exam/audit questions and hangups

Expect these questions (and prepare crisp, documented answers):

1. “Define ‘unauthorized change’ for your environment.” Show the written criteria and how you handle emergency changes. ²
2. “Show me evidence for the last few unauthorized changes.” Have tickets ready with end-to-end actions and approvals.
3. “How do you know your detection covers your in-scope assets?” Be ready with an inventory mapping or monitoring coverage statement.
4. “What happens if rollback is risky?” Demonstrate an alternate remediation path and risk acceptance process tied to an approver.
5. “How do third parties fit?” Provide contract language, notification processes, and how you ingest their change logs or attestations.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating unauthorized changes as normal incidents without configuration context.
  Fix: Add a CM-6(2) checklist to incident templates and force linkage to the baseline/change record.

• Mistake: Undefined scope (“all systems”) with no monitoring reality.
  Fix: Start with a defensible scope (critical production + security tooling + IAM), then expand as coverage improves.

• Mistake: Detection exists, but actions are ad hoc.
  Fix: A short decision matrix plus a mandatory rollback/investigation workflow beats a long policy.

• Mistake: No proof of closure approval or corrective action.
  Fix: Make closure fields required: approver, corrective action, and recurrence prevention notes.

• Mistake: Third-party changes fall into a blind spot.
  Fix: Require third-party change notifications, align on logs you receive, and test the process with a tabletop scenario. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CM-6(2) primarily as an assessment and contractual compliance risk, plus an operational risk. The real impact shows up as: expanded attack surface, weakened monitoring (if logs are disabled), privilege escalation through unauthorized IAM changes, and inability to prove control operation during incident reviews. ²

Practical 30/60/90-day execution plan

First 30 days (establish the minimum compliant loop)

• Name the CM-6(2) control owner and responders; document RACI.
• Define ODP scope and ODP response actions in a one-page standard.
• Update incident/ticket templates to include “unauthorized configuration change” classification and required fields.
• Identify your top detection sources and route alerts to the ticketing system with enough context for triage. ¹

By 60 days (prove repeatability)

• Publish the decision matrix and rollback guidance for top asset classes (IAM, network controls, logging).
• Run a tabletop: simulate an unauthorized firewall rule change and test the ticket workflow end-to-end.
• Collect evidence samples and store them in a dedicated audit folder or GRC system record with consistent naming.
• Add third-party touchpoints: define notification channels and required information when they make admin changes. ²

By 90 days (scale and harden)

• Expand monitoring coverage to additional systems in scope; document gaps and compensating controls.
• Add recurrence prevention tracking (corrective actions with owners and due dates).
• Implement periodic review of unauthorized change events to tune detection and reduce repeat failures.
• In Daydream, map CM-6(2) to the owner, procedure, and recurring evidence artifacts so audit prep becomes retrieval, not reconstruction. ¹

Frequently Asked Questions

What counts as an “unauthorized change” under CM-6(2)?

Any configuration change to your defined in-scope items that was not approved through your change process or does not meet your documented emergency change criteria. You must write the definition as an organization-defined parameter and apply it consistently. ¹

Do false positives from config monitoring fail the control?

No, but you need evidence that you triaged the alert, determined it was authorized or benign, and closed it with traceability. Repeated false positives become an operational risk because responders stop treating alerts as actionable. ²

How do we handle emergency changes that bypass normal approvals?

Define an emergency path: who can approve, what documentation is required, and how quickly you require retroactive review and normalization to baseline. Auditors will accept emergency handling if it is documented and evidenced. ²

We use infrastructure-as-code; do we still need CM-6(2) response steps?

Yes. IaC reduces drift, but unauthorized changes still occur through console edits, compromised credentials, or pipeline tampering. Your response should include restoring the approved code state and investigating the access path. ²

How does CM-6(2) apply when a third party administers the system?

You remain accountable for the response. Require the third party to report unauthorized changes, provide logs or tickets, and support rollback and root cause analysis under defined timelines in the contract or operating procedure. ²

What’s the minimum evidence set to keep auditors out of the weeds?

A written CM-6(2) procedure with scope and response actions, plus a small sample of completed unauthorized-change tickets showing detection, rollback/remediation, investigation, and closure approval. Evidence should be tied to specific assets and timestamps. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5