Configuration Management Plan: What It Is, the Template, and a Full Example

Quick answer: A configuration management plan is a document that says how you will control the parts of your project. It lists which items are controlled, who can change them, how changes get approved, and how you check that what you built matches what was approved. It stops uncontrolled changes breaking things.

Imagine a big Lego model with 500 pieces, built by six people over three months.

Now imagine someone quietly swaps a piece in the middle, and tells nobody. Two weeks later the model doesn’t fit together, and nobody can remember what changed or when.

That is what happens to projects without configuration management. This guide shows you how to stop it, with a template you can copy and a full worked example.

Quick signpost. “Configuration management” means different things in different jobs. This guide covers the project and engineering version — the document that controls your project’s parts. If you meant server setup tools like Ansible or Puppet, or the CMDB in a service desk, jump to the IT service management and DevOps section.

What Is Configuration Management?

Configuration management is the practice of keeping control of the important parts of a product or project. You always know what exists, what version it is, and who approved the last change.

It answers four questions at any moment:

1. What are the parts of this thing?
2. Which version of each part is the approved one?
3. Who changed what, when, and why?
4. Does what we actually built match what was approved?

Most projects can answer question 1. Far fewer can answer all four, and question 4 is where the expensive surprises live.

What is a configuration item?

A configuration item, usually shortened to CI, is any part of your project that is formally controlled.

A CI might be a document, a piece of software, a database design, a drawing, a server setup, or a physical part. If changing it without permission could cause a problem, it should probably be a CI.

Each CI gets an ID, an owner, and a version number. That sounds like paperwork, and it is — but it’s the paperwork that lets you answer “which version is live?” without a two-hour meeting.

What Is a Configuration Management Plan?

A configuration management plan, often called a CMP, is the document that explains how configuration management will work on your project.

It is the rulebook. It does not list every change. It says how changes are handled.

A good CMP answers these questions in writing:

Question	Where it’s answered
What is under control?	Configuration identification section
Who can approve a change?	Change control section
How do we request a change?	Change control section
Where is everything recorded?	Status accounting section
How do we check we got it right?	Audit section
Who does all this?	Roles and responsibilities section

Who writes and approves it?

The configuration manager writes it, or the project manager on smaller projects. It’s usually approved by the project sponsor and, in regulated work, a quality or compliance lead.

Write it early — during planning, before any baseline is set. A CMP written halfway through the build is written to describe the mess you already have, not to prevent it.

Configuration Management vs Change Management vs Version Control: What Is the Difference?

These four terms get used as if they mean the same thing. They don’t.

Term	What it covers	Example
Configuration management	Knowing what all the controlled parts are and which version is approved	“The live portal is running release 3.2, built from these 14 controlled items”
Change management (technical)	The process for requesting, reviewing and approving a change to those parts	“Change request CR-042 was approved on 14 October”
Change management (organisational)	Helping people adapt to a new way of working	“Training 200 staff on the new system”
Version control	The tool that stores each version of a file and its history	Git, SVN
Release management	Packaging approved changes and getting them into live use	“Release 3.2 goes live on Friday at 8pm”

Two things worth remembering:

• Configuration management is bigger than version control. Git tracks your code. It does not track your requirements document, your server settings, or your approved design drawings.
• “Change management” means two completely different things. In configuration management it means the approval process. In business it means helping people cope with change. Always check which one someone means.

Why Do You Need a Configuration Management Plan?

Without one, five things go wrong, and they usually go wrong together:

• Nobody knows which version is live. Two people fix the same bug in different copies.
• Changes appear that nobody approved. They work on one machine and break another.
• Testing tests the wrong thing. The test team uses version 2.1 while development moved to 2.3.
• You cannot roll back. Something breaks and there’s no known-good version to return to.
• You cannot prove anything to an auditor. In regulated work, this is a serious problem on its own.

When can you skip a formal CMP?

• Very small projects with one or two people and a short timeline
• Projects with no external oversight and no regulatory requirement
• Work where your existing tools already enforce control well enough

