CM-9: Configuration Management Plan

To meet the cm-9: configuration management plan requirement, you must create, approve, and run a system-specific Configuration Management Plan (CMP) that defines how you identify, control, review, and document configuration changes across the system lifecycle. The CMP must be more than a policy; auditors expect it to drive real workflows, tooling, and retained evidence. ¹

Key takeaways:

• CM-9 requires a documented plan plus operational execution and proof, not a generic “configuration management policy.” ¹
• Your CMP should tie together baselines, change control, roles, tools, and records for one specific system boundary. ²
• The fastest path to audit readiness is mapping CM-9 to a named owner, procedures, and recurring evidence artifacts. ¹

CM-9 sits in the Configuration Management (CM) family and forces a simple outcome: you can explain, in writing, how the system’s configuration is established, changed, verified, and kept under control, and you can prove you follow that plan. NIST’s text is short, but the expectation is operationally heavy because CM-9 becomes the “wiring diagram” for multiple configuration practices across engineering, IT operations, security, and DevOps.

For a CCO, Compliance Officer, or GRC lead, the practical goal is to get to a CMP that is (1) system-scoped, (2) aligned to how changes actually happen in your environment, and (3) supported by evidence you can hand to an assessor without recreating history. Done well, CM-9 reduces outage risk, limits unauthorized change, and makes incident response and forensics faster because you can reconstruct what changed, when, and why.

This page gives requirement-level guidance you can implement quickly: who owns what, what to write, what workflows to enforce, what artifacts to retain, and what auditors ask when they suspect the CMP is shelfware.

Regulatory text

Excerpt (CM-9): “Develop, document, and implement a configuration management plan for the system that:” ¹

What an operator must do (requirement meaning):

• Develop: create a plan tailored to a specific system boundary (not “the enterprise”). ²
• Document: produce a controlled document with versioning, approval, and clear references to procedures and tools. ¹
• Implement: demonstrate the plan is used to run configuration management in day-to-day work, with records to prove it. ¹

NIST’s excerpt is intentionally concise; in practice, assessors look for a CMP that points to the “how” (procedures, workflows, approvals, tooling) and the “proof” (tickets, baselines, diffs, reports, meeting minutes) for that specific system.

Plain-English interpretation (what CM-9 is really asking)

Your system must have a written Configuration Management Plan that answers:

• What is the approved configuration baseline today?
• How do changes get requested, evaluated, approved, implemented, tested, and rolled back?
• Who can change what, using which tools, and with what approvals?
• How do you detect and correct drift from the baseline?
• Where are the records kept, and how do you audit them?

If you cannot consistently reconstruct configuration history (what changed, when, who approved it, and what was deployed), CM-9 will fail in an assessment even if you have strong engineers.

Who it applies to (entity and operational context)

Entity scope

• Federal information systems and contractor systems handling federal data commonly inherit or adopt NIST SP 800-53 controls, including CM-9. ²

Operational contexts where CM-9 is examined closely

• Systems with regulated data and strong change-control expectations: identity, logging, network security, endpoint management, and key SaaS platforms in the authorization boundary.
• Modern delivery models: cloud infrastructure, containers/Kubernetes, CI/CD, infrastructure-as-code, and managed services where configuration changes happen through code merges rather than manual steps.
• Environments with multiple teams touching production (engineering, SRE, IT, third parties).

Key scoping decision

• CM-9 is per system. Your enterprise change policy can support CM-9, but you still need a system-specific plan that tells an assessor exactly how configuration is controlled inside the system boundary. ²

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

Use this as a build checklist for your CMP and operating model.

1) Assign ownership and governance (make it auditable)

• Name a CMP owner (typically System Owner, IT Ops lead, or SRE manager) accountable for plan accuracy and updates.
• Name approvers (e.g., Change Advisory Board, security approver for high-risk changes).
• Define decision rights: what changes can be pre-approved/standard vs. what needs review.

Practical control hook: map CM-9 to a control owner, implementation procedure, and recurring evidence artifacts so the plan does not become a one-time document. ¹

2) Define system configuration scope and baselines

