RMFInsider

A Configuration Management Plan that satisfies CM-9 has to do four things, because that is literally what the control says: define the roles, responsibilities, and processes for configuration management; define how configuration items are identified and placed under management; define how the configuration of those items is controlled through the life cycle; and protect the plan itself from unauthorized disclosure and modification. Everything else in the document exists to make those four requirements concrete for your system. Write to those four parts, cite the other CM controls where the plan implements them, and the assessor has very little to argue with.

I have reviewed CM plans that were forty pages of copied NIST text and CM plans that were six pages of actual procedure, and the six-page version passed cleaner every time, because the assessor could find who approves a change, where the baseline lives, and how a security impact analysis gets triggered. This post lays out the structure I use, section by section, with the CM control each section covers and the evidence the assessor will ask for.

What CM-9 requires and what it does not

CM-9 in NIST SP 800-53 Rev 5 is the plan control; the rest of the CM family are the doing controls. That distinction matters because a common mistake is writing a CM plan that describes the ideal process from NIST SP 800-128 (the guide for security-focused configuration management) without describing what your program actually does. The plan is assessed by comparing it to reality. If the plan says a Configuration Control Board meets weekly and the CCB has not met since the last ATO, the finding is written against CM-9 and CM-3 at the same time.

The four parts of the control, restated as the questions an assessor will ask:

• CM-9(a): Who does configuration management here, what is each role responsible for, and what process do they follow?
• CM-9(b): How do you decide which things are configuration items, and at what point in the life cycle do they come under control?
• CM-9(c): Once something is a configuration item, how is its configuration managed: baselined, changed, verified, and audited?
• CM-9(d): How is this plan protected? Who can read it, who can change it, and where is the authoritative copy?

CM-9 is in the Moderate and High baselines under CNSSI 1253, so nearly every DoD system carries it. Enhancement CM-9(1) assigns CM responsibility to personnel not directly involved in development, worth knowing when your CM manager is also your lead developer.

Section 1: Purpose, scope, and system identification

One page. Name the system, its eMASS identifier, the authorization boundary the plan covers, and the life cycle phase. State that the plan implements CM-9 and supports CM-2 through CM-8 and CM-10 through CM-14. Reference the System Security Plan as the parent document and keep the system description consistent with it; assessors compare the two and a mismatch in the component count is a finding waiting to happen.

Scope is where you draw the line between what this plan manages and what is inherited. If a data center or cloud provider runs its own CM program, name the provider and state which configuration items are theirs.

Section 2: Roles and responsibilities (CM-9(a))

List every role that touches configuration and what each owns. The typical set for a DoD system:

• Program Manager / System Owner: Approves the CM plan, resources the CM process, and chairs or delegates the CCB.
• Configuration Manager: Maintains the baseline documentation, runs the change request process, and keeps the configuration status accounting records. Often the ISSO in a small program, which the plan should say plainly if it is true.
• Configuration Control Board (CCB): The decision body for changes. Name the voting members by role (PM, ISSM or ISSO, lead system administrator, lead engineer, user representative) and the quorum rule.
• ISSO / ISSM: Performs or reviews the security impact analysis for every proposed change, verifies STIG compliance after implementation, and updates the authorization package when a change affects it.
• System Administrators and Engineers: Implement approved changes, document the as-built state, and update the baseline records.
• Developers (if applicable): Manage source and build configuration under the same process, with the CM tool named.

Then describe the process in the order it happens: request, analysis, approval, implementation, verification, closure. The assessor wants to trace one real change through your process and see each step evidenced.

Section 3: Configuration identification (CM-9(b), CM-2, CM-8)

Define what a configuration item is for your system: any hardware component, operating system, application, firmware, network device, VM or container image, or document whose change could affect the security posture or function of the system. Then state how CIs are named, versioned, and recorded.

The hardware and software baseline in eMASS is your configuration item list for authorization purposes. The CM plan should say that the eMASS lists are the authoritative inventory (CM-8), how often they are reconciled against a discovery scan, and who performs the reconciliation. If you also maintain a CMDB or an asset management tool, name it and state which one wins when they disagree. They will disagree.

For CM-2, describe the baseline configuration itself: the approved operating system versions, the STIG or SRG each component is configured to, the application versions, the network configuration, and the approved settings for any component that lacks a STIG. State where the baseline is stored (a controlled repository, a document library with version control, a golden image location) and when it was last approved. The plan should also cover CM-2(2), the requirement to maintain currency through automated mechanisms where you have them, and CM-2(3), retention of previous baselines to support rollback.