Even then, write half a page. Say what’s controlled, who approves changes, and where things are stored. That half page prevents most of the problems above.

What Are the Four Functions of Configuration Management?

Nearly every standard describes the same four activities, sometimes with a fifth for planning.

#	Function	Plain English	Main output
1	Configuration identification	Decide what’s controlled and name it	CI register, baselines
2	Configuration control	Manage how changes are requested and approved	Change requests, CCB decisions
3	Configuration status accounting	Record and report what’s happened	Status reports, change log
4	Configuration audits	Check reality matches the records	Audit reports

1. Configuration identification

You choose which items are controlled, give each one a unique ID, and record its version.

A simple naming pattern works best. Something like CI-PORTAL-003 v2.1 tells you the project, the item and the version at a glance.

2. Configuration control

This is the approval process. Somebody requests a change, somebody reviews it, and somebody approves or rejects it.

The key rule: once an item is baselined, it can only be changed through this process. No exceptions for small changes, and no exceptions for urgent ones — urgent changes get a faster route, not a way around the process.

3. Configuration status accounting

This is the record keeping. You track the current version of every CI, every change request and its status, and the history of each item.

It sounds dull, and it’s the function people cut first. It’s also the one that answers “what changed between Tuesday and Friday?” when something breaks on Friday.

4. Configuration audits

You check that what exists matches what the records say. There are two types, covered later on this page.

How Do You Choose Configuration Items?

This is the hardest judgement in configuration management planning, and almost no guide covers it.

Control too much and the process collapses — every tiny edit needs approval, so people start working around it. Control too little and you lose track of the things that matter.

Five tests for a configuration item

Make something a CI if you can answer yes to two or more:

1. Would an unapproved change to this cause a real problem?
2. Do several people or teams depend on it?
3. Does it need to be rebuilt or restored exactly, some day?
4. Does a contract, regulator or auditor require control of it?
5. Does it have its own version history that matters?

Usually a CI

Requirements documents · design specifications · source code repositories · database schemas · server and environment configurations · API contracts · third-party components and their versions · test scripts · deployment scripts · user documentation · the release package itself

Usually not a CI

Meeting notes · draft documents still being written · personal working files · internal chat messages · temporary test data · anything already covered as part of a bigger CI

The practical rule

Start with fewer CIs than you think you need, and add more if you find gaps.

A project with 30 well-chosen CIs that people actually maintain beats a project with 300 CIs that everyone quietly ignores by month two.

What Are Baselines?

A baseline is a snapshot of your CIs at a moment in time, formally approved and frozen. After that point, changes need approval.

Think of it as saving your game. You can carry on playing, but you can always get back to that exact point.

The three classic baselines

Baseline	Set when	What it captures
Functional	Requirements are agreed	What the product must do
Allocated	Design is approved	How those requirements are split across parts
Product	The build is finished and verified	What was actually built and delivered

These names come from engineering work. On an IT project you’ll often see simpler names instead:

Baseline	Typical trigger
Requirements baseline	Requirements document signed off
Design baseline	Technical design approved
Development baseline	Code complete, ready for testing
Release baseline	Approved for live use

The names matter less than the principle: before a baseline, changes are cheap and informal. After it, they go through the process.

Baselines line up neatly with the phase gates in a waterfall project — each gate usually sets one.

How Does the Change Control Board Work?

The change control board, or CCB, is the group that decides whether a change to a baselined item goes ahead.

Who sits on it?

Keep it small. Four to six people is usually right:

Role	Why they’re there
Chair (project or configuration manager)	Runs the meeting, makes the call when needed
Technical lead	Says whether it can be done, and what it breaks
Business or product owner	Says whether it’s worth doing
Quality or test lead	Says what re-testing it triggers
Finance or contracts (when needed)	Says who pays

How a change request flows

