CM-9: Configuration Management Plan

Quick-reference card

What this control requires

CM-09 requires your organization to develop, document, and implement a formal configuration management (CM) plan for every system. The plan must define roles and responsibilities, establish processes for identifying configuration items (CIs) across the entire system development life cycle (SDLC), and place those items under active management.

In practice, defining CIs is only the starting point. The plan must also spell out how your team advances changes through a structured change management process, updates configuration baselines, and maintains accurate inventories. Designated personnel must review and approve the plan, and the plan itself must be protected from unauthorized disclosure and modification. In practice, this means treating the CM plan as a controlled document with its own access restrictions and version history.

Specifically, most CM plans need to cover both developmental artifacts, such as source code repositories and software libraries, and operational assets, such as installed components and their runtime configurations. The plan should also describe how your team manages development, test, and production environments as separate configuration domains. NIST encourages the use of CM plan templates to promote consistency across systems and reduce the effort required to stand up new plans.

Why it matters

Most organizations that fail a CM-09 assessment don’t lack a configuration management process. They don’t have a documented, approved plan that ties the process to defined roles, specific configuration items, and a repeatable change workflow. Auditors treat undocumented CM activity as uncontrolled CM activity, regardless of how disciplined the team believes it is.

In practice, the absence of a formal plan means configuration drift accumulates silently. Teams apply changes without impact analyses, skip baseline updates, and lose track of which components are actually in production. The resulting inventory gaps make it harder to respond to vulnerabilities or validate that controls are operating as intended.

The result is a cascade of downstream audit findings across related controls. An incomplete CM plan undermines your baseline configuration efforts, weakens change control processes, and leaves your system component inventory unreliable. Auditors view CM-09 as the keystone of the Configuration Management family because it governs how every other CM control is executed.

What attackers exploit

• Untracked configuration items that fall outside the plan’s scope, creating blind spots where unauthorized changes go undetected
• Stale baselines that no longer reflect the actual state of production systems, masking unauthorized modifications
• Missing role assignments that leave change approval responsibilities unclear, allowing unauthorized personnel to push changes
• Unprotected CM plan documents that attackers modify to weaken change control thresholds or remove approval gates
• Disconnected development and production environments where configuration changes bypass the documented change management workflow

How to implement

For your organization

The most common failure mode is drafting a CM plan that reads like a policy statement instead of an operational playbook. A plan that says “changes will be managed” without specifying who approves changes, what constitutes a CI, or how baselines are updated won’t survive an audit.

Step 1: Define your configuration items. Start by inventorying every component class your systems depend on: hardware, software, firmware, and documentation. Map each CI to the system it supports and the SDLC phase where it enters configuration control. Don’t limit the scope to production assets. Development libraries, build configurations, and infrastructure-as-code templates all qualify as CIs.

Step 2: Assign roles and responsibilities. Name the individuals or roles responsible for CI identification, change requests, impact analysis, change approval, and baseline updates. Avoid generic assignments like “the IT team.” Tie each responsibility to a named role in your organizational structure.

Step 3: Establish your change management workflow. Document the step-by-step process for proposing, reviewing, approving, implementing, and verifying changes. Specify how your team conducts security and privacy impact analyses before approving changes. Include escalation paths for emergency changes.

Step 4: Define baseline management procedures. Describe how your team establishes, documents, and updates configuration baselines. Your plan should specify the cadence for baseline reviews and the criteria that trigger an unscheduled baseline update. Configuration management tools that enforce desired-state configurations can automate baseline drift detection.

Step 5: Protect the plan itself. Apply access controls to the CM plan document. Maintain version history, restrict edit permissions, and log all access. The plan is itself a CI and should be treated as one.

Common mistakes to avoid:

• Writing a plan that mirrors policy language without specifying operational procedures
• Omitting firmware and documentation from the CI inventory
• Failing to update the plan when organizational roles change
• Storing the plan in an uncontrolled shared drive without access logging

For your vendors

The most common gap in third-party CM-09 assessments is accepting a vendor’s claim that “we have configuration management” without verifying that a documented, approved plan exists.

Step 1: Request the vendor’s CM plan. Ask for the actual plan document, not a summary or a policy statement. Verify that the plan covers roles, responsibilities, CI identification, change management processes, and baseline management. If the vendor offers only a policy document, flag the gap.

