CM-3: Configuration Change Control

CM-3 requires you to define which system changes must be controlled and to document that decision so changes to high-impact configuration items cannot happen informally. Operationalize it by building a clear “configuration-controlled change” scope, enforcing it through your change workflow, and retaining repeatable evidence that approvals and implementation match the documented scope. ¹

Key takeaways:

• Document a specific list of change types that are configuration-controlled, tied to your system boundaries and risk.
• Bind those change types to a real workflow (request, review, approval, test, implement, record) so teams cannot bypass control.
• Keep assessor-ready artifacts: scope statement, change logs, approvals, implementation records, and exceptions.

CM-3: configuration change control requirement is easy to misunderstand because many teams think “we have Jira tickets” equals change control. CM-3 is narrower and more testable: you must determine and document the types of changes to the system that are configuration-controlled. That means you decide, in writing, which changes require formal control (review/approval/traceability) and which are routine or pre-approved.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to convert CM-3 into two deliverables: (1) a scoped list of controlled change types aligned to your system inventory and baseline configurations, and (2) evidence that those change types actually flow through an enforced process. Auditors rarely fail teams because a process document is missing; they fail teams because scope is vague (“all significant changes”), because the workflow does not match reality (direct-to-prod changes), or because evidence is incomplete.

This page gives requirement-level implementation guidance you can put in place quickly: applicability, a step-by-step procedure, the artifacts to retain, common audit questions, and a practical execution plan. The regulatory anchor is NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (CM-3): “Determine and document the types of changes to the system that are configuration-controlled;” ¹

Operator meaning: You must produce a documented decision on which categories of changes require configuration change control for the system in scope. An assessor should be able to read your documentation and answer, without interpretation, “Which changes must follow formal change control here?”

What the operator must do:

1. Determine (decide) the change types that matter for your system’s confidentiality, integrity, availability, and compliance commitments.
2. Document them in a durable place (policy standard, system security plan appendix, configuration management plan, or equivalent), including examples and boundaries.
3. Make the documentation operational by aligning the workflow and evidence to the declared change types, so the documentation is not aspirational.

Plain-English interpretation

CM-3 is a scoping control. You are drawing a line between:

• Configuration-controlled changes: must be requested, reviewed, approved, implemented in a controlled way, and recorded.
• Non-controlled changes: may be routine (for example, certain operational tasks) or covered by a standing/pre-approval, but still need guardrails.

If you do not document the scope, you cannot prove consistent control. If you document it vaguely, you create audit risk and operational confusion.

Who it applies to

Entity types: Federal information systems and contractor systems handling federal data commonly implement CM-3 as part of NIST SP 800-53 alignment. ¹

Operational context (where CM-3 shows up in real life):

• Cloud infrastructure (IaaS/PaaS) changes: IAM, networking, encryption, logging, key management.
• Application and service changes: releases, feature flags, dependency updates, configuration toggles.
• Endpoint/server configuration: hardening, agents, patches with security impact.
• Third party and managed services: changes the third party makes that affect your system boundary or shared responsibility controls.

Systems in scope: Apply CM-3 to each defined system boundary you manage. If you have multiple environments (dev/test/prod), document how the control applies differently by environment (for example, stricter in production).

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

Step 1: Name the control owner and enforcement points

Assign a single accountable owner (often Head of IT Ops, Platform Engineering, or Security Engineering) and document supporting roles (Change Advisory Board, approvers, release managers). Map where enforcement happens:

• Ticketing/change system (workflow gates)
• Source control (pull request approvals)
• CI/CD (required checks)
• Cloud policy (preventive controls)

Practical tip: auditors accept “multiple tools” if you can show one coherent workflow and traceability across tools.

Step 2: Define “types of changes that are configuration-controlled”

Create a table that is explicit and testable. Example starter scope:

Change type	Examples	Must be configuration-controlled?	Notes / approval rule
Identity and access	IAM roles, MFA settings, privileged group membership	Yes	Security approval required
Network/security boundaries	Firewall rules, security groups, ingress/egress policies	Yes	Security + service owner
Crypto and keys	KMS key policies, TLS settings, rotation procedures	Yes	Security approval required
Logging/monitoring	Turning off audit logs, changing retention, SIEM routing	Yes	Security approval required
Production deployments	Release to prod, rollback, hotfix	Yes	Change ticket + PR required
Baseline configs	Hardening baseline, golden images, agent installs	Yes	Document baseline versioning
Routine ops	User provisioning (non-privileged), disk expansion within limits	Maybe	Define pre-approval criteria

Your final list must reflect your architecture. The CM-3 pass/fail hinge is whether your documented types cover the changes that could materially alter the system’s security posture.

Step 3: Publish the scope in an assessor-friendly document

Pick one “source of truth” and link out:

• Configuration Management Plan (preferred for engineering teams)
• System Security Plan section or appendix
• Configuration control standard

Minimum content:

• System name/boundary
• List of configuration-controlled change types
• Examples and exclusions
• Emergency change handling approach (even if brief)
• Where evidence lives (ticket system, Git, CI logs)

Step 4: Bind the scope to your change workflow

Your workflow must enforce that configuration-controlled change types cannot bypass review. Common implementation patterns:

• Ticket-first: every controlled change starts with a change request ticket, then links to PRs and deployment records.
• PR-first with ticket link: controlled changes require a ticket reference in PR template plus required reviewers and checks.
• Pipeline gates: CI/CD denies deploy unless required approvals and test evidence are present.

Define required workflow fields for controlled changes:

• Change type (from your CM-3 table)
• Risk impact (low/med/high, or descriptive)
• Planned implementation window
• Test plan / validation steps
• Backout plan
• Approvers

Step 5: Implement a clean exception path (especially for emergencies)

Emergency changes happen. CM-3 survives audits when emergencies are:

• Clearly labeled
• Approved by the right role (even if after-the-fact)
• Retrospectively reviewed with corrective actions
• Not used as the default path

Add an “emergency change” category in your change system and require a post-implementation review record.

Step 6: Prove it with sampling-ready evidence

Run a monthly or quarterly self-check:

• Pull a sample of production changes
• Confirm each maps to a documented change type
• Confirm required approvals, tests, and implementation records exist
• Track exceptions and remediation

This closes the loop between “documented types” and actual operations.

Step 7: Operationalize with ownership, procedure, and recurring artifacts

A reliable way to keep CM-3 from drifting is to explicitly map: control owner → procedure → recurring evidence artifacts. Daydream is often used here as the system to map CM-3 to an owner, attach the implementation procedure, and schedule evidence pulls so you can answer audits without a scramble. ¹

Required evidence and artifacts to retain

Keep artifacts in a way that supports point-in-time reconstruction for an audit sample.

Design-time (static) artifacts

• CM-3 scope statement: “types of changes that are configuration-controlled” document
• Roles and responsibilities (RACI or equivalent)
• Change workflow diagram or written procedure
• Definitions: standard change vs normal change vs emergency change

Run-time (dynamic) artifacts

• Change request records for controlled change types (tickets)
• Approval evidence (ticket approvals, CAB minutes, PR reviews)
• Testing/validation evidence (CI results, test checklist completion)
• Implementation evidence (deployment logs, change completion notes)
• Post-implementation review records for emergencies
• Exception register and remediation actions

Traceability expectation: For any sampled change, you should be able to connect ticket → PR → pipeline/deploy → validation → closure.

Common exam/audit questions and hangups

Expect assessors to probe gaps between documented scope and actual practice.

1. “Show me your documented types of configuration-controlled changes.”
   Hangup: teams provide a generic policy with no change type list.

2. “How do engineers know which path to use?”
   Hangup: no decision tree; engineers guess.