1. Someone raises a change request with a description and a reason
2. The configuration manager logs it and gives it a number
3. The technical lead assesses impact: cost, time, risk, what else it touches
4. The CCB reviews it and decides
5. The decision is recorded, with the reason
6. If approved, the work is done and the CI version is updated
7. The change log is updated, and affected people are told

Step 5 is the one teams skip. Six months later, nobody remembers why a request was rejected, so someone raises it again.

Classify changes so small ones move fast

Not every change needs a full board meeting. Three classes work well:

Class	What it means	Who approves	Typical time
Major	Affects scope, cost, deadline, or a contract	Full CCB, plus sponsor	Next scheduled meeting
Minor	Affects a baselined item, but not scope or cost	Configuration manager plus technical lead	2 working days
Administrative	Typos, formatting, clarifications with no technical effect	Document owner	Same day

Without classes, everything queues behind the board meeting, and people start making changes quietly instead. The classes are what keep the process usable.

Emergency changes

Agree the emergency route in advance. A common rule: the technical lead and one other person can approve it on the spot. It then goes to the next CCB meeting for the record.

An emergency route that exists is far safer than one people invent under pressure.

What Are the 10 Sections of a Configuration Management Plan?

#	Section	What goes in it
1	Purpose and scope	What this plan covers, and what it doesn’t
2	Roles and responsibilities	Who does what, by name or role
3	Configuration identification	How CIs are chosen, named and numbered
4	Configuration items list	The CI register, or where it lives
5	Baselines	Which baselines exist and when they’re set
6	Change control	The request process, classes and the CCB
7	Status accounting	What’s recorded and reported, and how often
8	Audits	Types, timing and who runs them
9	Tools and storage	Where everything lives, and access rules
10	Interfaces and suppliers	How supplier items are controlled

Keep it to 6–12 pages for most projects. A CMP nobody reads controls nothing.

How to Write a Configuration Management Plan for IT Projects

IT projects have their own shape. Here are the seven steps, with the IT specifics called out.

Step 1: Define the scope

Say which systems, environments and documents this plan covers. On IT projects, be clear about environments. Development, test, staging and production are often treated differently. Pretending they’re the same causes most of the trouble.

Step 2: Choose your configuration items

Use the five tests above. For IT projects, remember the items that live outside your code repository. That means server configurations, environment variables, database schemas, API contracts, third-party library versions, and infrastructure definitions.

Third-party libraries deserve special attention. A dependency that silently updates is an unapproved change to your product.

Step 3: Set your naming and numbering rules

Pick a pattern and write it down. Decide how version numbers work — many IT teams use semantic versioning, where 2.4.1 means major.minor.patch.

Step 4: Define your baselines

Name each baseline, say what triggers it, and say who approves it. Link them to your project’s phase gates or release milestones.

Step 5: Design the change process

Write the change request form, the three change classes, the CCB membership, and the meeting frequency. Weekly works for most active IT projects.

Step 6: Decide tools and storage

Say which tool holds what: the repository for code, the tracker for change requests, the wiki or document store for specifications. Say who has write access to each.

The rule that matters: one source of truth per item type. Two half-maintained lists are worse than one.

Step 7: Plan your audits

Schedule them. A short check before each release beats a big audit at the end, when fixing anything is expensive.

Your CMP should connect to your deployment plan, since the release baseline is exactly what gets deployed.

What Goes in the Configuration Management Plan Template?

Copy this and fill it in.

CONFIGURATION MANAGEMENT PLAN

Project:
Document version:              Date:
Author:                        Approved by:
Next review date:

1. PURPOSE AND SCOPE
   Why this plan exists.
   Systems, documents and environments covered:
   Explicitly NOT covered:

2. ROLES AND RESPONSIBILITIES
   | Role | Name | Responsibility |
   | Configuration manager |  | Owns this plan and the CI register |
   | Project manager |  | Chairs the CCB |
   | Technical lead |  | Assesses change impact |
   | Quality / test lead |  | Runs audits, confirms re-testing |
   | Document owners |  | Maintain their own CIs |