In the CMP, list baseline categories and where the baseline is stored:

• Infrastructure: cloud accounts/subscriptions, VPC/VNet, firewall rules, load balancers.
• Platforms: Kubernetes configs, container registries, secrets management.
• Hosts/endpoints: gold images, hardening standards, configuration profiles.
• Applications: runtime config, feature flags, environment variables, dependencies.
• Security tooling: EDR policies, SIEM collectors, IAM settings.

Baseline storage examples:

• Git repository (infrastructure-as-code, config-as-code).
• CMDB or asset inventory entry.
• “Golden AMI/image” definition and build pipeline records.

Deliverable: a baseline table that is system-specific and points to the authoritative source of truth.

3) Describe change control workflow end-to-end

Your CMP should include a workflow that matches reality. Auditors will compare your stated process to ticket and deployment evidence.

Minimum workflow elements to document:

• Intake: how changes are requested (ticket type, pull request template).
• Risk/impact review: criteria for security review, testing requirements, and downtime window.
• Approval: who approves; what constitutes approval (electronic sign-off, merge approval).
• Implementation: tooling used (CI/CD, config management tool), and separation of duties where applicable.
• Verification: post-deploy checks, monitoring, validation, and acceptance criteria.
• Rollback/backout: defined rollback steps and when to use them.
• Emergency changes: expedited path with after-the-fact review and documentation.

Tip that reduces audit pain: write the CMP so it references your actual systems (e.g., “ServiceNow CHG tickets + GitHub PR approvals + production deploy logs”), not generic “change requests.”

4) Control and monitor configuration drift

Implementation expectations commonly include:

• Drift detection method (CSPM policies, IaC drift checks, host compliance scanning).
• Frequency triggers (continuous where possible, or tied to deploy cadence).
• Exception handling (how you document approved deviations and compensating controls).
• Remediation SLAs as internal targets (avoid stating hard numbers unless you can meet them consistently).

5) Integrate third parties into the plan

If third parties can change your system (managed service providers, implementation partners, SaaS admins), the CMP must state:

• How third-party access is approved and time-bound.
• How their changes are requested/recorded (tickets, written work orders, PRs).
• How you review and accept their work (evidence of validation).

This is a common gap: teams treat third-party work as “outside change control,” then fail CM-9 because production changes lack your approvals and records.

6) Operationalize documentation control

Treat the CMP like a controlled compliance artifact:

• Version history and change log.
• Approval records.
• Review cadence tied to major system changes (re-architecture, new CI/CD, migration).

7) Make evidence collection automatic

Build the CMP so it points to places where evidence already exists:

• Ticketing exports for changes and approvals.
• Git logs for commits/merges tied to change records.
• CI/CD release logs.
• Configuration compliance reports.
• Meeting minutes for CAB reviews (if you have a CAB).

If you use Daydream to run your control program, CM-9 becomes easier to sustain because you can map the requirement to an owner, procedures, and recurring evidence requests, then track completion without spreadsheets. ¹

Required evidence and artifacts to retain

Auditors test CM-9 by sampling. Keep artifacts that survive staff turnover and tooling changes.

Core artifacts

• System-specific Configuration Management Plan (versioned, approved).
• RACI or role definitions for change authority (can be inside CMP).
• Baseline definition (tables, IaC repo references, image build definitions).

Operating evidence (sample-ready)

• Change tickets or work items showing request, risk/impact, approvals, implementation date/time, and closure notes.
• Pull requests with peer review and approval history.
• Release/deployment logs that tie to the change record.
• Drift/compliance reports and remediation records.
• Emergency change records plus post-implementation review notes.

Audit packaging tip Maintain a “CM-9 evidence index” per system: where each artifact lives, how to export it, and who can produce it during an exam.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your CMP for this system boundary. Who approved it and when was it last updated?” ²
• “Pick five production changes. Show the approvals, testing evidence, and deployment record for each.”
• “How do you prevent unauthorized configuration changes?” (assessors will look for access controls plus workflow enforcement)
• “How do emergency changes work, and how do you ensure they’re reviewed afterward?”
• “Where is the configuration baseline, and how do you detect drift?”