Section 4: Configuration change control (CM-9(c), CM-3, CM-4, CM-5)

This is the section the assessor reads twice. Define the change request form or ticket type, the fields it must contain, and the categories of change:

• Standard or pre-approved changes: Routine patching within the approved baseline, signature updates, and user account changes. State that these are logged but do not require CCB review, and define the boundary precisely so nobody classifies a domain migration as routine.
• Normal changes: Anything that alters the baseline: new software, version upgrades, architecture changes, new interconnections, firewall rule changes. These go through the security impact analysis and the CCB.
• Emergency changes: Changes required to restore service or close an active security exposure. Define who can authorize one verbally, the maximum time before it is documented and reviewed by the CCB retroactively (72 hours is a common figure), and the rule that an emergency change still gets a security impact analysis, just after the fact.

For CM-4, state that every normal and emergency change receives a security impact analysis before approval, who performs it, and where it is recorded. The security impact analysis template covers the content; the CM plan only needs to say when the SIA is triggered, what result levels exist (no security impact, impact mitigated, impact requires AO notification), and what happens at each level. The last one connects the CM plan to the significant change process in your continuous monitoring strategy, and the assessor will check that both documents agree on what counts as significant.

For CM-5, describe access restrictions for change: who has the administrative privileges to modify production configuration, how those privileges are limited (separate admin accounts, privileged access workstations, change windows), and how unauthorized changes are detected. If you use a file integrity or configuration drift tool, name it here. If you do not, say that detection relies on periodic STIG re-scans and log review, and accept that the assessor may write an observation.

Section 5: Configuration settings and least functionality (CM-6, CM-7)

State that the mandatory configuration settings are the applicable DISA STIGs and SRGs, list which STIGs apply to which components, and reference the STIG application process your program follows. Describe how deviations are handled: a STIG check that cannot be met gets a documented deviation with a risk justification, approval by the ISSM or AO as your component requires, and a POA&M entry if the deviation is a finding rather than a not-applicable.

For CM-7, describe how the system is restricted to essential functions: the ports, protocols, and services baseline, the PPSM registration, application allow-listing if used, and the review cadence for disabling functions that are no longer needed. The plan should state the frequency for the CM-7(1) periodic review; annually is the common CNSSI 1253 value.

Section 6: Configuration status accounting and audits

Status accounting is the record-keeping: the current approved baseline, the changes pending, approved, implemented, and verified, and the history of each CI. State where these records live: usually the ticketing system, the eMASS baseline lists, and the STIG checklists. Say that plainly rather than describing a unified CM database you do not have.

Configuration audits verify that the as-built system matches the documented baseline. Describe two kinds: functional audits (does the system do what the baseline says) and physical audits (does the inventory match what is racked and running). State the frequency, who performs them, and that discrepancies become either a change request or a POA&M item. Tying the annual audit to your continuous monitoring calendar means it actually happens.

Section 7: Tools

List the tools that implement each part of the process. A typical DoD set: the ticketing system for change requests, a version control repository for baseline documents and code, ACAS for discovery and vulnerability data, Evaluate-STIG or SCAP tools for settings compliance, a patch management platform, and eMASS for the authoritative inventory. State what each tool is authoritative for, so that when the assessor says “show me” for any step in Section 4, you can open the tool where the evidence lives.

Section 8: Plan protection and maintenance (CM-9(d))

State the classification or CUI marking of the plan, who is authorized to read it, who can modify it, and where the controlled copy is stored. A CM plan reveals your architecture, your tool set, and your change windows, which is useful information for anyone planning something you would not approve. Store it with the SSP under the same access controls, and upload the current version to eMASS as an artifact linked to CM-9.

Then define when the plan is reviewed: annually as part of the continuous monitoring cycle, and whenever the CM process, the CCB membership, or the tool set changes. Include a revision history table at the front with dates, versions, and approvers. The revision history is your CM-9 evidence that the plan is maintained, so an untouched revision table from three years ago undermines the whole document.

The evidence the assessor will request

Expect requests for the signed plan itself, CCB meeting minutes or decision records for the last several meetings, three to five completed change requests traced from submission through SIA to closure, the current baseline documents, the most recent configuration audit results, and the eMASS hardware and software lists with the reconciliation date. If you can produce those in under an hour, your CM plan describes reality and CM-9 will be marked compliant. If any of them do not exist, the plan is a story, and the assessor has read that story before.

If you want the CM plan requirements laid out next to the other package artifacts, with the CM family controls and the evidence each one needs tracked in one place, the RMF Checklist is the working document I use to keep a package assessment-ready.