3. CONFIGURATION IDENTIFICATION
   How we decide what becomes a CI:
   Naming convention:            Example: CI-XXXX-000
   Version numbering:            Example: major.minor.patch

4. CONFIGURATION ITEMS
   | CI ID | Item | Type | Owner | Current version | Storage location |

5. BASELINES
   | Baseline | Trigger | Approved by | Date set |

6. CHANGE CONTROL
   How to raise a change request:
   Change classes:
     Major — approved by:
     Minor — approved by:
     Administrative — approved by:
   Emergency change route:
   CCB members:                  CCB meets:
   Records kept in:

7. STATUS ACCOUNTING
   What we record for each CI:
   Reports produced:             Frequency:            Sent to:

8. AUDITS
   | Audit type | When | Run by | Output |

9. TOOLS AND STORAGE
   | Item type | Tool | Who has write access |

10. INTERFACES AND SUPPLIERS
    Supplier-provided items under control:
    How supplier changes are notified and approved:
    Shared interfaces and who owns each:

APPROVAL
   Name:               Signature:            Date:

What Does a Completed Configuration Management Plan Look Like?

Here is a filled example. The project replaces the customer portal at a mid-size insurance company, running 8 months with a team of 11.

Section 3 — identification rules

• Naming: CI-PORT-###, numbered in the order items are registered
• Versions: major.minor.patch. Major = breaking change, minor = new feature, patch = fix
• New CIs are approved by the configuration manager and added to the register within 2 working days

Section 4 — configuration items (extract)

CI ID	Item	Type	Owner	Version	Location
CI-PORT-001	Requirements specification	Document	Business analyst	3.2	Document store
CI-PORT-002	Technical design specification	Document	Technical lead	2.4	Document store
CI-PORT-004	Portal front-end source	Code	Dev lead	3.1.0	Git repository
CI-PORT-005	Portal API source	Code	Dev lead	3.1.2	Git repository
CI-PORT-006	Database schema	Schema	Data engineer	1.9	Git repository
CI-PORT-009	Production server configuration	Config	Infrastructure lead	2.0	Config repository
CI-PORT-012	Third-party payment library	Dependency	Dev lead	4.7.1	Dependency file
CI-PORT-015	Regression test suite	Tests	QA lead	2.2	Git repository

Total: 23 configuration items.

Section 5 — baselines

Baseline	Trigger	Approved by	Date set
Requirements	Requirements spec signed	Sponsor	14 March
Design	Technical design approved	Technical lead and sponsor	22 April
Development	Code complete, unit tests passing	Dev lead	30 July
Release 3.1	Testing complete, defects closed	CCB	9 September

Section 6 — change control in action

The CCB met weekly on Tuesdays. Over the project it handled 61 change requests.

Class	Requests	Approved	Rejected	Deferred
Major	9	5	3	1
Minor	34	31	2	1
Administrative	18	18	0	0
Total	61	54	5	2

A sample entry from the change log:

CR-038 · Raised 3 August by the QA lead · Class: major Request: Add two-factor authentication at login. Impact: 12 developer days, affects CI-PORT-004, 005 and 015. Pushes the release baseline by 1 week. Decision: Approved 5 August. The sponsor accepted the one-week delay because the insurer’s security policy required it before go-live. Result: Implemented. CI-PORT-004 moved to 3.1.0, CI-PORT-015 to 2.2.

What the plan caught

During the pre-release audit, the team found that the production server configuration on file (CI-PORT-009 v2.0) did not match the live server. Someone had increased a session timeout directly on the server in June, without a change request.

It was a small change and it worked fine. But it wasn’t in the records. So if the server had ever been rebuilt from the approved configuration, the setting would have quietly disappeared.

The lesson recorded: direct changes to live servers were the one gap in the process. The team added a monthly automated comparison between the recorded configuration and the actual server, and a rule that any live fix must be logged within 24 hours.

Examples of Configuration Management Plans for Software Development

Software projects follow the same four functions, but the items and tools differ. Here is what a software CMP typically controls.