Hangups that trigger deeper testing:

• CMP says “CAB approves all changes” but evidence shows changes merged directly to main without documented approval.
• Baselines exist only as tribal knowledge (“the way it’s configured in prod”).
• Third parties make changes without your change records.

Frequent implementation mistakes and how to avoid them

Mistake 1: Writing an enterprise policy and calling it a CMP.
Fix: publish a CMP per system with concrete tools, repos, ticket types, and roles.

Mistake 2: CMP describes an ideal process, not the real one.
Fix: document the workflow you actually run, then improve it iteratively. Assessors penalize fiction.

Mistake 3: No linkage between tickets and deployments.
Fix: require ticket ID in PR titles, commit messages, or deployment annotations, then demonstrate traceability in samples.

Mistake 4: Emergency change path becomes the default.
Fix: define criteria for emergency use and require after-action documentation; audit emergency usage patterns.

Mistake 5: Drift detection is informal.
Fix: implement scheduled or continuous checks and retain reports plus remediation tickets.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-9, so you should treat this primarily as an assessment and authorization risk rather than a cited enforcement trend. ¹

Operational risk is still concrete:

• Weak configuration management increases the chance of unauthorized change, misconfiguration, outages, and delayed incident investigation because you cannot reconstruct state changes.
• In federal and contractor contexts, CM-9 gaps can block ATO progress, trigger POA&Ms, and expand assessor sampling into adjacent CM controls.

A practical 30/60/90-day execution plan

Use phased execution (not calendar promises) to avoid committing to dates you cannot meet.

First 30 days (stabilize and draft)

• Confirm system boundary and inventories that belong to the system.
• Assign CMP owner and approvers; document decision rights.
• Draft the CMP outline: baselines, change workflow, emergency process, drift monitoring, evidence sources.
• Identify where evidence lives today (tickets, Git, CI/CD, cloud logs) and what is missing.

Days 31–60 (implement and connect tooling to the plan)

• Publish CMP v1 with approvals and document control.
• Standardize change records (ticket templates, PR templates, required fields).
• Implement traceability (ticket-to-PR-to-deploy mapping).
• Stand up drift checks and produce initial reports.
• Run a “mini-audit”: pick recent changes and validate you can produce end-to-end evidence.

Days 61–90 (prove operation and harden)

• Collect a clean evidence set suitable for assessor sampling.
• Train engineers, IT ops, and third parties on the workflow and required records.
• Tune emergency change rules and enforce post-change review.
• Establish recurring CMP review triggers tied to significant system changes and toolchain changes.

Ongoing: maintain the CM-9 owner-to-evidence mapping so evidence collection becomes routine and defensible. ¹

Frequently Asked Questions

Do I need a separate CM-9 Configuration Management Plan for every system?

CM-9 is scoped “for the system,” so assessors expect a system-specific CMP or a master CMP with clearly separated system addenda. ¹

Can my change management policy satisfy CM-9?

A policy helps, but CM-9 expects a plan that is actionable for the system boundary, including baselines, workflows, roles, and evidence sources. If your policy lacks system-specific detail, it will read as incomplete in an assessment. ²

What evidence is usually sampled to test CM-9?

Expect sampling of change tickets, approvals, code reviews, deployment logs, and baseline/drift reports tied to the system. Your CMP should point to these sources so you can produce evidence quickly. ¹

We deploy via CI/CD with Git approvals. Do we still need CAB minutes?

Not necessarily. You need documented approvals and traceability; Git-based approvals can work if your CMP defines them as the approval mechanism and you can export the approval history for sampled changes. ²

How should we handle third parties who make configuration changes?

Treat third-party changes as your changes: require a request record, approval, implementation trace, and validation evidence under your CMP. If the third party uses their own tooling, define how you ingest or retain their records. ²

What’s the quickest way to make CM-9 sustainable?

Assign a control owner, document the procedure engineers already follow, and set recurring evidence pulls from ticketing and source control so you are not rebuilding proof during audits. Daydream can track ownership and recurring artifacts so CM-9 evidence stays current. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5