3. “Show evidence for a sample of changes.”
   Hangup: approvals live in chat; tickets lack links to code/deploy.

4. “How do you handle emergency changes?”
   Hangup: emergency path exists but has no retrospective review evidence.

5. “Do third parties make changes that affect this system?”
   Hangup: no visibility into MSP/SaaS configuration changes that alter security settings.

Frequent implementation mistakes and how to avoid them

• Mistake: Writing “all changes are controlled” with no taxonomy.
  Fix: publish specific change types with concrete examples and exclusions.

• Mistake: Controlling code changes but not configuration changes.
  Fix: include IAM, network, logging, encryption, and environment configuration in controlled types.

• Mistake: Manual approvals outside the system of record.
  Fix: require approvals in the ticketing/PR system; treat chat approvals as non-evidence.

• Mistake: “Emergency” becomes the default.
  Fix: add thresholds, require post-implementation review, and trend emergency usage.

• Mistake: No owner, no cadence.
  Fix: assign an owner and perform periodic sampling with documented results.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources, so this page does not cite enforcement examples.

Risk still exists even without named cases. Poor change control increases the likelihood of unauthorized changes, outages, security control degradation (for example, reduced logging), and weak incident reconstruction. For federal and federal-adjacent programs, CM-3 gaps can also become assessment findings because the requirement is explicit and evidence-based. ²

Practical execution plan (30/60/90)

You asked for speed. Use these phases as an execution plan; adapt to your delivery model.

First 30 days (stabilize scope and ownership)

• Assign control owner and define approver roles for high-impact change types.
• Draft the CM-3 “configuration-controlled change types” table for the system boundary.
• Choose the system of record for change evidence (ticketing + source control links).
• Update templates: change request form fields and PR template require “change type” selection and ticket link.

Next 60 days (bind to workflow and generate evidence)

• Implement workflow gating: required reviewers and required checks for controlled change types.
• Roll out an emergency change path with retrospective review.
• Run a pilot evidence pull: sample recent production changes and build a traceability packet.
• Capture gaps as issues (missing links, missing approvals, unclear categorization) and fix them.

Next 90 days (operate and prove repeatability)

• Formalize recurring self-assessment sampling and document results.
• Train engineering and operations leads on the change type decision tree.
• Tune the controlled change list based on real exceptions and near-misses.
• Centralize control mapping, procedures, and recurring evidence artifacts in Daydream so audits become retrieval work, not archaeology. ¹

Frequently Asked Questions

What counts as a “type of change” for CM-3?

Treat “type” as a repeatable category that maps to risk and workflow steps, like IAM changes, network rule changes, logging configuration changes, or production releases. The key is that a reviewer can consistently classify a change without debating semantics. ¹

Do we need a formal Change Advisory Board (CAB) to meet CM-3?

CM-3 does not require a CAB by name. You need documented change types and a consistent review/approval mechanism that matches those types and produces evidence. ¹

We deploy multiple times per day. How do we avoid CM-3 becoming a bottleneck?

Use standard changes and automation: pre-approve low-risk, well-tested change types, then enforce required checks in CI/CD and PR review. Keep higher-risk change types on a stricter approval path.

Are configuration-controlled changes only production changes?

Production is the common focus, but CM-3 applies to “the system” in scope. Document how the requirement applies by environment, and include non-prod changes when they can affect security posture or propagate into production.

How should we handle third-party-managed infrastructure changes?

Document which third party changes are configuration-controlled from your perspective (for example, changes to tenant security settings) and require a record of change notices, approvals, or attestations. Make sure those records are retrievable alongside your internal change evidence.

What’s the minimum evidence set to satisfy an auditor quickly?

Provide the documented list of controlled change types, your workflow/procedure, and a small sample of recent controlled changes showing request, approval, implementation, and closure records with traceable links.

Footnotes

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

2. NIST SP 800-53 Rev. 5