Area	Configuration items	Usually stored in
Code	Application source, libraries you wrote, build scripts	Git repository
Dependencies	Third-party packages with exact versions	Lock file in the repository
Data	Database schema, migration scripts, reference data	Repository
Infrastructure	Server configuration, container definitions, infrastructure as code	Configuration repository
Documents	Requirements, technical design spec, API documentation	Document store or wiki
Tests	Test plans, automated test suites, test data sets	Repository
Releases	Built artefacts, release notes, rollback package	Artefact store

Three software-specific rules worth writing into the plan

1. Pin your dependencies. Record exact versions, not ranges. A library that updates itself is a change to your product that nobody approved.

2. Treat infrastructure as a configuration item. If your servers are defined in code, that code is a CI. If they’re configured by hand, write down the configuration and check it regularly — as the example above shows, this is where gaps usually appear.

3. Say which branch is the baseline. Most teams use the main branch as the current approved state, with releases tagged. Write that down rather than assuming everyone knows.

A note on agile projects

Configuration management still applies to agile work. What changes is the rhythm, not the principle.

Instead of a few big baselines, each release or increment becomes one. Instead of a weekly board meeting, the product owner handles most decisions and the board handles anything touching architecture, security, contracts or cost.

The rule stays the same: once something is released, changing it goes through a process.

What Are Configuration Audits?

An audit checks that reality matches the records. There are two types.

	Functional configuration audit (FCA)	Physical configuration audit (PCA)
Question it answers	Does it do what the requirements said?	Does the built item match its documentation?
Compares	Test results against requirements	The actual product against its records
Typically finds	Requirements not met, untested features	Wrong versions, undocumented changes, missing files
When	Before acceptance	Before release or handover

On IT projects, a light version of both fits into pre-release checks:

• Functional check: every requirement has a test, and every test passed.
• Physical check: the release contains the exact CI versions the records say, and nothing else.

Two rules for audits that actually help:

1. Run small ones often. A 30-minute check before each release finds problems while they’re cheap.
2. Write down what you found, even when it’s fine. “Audited 9 September, no discrepancies” is evidence. A missing record is not.

Where to Find Templates for Configuration Management Plans

You have five good sources:

• The template on this page. Copy it straight into your document. It covers the ten standard sections.
• Government and agency templates. Bodies such as the US Defense Acquisition University, NASA and the Federal Highway Administration publish CMP templates as free Word documents. They’re thorough and heavily engineering-focused, so expect to delete a lot for a small IT project.
• Standards bodies. SAE EIA-649 and ISO 10007 describe what a CMP should contain. The standards themselves are paid documents, but summaries of their structure are widely available.
• Your own organisation. Ask your PMO or quality team. Many companies already have an approved CMP template you’re expected to use, and using theirs saves an approval round.
• Your project tool’s template gallery. Search it for “configuration management” or “change control”.

Whichever you start from, cut it down. A template written for a defence programme asks for things a 6-month web project will never need. And an over-long CMP is one nobody follows.

Best Software Tools to Create a Configuration Management Plan

Two different jobs get confused here, so let’s separate them.

Writing the plan is a document job. Doing the configuration management is a tooling job.

Job	What to look for	Type of tool
Writing the CMP document	Templates, version history, shared editing, approvals	Document and wiki tools, plus AI writing assistants
Holding the CI register	Custom fields, filtering, ownership, version columns	Spreadsheets, or a project platform with custom fields
Tracking change requests	Workflow states, approvers, linked items, audit trail	Issue trackers and project management platforms
Version control for code and configs	Branching, history, tags, access control	Git-based repositories
Environment and server configuration	Defined as code, repeatable, drift detection	Infrastructure as code and configuration tools
IT service configuration	A CMDB with relationships between items	ITSM platforms

Four features matter more than the brand:

• An audit trail you cannot edit. If someone can quietly change history, the records prove nothing.
• Linking. A change request should link to the CIs it affects.
• Access control per item type. Not everyone should be able to change a baseline.
• Export. Auditors will ask for a report, and you don’t want to build it by hand.

