What the CM-9 configuration management plan requires
If an assessor asks for your configuration management plan and you do not have one written for this system, you have a gap that no amount of change tickets will close. CM-9 asks for a system-specific configuration management plan that sets out roles, responsibilities and processes, establishes how configuration items are identified and managed through the system development life cycle, defines which items fall under the plan, is reviewed and approved by defined personnel, and is protected from unauthorized disclosure and unauthorized change. The point of the plan is to give everyone the same answer to the question "what is this system, and which parts of it are under control?" Without that shared definition, changes get made against different understandings of the baseline, and impact analysis, approval and recovery all become guesswork.
The plan is hard in practice because it describes how other controls will run rather than standing alone. It has to name who owns the baseline, which items are configuration items, where the records live and how changes move through review. Those answers depend on how CM-2 baselines, CM-3 change control, CM-8 inventory and CM-6 settings are actually operated. Organizations often write the plan first and find the tooling does not match it. A useful first step is to list the systems in scope, confirm which ticketing or change tool is the system of record and ask the system owner to name the people accountable for each configuration item class. Ask any implementation partner to show how the plan maps to the tools you already run, not to a generic template.
NIST SP 800-53B Release 5.2.0 selects CM-9 for the moderate and high baselines and does not select it for the privacy baseline, so most federal and contractual programs that adopt those baselines will expect a documented plan. The single enhancement, CM-9(1), which concerns assignment of responsibility for the plan, is not selected in any SP 800-53B baseline in this release. Confirm the baseline your authorization boundary uses before you scope the work, and confirm with the authorizing official whether they expect the enhancement anyway. An independent assessor will test the plan against the determination statements in SP 800-53A, so the plan must be a document people can find, read and show to an examiner.
Which systems and teams the CM-9 plan must cover
CM-9 is a per-system requirement, so the first decisions are where the system boundary sits and which teams own configuration items inside it. Each card below is a scoping decision that changes who writes the plan, what it names and what evidence an assessor will ask to see.
Set the system boundary first
The plan can only define configuration items for components the organization has placed inside the system boundary. Confirm which hosts, containers, network devices, databases and management consoles are inside, and which sit in a shared environment outside it. Record the boundary in the system security plan and check that the plan's item list matches it. Gaps usually appear at the edges, such as backup servers, CI runners and identity services.
Confirm the baseline that selects CM-9
SP 800-53B selects CM-9 for the moderate and high baselines but not for the low or privacy baselines. A system categorized as low impact may not need a formal plan under this control, though other configuration controls still apply. Confirm the impact categorization and the selected baseline before scoping effort. If a tailored baseline or overlay changes the selection, document the decision and its rationale.
Map owners for each configuration item
The plan must name the roles responsible for configuration items, so each item needs a named owner. Infrastructure teams typically own operating system and network builds, application teams own deployment artifacts and application settings, security owns security-relevant settings and monitoring, and change management owns approval records. Build a responsibility matrix that shows which team approves, implements and verifies each item class, and check that no item lacks an owner.
Reference third-party configurations
Managed service providers, software vendors and cloud platform operators often control settings the organization cannot change directly. The plan should state which configurations a third party manages, which artifacts the organization receives from them, and how changes are communicated and approved. Contracts and service descriptions should give the organization the right to receive configuration records. Ask each provider what configuration evidence it can supply and how often.
State inherited and shared platform controls
When a shared platform, such as a common hypervisor cluster or identity service, supports several systems, the plan for each system must say which configuration items it inherits and which it owns. Document the inheritance in the plan itself rather than assuming the platform team's plan covers it. Assessors will check that each system's plan names the shared components and the party responsible for them, and that the two plans do not contradict each other.
Include the security and change functions
The plan must connect to security review and change control, because configuration items change through those processes. Name the change control body that approves changes to configuration items and the security role that reviews impact. Include the system security plan and privacy plan as related documents, since the plan's items and roles must match what those documents describe. Check that the same names appear across all of them.
How an assessor tests the CM-9 configuration management plan
This table maps each SP 800-53A assessment object for CM-9 to the test method, the evidence an assessor asks for and the findings that most often appear. Read it as a checklist for preparing the plan and its supporting records before an assessment begins.
| Assessment object | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Configuration management policy (examine) | Confirm the policy sets the basis for configuration management planning and names the owner and review cycle. | Approved policy with version history, owner and review date. | Policy is missing, unsigned or never reviewed after system changes. |
| Procedures for configuration management planning (examine) | Check that documented procedures explain how the plan is written, reviewed, approved and updated. | Procedure document showing steps, roles and review triggers. | Procedures describe a process the team does not follow in practice. |
| Configuration management plan (examine) | Compare the plan against the system boundary and the determination statements for roles, item identification, life cycle coverage and approval. | Current plan with defined configuration items, roles, approval record and revision history. | Plan is out of date, does not match the current system, or lacks named configuration items. |
| System design documentation (examine) | Trace the configuration items named in the plan to the architecture and component records. | Architecture diagrams and design documents that match the items listed in the plan. | Design documents show components that the plan does not mention. |
| System security plan and privacy plan (examine) | Check that both plans refer to the configuration management plan consistently and describe the same system. | System security plan and privacy plan with cross-references to the configuration management plan. | Security and privacy plans describe a different system version or omit the configuration plan. |
| Personnel responsible for developing the plan (interview) | Ask who writes, reviews and maintains the plan and whether they know the defined configuration items and approval path. | Role assignments, delegation records and staff able to explain the plan. | Responsible staff cannot describe the plan or the plan names people who have left. |
| Organizational process for developing and documenting the plan (test) | Observe or walk through a recent plan update to confirm the documented process was followed and the plan was approved. | Records of a recent update, review comments, approval sign-off and distribution list. | Updates happen outside the documented process, or approval is missing for the latest version. |
| Protection of the plan from unauthorized disclosure and change (test) | Check access controls on the repository holding the plan and review the change log for edits. | Access list for the document store, version history and audit records of changes. | Plan is editable by broad groups, or changes are made without a recorded approval. |
How to build a CM-9 plan that an assessor can test
This sequence turns CM-9 into a plan that names who does what, which configuration items it covers, how changes flow through approval, and how the document itself is protected, so an assessor can trace each determination statement to a record.
Confirm the system boundary and baseline
Start by fixing the system boundary that the plan governs, including the components, environments and interfaces that sit inside it. Record this alongside the baseline configuration that CM-2 requires, so the plan and the baseline describe the same system. The output is a short boundary statement with a diagram and a reference to the current baseline version. You know this step is done when a reviewer can point to every component in the diagram and find it in the baseline. Confirm with the assessor which boundary they will test against, since the plan must match the system security plan that the assessment objects reference.
Name roles and responsibilities in a role matrix
Assign each configuration management responsibility to a named role or position, covering who develops the plan, who maintains the configuration items, who reviews changes, who approves the plan and who audits compliance. CM-9(1) on assignment of responsibility is not selected in any SP 800-53B baseline, but assessors still interview the people who develop the plan, so the matrix must be accurate and current. The output is a role matrix that maps each duty to a role, a deputy and a reporting line. You know it is done when every process in later steps has an owner in this matrix and no duty is shared without a named lead.
Define configuration items and their life cycle stages
Decide which items the plan manages, such as hardware, software, firmware, configuration files, scripts, infrastructure as code and security documentation, and the level of detail at which each is tracked. Then map where each item is created, changed, released, operated and retired across the system development life cycle. The output is an item register that lists each configuration item, its owner, its life cycle stages and the control that tracks it. You know this step is done when every item in the baseline appears in the register and each entry names the stage where it is first placed under configuration control.
Document identification, change and recording processes
Write the procedures for how each configuration item receives an identifier, how changes are proposed, reviewed and implemented, and how the resulting records are kept. Link the change process to CM-3 for change control, CM-4 for impact analysis and CM-5 for access restrictions on who may change the system, and link the item register to CM-8 for the component inventory. The output is a process section of the plan with a flow for each activity and a named record for each step. You know it is done when an assessor can follow one change from proposal to closure and find a record at every stage.
Set the review and approval path with named approvers
Define the reviewers and the approving official for the plan, the review frequency, and the trigger events that require an update, such as a change to the system boundary or to the life cycle process. Record the approval as a signed or dated entry in a document control log, with the version number and the list of changes since the prior version. The output is an approval record and a revision history. You know this step is done when the current version shows a named approver, a date and a link to the last review, and the approver is the same person named in the role matrix.
Set access and storage rules that protect the plan
Define who can read, edit and approve the plan and its registers, where the controlled copies live, and how changes to the plan itself are logged. Protect the plan from unauthorized disclosure and modification by restricting write access to the document owner and approvers, keeping a single controlled repository and retaining prior versions. The output is a protection rule set and an access list that matches the role matrix. You know it is done when a test edit by an unlisted user is blocked and every version of the plan can be restored and compared. Confirm the exact access controls with your platform and security team before the assessment.
Map the plan to the related controls and collect evidence
Cross-reference each section of the plan to the related controls that the SP 800-53 catalog lists for CM-9: CM-2, CM-3, CM-4, CM-5, CM-8, PL-2, RA-8, SA-10 and SI-12. Build a traceability table that points each assessment object in SP 800-53A, such as the plan, the policy, the procedures and the interview record for plan developers, to the document or record that proves it. The output is a traceability matrix and an evidence folder. You know this step is done when every assessment object has a located artifact, and the gaps are logged for remediation before the assessor arrives.
Evidence that passes a CM-9 review
CM-9 is tested by reading the plan itself, then checking whether the people, items and records it names actually match how the system is run. The six artifacts below connect the plan to its approval history, its role assignments, the items it governs, its review cadence, its protection and its link to the system security plan.
Approved plan with version history
The configuration management plan is the primary artifact. Assessors look for a single current document that defines the configuration items, the life cycle stages it covers and the processes for managing them, with a version history showing each revision and the approver signatures for each one. Confirm that the approver is the defined role named in the plan, not whoever happened to sign last. A wiki page with revision history kept by the document system can serve as this record when approvals are captured alongside each version.
Role and responsibility matrix
CM-9 requires the plan to address roles, responsibilities and processes. The matrix should name who develops the plan, who approves it, who maintains the configuration item register, who chairs change review and who holds the authority to change configuration items. Assessors compare the names and roles against the plan text and interview staff to confirm they know their duties. Keep the matrix tied to job roles rather than individuals so it stays accurate through staff turnover, and record the date of the last confirmation.
Configuration item register with life cycle stages
The plan must establish how configuration items are identified and managed through the system development life cycle. The register lists each defined item, such as hardware, operating system images, application code, configuration files and security tooling, with its owner, its current stage and the life cycle stages it passes through. Assessors sample items and check that the register matches what is deployed. Reconcile it against the component inventory on a schedule so gaps are caught before an assessment.
Review record for periodic and event-driven updates
Assessors expect evidence that the plan is reviewed and approved by defined personnel and kept current. Keep a dated review log that records each periodic review and each review triggered by a significant event, such as a new platform component, a change to the architecture or a finding that exposed a gap. Each entry should state what was checked, what changed and who approved the outcome. An empty log is a finding, even when the plan text is sound, because it suggests the plan has not been maintained.
Access list and protection settings for the plan
CM-9 requires the plan to be protected from unauthorized disclosure and modification. Produce the access list for the repository holding the plan, showing who can read it and who can edit it, and the settings that enforce those rights, such as role-based permissions at the space or page level. Assessors check that edit rights are limited to the defined plan owners and that readers match a documented need. Export the permission settings and the list of users with edit rights at the time of each assessment.
Cross-reference to the system security plan
The SP 800-53 catalog lists related controls for CM-9, including CM-2, CM-3, CM-4, CM-5 and CM-8, and the assessment procedure names the system security plan as an object to examine. The plan should point to the security plan, the baseline configuration, the change control records and the component inventory, and those documents should point back to the configuration management plan. Assessors trace these links to confirm the plan is consistent with the rest of the system documentation. Check each reference after every revision so that section numbers and document names still resolve.
What a CM-9 configuration management plan costs to meet
This table compares the cost components of meeting CM-9, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a written scope and quote, since NIST does not estimate compliance costs and no figures are given here.
| Cost component | One-time or recurring | What drives the cost | How to keep it down |
|---|---|---|---|
| Internal engineering time to write the plan | One-time, then updated | Number of system components, teams involved, and how many configuration items the plan must define | Start from the existing baseline and inventory records, and scope the plan to the system boundary in the system security plan |
| Configuration management tooling or licenses | Recurring license or subscription, or one-time setup for self-hosted tools | Number of users, integrations with build and deployment pipelines, and required reporting features | Use self-hosted open-source tools such as GLPI for change records and BookStack or XWiki for plan versions, which removes license spend but adds hosting and admin effort |
| Evidence upkeep and periodic review | Recurring | How often the plan changes, number of approval cycles, and how many reviewers sign off | Keep version history in the document tool and link each review to a ticket so approvals are not reconstructed at audit time |
| External review or testing of the plan | One-time per review cycle, optional | Depth of review requested, size of the system, and whether the reviewer also tests the processes the plan describes | Ask for a defined review scope and limit it to the plan and the processes it names rather than a full configuration audit |
| Assessor sampling time | One-time per assessment, repeats each cycle | Number of configuration items sampled, number of plan revisions in the period, and quality of approval records | Prepare a sample-ready evidence folder with dated approvals, reviewer names and the plan version in force on each date |
| Implementation partner preparation work | One-time for setup, then support retainer if chosen | Current maturity of configuration records, number of systems in scope, and fixed-scope deliverables agreed in writing | Define deliverables, exclusions and the handover format in the written scope before work starts |
Open-source tools that hold CM-9 evidence
CM-9 is a document-centric control, so the evidence is a plan that is current, approved and protected, plus the records showing it is followed. The tools below can each hold a different part of that evidence, but none of them replaces the approval workflow or the access controls the organization must define and confirm.
GLPI change tickets and planning
GLPI's Assistance module tracks tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. For CM-9, it can hold the change and release records that show the plan's processes are used in practice, such as who requested a change to a configuration item and who approved it. The license caveat is GPL-3.0-or-later, so confirm with counsel how its terms apply if you modify and redistribute it. Check whether its approval steps match the approval roles named in your plan before relying on it.
Zammad request intake
Zammad is a web-based helpdesk that brings requests from email, chat, telephone and social media into one ticket system. For CM-9, it can record how requests affecting configuration items enter the organization and route to the people the plan names as responsible. It does not manage the plan itself. Its license is AGPL-3.0-only, which carries network-use obligations for modified versions, so confirm those duties with your legal team. Verify that its ticket history meets your retention and audit needs.
XWiki plan version history
XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For CM-9, this makes XWiki a reasonable home for the configuration management plan itself, since assessors look for evidence that the plan is reviewed and that changes to it are traceable. Confirm that the approved version is marked clearly, because version history alone does not show formal approval. The library is LGPL-2.1-or-later, so check the terms for any modifications you make.
BookStack role-based access
BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For CM-9, this lets you restrict who can edit the plan while allowing wider reading, which supports the protection from unauthorized modification the control requires. Test the permission model with your own roles before you rely on it, since a page-level override can grant more access than the book it sits in. BookStack is MIT licensed, so its license imposes few obligations, but you should still confirm that its access model meets your classification requirements.
Who owns the CM-9 plan and who prepares the evidence
Your organization owns CM-9. Its configuration management plan describes how your system is run, so the people accountable for that system must decide what the plan says, who approves it and how it stays current. An implementation partner can draft and organize material, but it cannot make these decisions on your behalf or sign off the plan as your approved document.
- Named roles: Assign who owns the plan, who manages each configuration item and who acts as the change control contact. SP 800-53 expects roles and responsibilities to be stated, not implied.
- Approval: Name the defined personnel who review and approve the plan, and record the approval date and version.
- Operational content: Your engineers write how items are identified, how they move through the system development life cycle and which tools hold the records.
- Reviews: Schedule periodic reviews of the plan and keep the minutes, changes and reasons for updates.
- Protection: Decide who can read and edit the plan, and enforce that access in your document repository.
Before the assessment, confirm that every role named in the plan has a real person who can explain it to an assessor.
An implementation partner prepares the systems and evidence that let your team meet CM-9 and let an assessor test it. DeployOpen works this way: it prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Work is usually scoped in writing before it starts, so the boundary of the partner's role is clear.
- Plan structure: Prepare a plan template that covers roles, processes, configuration item identification and approval, mapped to the CM-9 assessment objects.
- Tooling: Configure self-hosted tools that hold the plan, change tickets and item records, such as a ticketing system, a wiki with version history and a permissions model.
- Evidence package: Assemble the plan versions, approval records, review logs and access settings into a set that an assessor can examine.
- Outsourced work: Partners often take on tool setup, template drafting, evidence collection and gap remediation, while the organization keeps ownership of decisions.
- Quote basis: Ask for a written scope listing each deliverable, the systems in scope and who performs each task.
Check that the partner's deliverables are documents and configurations you own, not outputs that only the partner can reproduce.
An independent auditor, assessor or certification body tests the plan and issues the findings or report. Its work is separate from the organization and from any partner, because an assessment result is only meaningful when the person judging the controls did not build them. The partner cannot issue the assessment result, and the partner's preparation does not replace the assessor's testing.
- Determination statements: SP 800-53A gives CM-9 twelve determination statements that the assessor evaluates against your evidence.
- Assessment methods: The assessor examines the plan and related policy, interviews the people who develop the plan, and tests the process used to develop and document it.
- Findings: The assessor records where the plan meets or misses each determination and reports these findings to you.
- Independence: Confirm the assessor's independence rules before you engage it, and keep the preparation partner and assessor roles separate.
- Engagement: Agree on the assessment scope, the evidence you will provide and the report format in writing.
Before you engage an assessor, confirm which report or certificate it can issue and which authority accepts that output for your contract or regulator.
Questions buyers ask about the CM-9 plan
How much effort does a CM-9 configuration management plan take?
The effort depends on how many systems the plan covers, how many configuration items it must define, and how much of the process already exists in writing. A plan is a document, but it has to describe working processes, so the work is mostly interviews, process mapping and agreeing on who approves what. The cost components are the people who gather the facts and draft the plan, the reviewers who approve it, and any tooling changes needed to make the stated process real. Most of this is one-time work, while reviews and plan updates recur whenever the system or its life cycle changes. Ask any quote to split effort by activity: discovery, drafting, approval and handover of the plan.
Can our own team write the CM-9 plan in-house?
Yes, an internal team can write the CM-9 plan, provided it has people who know the system's life cycle, its change process and its owners. The organization always owns the plan and its approval, because CM-9 requires review and approval by defined personnel. An implementation partner can help by preparing the system documentation, drafting the plan from interviews and reconciling it with tools already in use. Independent assessors test the plan later, but they do not write or approve it for you. If your team lacks time or experience with configuration management, outside help usually goes to drafting and gap review rather than ownership.
How long does a CM-9 plan take, and what drives that time?
No duration is fixed for this work, so ask any provider for a timeline tied to a written scope rather than a generic estimate. The main drivers are the number of systems and components in scope, whether configuration items are already identified, how many teams must agree on the process, and how quickly approvers can review drafts. Plans for a single well-documented system move faster than plans that span several environments with separate change boards. Delays usually come from unresolved ownership questions, not from writing. Agree on review cycles and approval dates in the scope so the schedule depends on named people.
What does the client team need to provide for the plan?
The client team needs to provide access to the people and records that describe how the system is built and changed. In practice this means system design documentation, the current system security plan, the existing policies and procedures for configuration management, and named personnel who develop and approve the plan. Access to change records and inventory data helps show how configuration items are actually tracked. The team also needs time from approvers and a decision on which life cycle stages the plan covers. Missing inputs are the most common reason a written plan is delayed, so list them in the scope before work starts.
Does a CM-9 plan alone satisfy the control without other CM controls?
A plan alone does not show that configuration management works. CM-9 asks for a plan that names roles, identifies configuration items and is approved and protected, but assessors also check whether the processes it describes operate. The plan is closely tied to CM-2 baseline configurations, CM-3 change control, CM-4 impact analyses, CM-6 configuration settings and CM-8 component inventory, which the plan should reference. Evidence from those controls, such as change records and an inventory, is what shows the plan is followed. Build the plan with those sibling controls in view so the document matches the records an assessor will sample.
What should a written scope for CM-9 work include?
A written scope should name the systems covered, the life cycle stages the plan addresses, the configuration items in scope, the roles the plan must define, and the approvers who will sign it off. It should list deliverables, such as the draft plan, the review record and the protection measures for the document, and state which party performs each step. Ask the provider to state what the organization must supply, what is excluded, and how revisions after approval are handled. Fixed-scope agreements of this kind are how DeployOpen usually works, and the quote should follow directly from that written scope. Independent assessment is a separate engagement with a separate party.
How DeployOpen prepares the CM-9 plan and its evidence
DeployOpen helps organizations prepare a configuration management plan for their own systems and the evidence an assessor will examine against CM-9. The organization owns the plan and its approval, while DeployOpen prepares the documents, tooling and records, and an independent assessor tests the result.
How we scope
- Engagements are fixed-scope, with the systems, owners and life cycle stages covered by the plan agreed in writing first.
- The written scope names which configuration items the plan will define and which roles approve it.
- Scope also confirms how the plan links to the system security plan and related CM controls, such as CM-2 and CM-8.
How we build
- We draft the plan with the organization's named roles, responsibilities and processes for each life cycle stage.
- We set up the open-source tools that hold configuration items, change tickets and versioned plan documents.
- We map each plan element to the CM-9 determination statements so the assessor can trace each one to evidence.
How we hand over
- Handover includes the approved plan, its revision history and records showing review and approval by defined personnel.
- Access controls on the plan repository are documented so protection from unauthorized disclosure and change can be examined.
- The organization receives runbooks explaining how to keep the plan current and who must sign off each revision.
How we support
- Ongoing support and upgrades are available as a retainer, covering plan revisions as systems and life cycle processes change.
- Retainers can include periodic reviews of plan records before an assessor requests them.
- Confirm with DeployOpen whether a retainer covers tool upgrades, plan reviews and evidence refreshes, and what each costs in the written quote.