Step 2: Verify plan approval. Confirm that designated personnel reviewed and approved the plan. Look for approval signatures, dates, and version numbers. An undated, unsigned plan is effectively an uncontrolled draft.

Step 3: Assess CI coverage. Review the vendor’s CI inventory to confirm that the plan covers all relevant component classes: hardware, software, firmware, and documentation. Pay attention to whether the vendor includes development and test environment configurations in addition to production assets.

Step 4: Evaluate change management maturity. Request evidence that the vendor follows the change management workflow documented in the plan. Look for change request logs, impact analysis records, and approval artifacts. A plan without corresponding execution evidence suggests the plan exists for compliance purposes only.

Step 5: Confirm plan protection. Ask how the vendor protects the CM plan from unauthorized modification. You should see access controls, version history, and an audit trail for plan changes.

Common mistakes to avoid:

• Accepting a CM policy as a substitute for a CM plan
• Failing to verify that the plan has been reviewed and approved within the past 12 months
• Overlooking whether the vendor’s CI scope matches the services they provide to your organization
• Skipping validation of the change management workflow against actual change records

Evidence examples

Cross-framework mapping

Related controls

• CM-02 — Baseline Configuration: defines the configuration baselines that the CM plan must establish procedures to maintain and update
• CM-03 — Configuration Change Control: implements the change management workflow that the CM plan must document and assign roles for
• CM-04 — Impact Analyses: provides the security and privacy impact analysis process that the CM plan must incorporate into its change approval workflow
• CM-05 — Access Restrictions for Change: enforces the access controls that protect configuration items and the CM plan itself from unauthorized modification
• CM-08 — System Component Inventory: maintains the CI inventory that the CM plan must define processes for populating and updating throughout the SDLC
• PL-02 — System Security and Privacy Plans: incorporates the CM plan by reference and defines the system-level security context for configuration management activities
• RA-08 — Privacy Impact Assessments: feeds into the impact analysis step of the CM plan’s change management workflow for changes affecting personally identifiable information
• SA-10 — Developer Configuration Management: extends CM plan requirements to developers and integrators responsible for system components during the development phase
• SI-12 — Information Management and Retention: governs how long CM plan versions, change records, and baseline documentation must be retained

Frequently asked questions

What is NIST SP 800-53 CM-09?

CM-09 is a NIST SP 800-53 control that requires organizations to develop, document, and implement a configuration management plan for each system. The plan must define configuration items, assign roles and responsibilities for CM activities, establish a change management workflow, and be reviewed and approved by designated personnel. CM-09 applies to systems categorized at MODERATE and HIGH baselines and covers both developmental and operational phases of the SDLC.

What happens if CM-09 is not implemented?

Without a documented configuration management plan, your organization loses the ability to demonstrate controlled management of configuration items across the SDLC. Auditors will flag the absence of defined roles, untracked CIs, and undocumented change management processes as findings. These gaps cascade into related control failures across the Configuration Management family, undermining baseline configuration, change control, and component inventory efforts. For organizations pursuing federal authorization, a missing CM plan becomes a plan of action and milestones (POA&M) item that won’t close until the plan is in place.

How do you audit CM-09?

Auditing CM-09 starts with verifying that a documented configuration management plan exists for each in-scope system. Assessors examine whether the plan addresses all required elements: roles and responsibilities, CI identification processes, a defined set of configuration items under management, and protection from unauthorized disclosure and modification. They confirm that designated personnel reviewed and approved the plan by checking for signatures, dates, and version control records. Assessors then validate that the plan’s change management workflow aligns with actual change records, impact analysis artifacts, and baseline update logs.

What should a configuration management plan include?

A configuration management plan should cover five areas: CI definitions, role assignments, change management workflows, baseline management procedures, and plan protection controls. The most common gap auditors find isn’t a missing section but a plan that reads like a policy restatement. A CM policy says “the organization shall manage configurations.” A CM plan says who approves change requests, which component classes qualify as CIs, how baselines are updated after each release, and what happens when an emergency change bypasses the standard workflow. If your plan doesn’t answer those operational questions for each in-scope system, it’s likely to draw a finding during assessment.