One warning: don’t buy a tool to solve a process problem. Decide what’s controlled and who approves changes first. A tool applied to an undefined process just automates confusion.

Which Standards Cover Configuration Management Planning?

Standard	What it covers	Who uses it
SAE EIA-649	The general consensus standard for configuration management principles	Industry-wide, defence, aerospace
ISO 10007	Guidance on configuration management within a quality system	Organisations working to ISO 9001
IEEE 828	Configuration management plans for software and systems	Software and systems engineering
MIL-HDBK-61A(SE)	US Department of Defense guidance handbook	Defence programmes

One correction worth knowing

Some older guides still tell you to write your CMP to MIL-STD-973. That standard was cancelled. The US Department of Defense published the cancellation notice in 2001 and moved to commercial standards. MIL-HDBK-61A(SE) became the guidance handbook, and SAE EIA-649 the consensus standard.

If a template you download references MIL-STD-973 as current, that template has not been updated in a long time. Check the rest of it carefully.

You rarely need to follow a standard exactly unless a contract requires it. What matters is that your plan covers the four functions properly.

Configuration Management in IT Service Management and DevOps

If you came here for one of these, this section is your signpost.

IT service management (ITIL)

In a service desk, configuration management means maintaining a configuration management database, or CMDB. It records the IT assets in your live estate — servers, applications, services — and how they connect.

Its purpose is different from a project CMP. A CMDB answers “if this server fails, what breaks?” A project CMP answers “which version did we approve, and who changed it?”

Many organisations need both.

DevOps and infrastructure as code

In DevOps, configuration management usually means tools that set up servers automatically from code. You define the state you want, and the tool enforces it.

This is configuration management in the true sense. It keeps systems in a known, controlled state. If a system drifts away from that state, the tool spots it and corrects it.

The overlap with a project CMP is real. The code that defines your infrastructure should be a configuration item in your plan, with its own version control and change approval. The tool enforces the state; the plan says who is allowed to change what that state should be.

What Are the 8 Most Common Configuration Management Mistakes?

1. Writing the plan too late. A CMP written mid-build documents the mess instead of preventing it.
2. Controlling too many items. People work around a process that slows everything down.
3. No change classes. Everything queues behind the board, so small changes get made quietly.
4. Forgetting non-code items. Server settings, schemas and dependencies cause more incidents than code does.
5. Not recording rejections. The same request comes back in six months and nobody remembers why it was refused.
6. Skipping audits until the end. The problems are the same; fixing them is far more expensive.
7. Two sources of truth. A spreadsheet and a tool, both half-updated, is worse than either alone.
8. Buying a tool instead of defining a process. The tool will faithfully automate whatever confusion you give it.

How Does Writegenic AI Fit In?

A configuration management plan is a structured document with predictable sections — purpose, roles, identification rules, change control, audits. That structure is exactly what AI drafting handles well.

Writegenic AI can help you:

• Draft the full CMP from a short description of your project
• Write the change request form and the change classification rules
• Turn CCB meeting notes into properly worded decision records
• Produce the status accounting report from your change log
• Rewrite a heavy government template into plain language for your team
• Draft the audit report from your findings

It pairs with the other project documents you’ll need: the technical design specification, the deployment plan, and the scope management plan.

Explore AI for project management, browse the project management tools, or use the prompt generator to write sharper instructions.

Draft with the tool, keep the judgement. AI can produce a complete, well-structured plan in minutes. It cannot decide which 23 items matter on your project, who should sit on your board, or which of your suppliers needs watching. Those choices are the plan. Everything else is formatting.

Try Writegenic AI free

Frequently Asked Questions

Related reading:

• Technical Design Specification: Template + Example
• Deployment Plan: AI-Powered Precision
• Scope Management Plan Generator
• Waterfall Methodology: 6 Phases, Template + Example
• Project Closure: Checklist + Closure Report Template