Software Configuration Management Plan: [Project or product name]

Complete Software Configuration Management Plan (SCMP). The structure follows the configuration management plan content described in IEEE 828-2012: introduction, SCM management, configuration identification, configuration control, status accounting, audits and reviews, interface control, release management, tools and records. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction
2. SCM management
3. Configuration identification
4. Configuration control
5. Configuration status accounting
6. Configuration audits and reviews
7. Interface control
8. Release management and delivery
9. Supplier and third-party item control
10. SCM tools and infrastructure
11. SCM schedule and resources
12. Records and plan maintenance
13. Glossary and references

1. Introduction

1.1 Purpose

This plan defines how [organisation] identifies, controls, records and audits the configuration of [product name] from project start to [end of support], so that every delivered release can be reproduced and every change can be traced to an approved request.

1.2 Scope

1.3 Key terms

2. SCM management

2.1 Organisation

2.2 Change control board

2.3 Policies

• Every change to a baselined CI is linked to an approved change request or defect ID.
• No direct commits to protected branches; all changes arrive through reviewed pull requests.
• Every release is built by the CI pipeline from a tagged commit; local builds are never shipped.
• Build inputs (dependencies, base images, tools) are pinned and recorded.
• Access to production configuration follows least privilege and is reviewed [quarterly].

3. Configuration identification

3.1 Configuration items

3.2 Naming and versioning conventions

3.3 Baselines

3.4 Branching model

The project uses trunk-based development with short-lived feature branches and a release branch per minor version for stabilisation and patches.

4. Configuration control

4.1 Change classes

4.2 Change request content

Each change request (CR) records: ID, title, requester, date, affected CIs, reason, description, impact analysis (scope, schedule, cost, risk, interfaces, security), priority, CCB decision and date, implementing branch or pull request, verification evidence, and closure date.

4.3 Change control flow

The flow below applies to normal changes. Routine changes skip the CCB step; emergency changes are approved by the chair and ratified afterwards.

4.4 Deviations and waivers

A request to release a CI that does not meet its requirements is handled as a deviation or waiver with CCB approval, an expiry date and a linked corrective change request.

5. Configuration status accounting

Status data is generated from tools wherever possible; manual registers are reconciled against the repository [monthly].

6. Configuration audits and reviews

6.1 Audit checklist (PCA excerpt)

• Release tag points to a commit on the release branch.
• Build was produced by the CI pipeline; provenance attestation present.
• Image digests in the deployment manifest match the registry.
• SBOM generated from the same build and archived.
• Every change since the previous release links to a CR or defect.
• Release notes and installation guide match the delivered version.

Audit findings follow the corrective action process in the SQA plan.

7. Interface control

8. Release management and delivery

8.1 Release types

8.2 Build and packaging

• Builds run in the CI pipeline from a clean checkout of the tag.
• Artifacts are signed [with Sigstore / GPG key ID] and stored in [artifact registry] with immutable tags.
• Build provenance and SBOM are attached to each artifact.
• Builds are reproducible: rebuilding the same tag produces artifacts with the same content hashes, or differences are documented.

8.3 Delivery and deployment

8.4 Rollback

Every release keeps the previous production artifact available. Rollback is a redeploy of the previous tag; database migrations are written to be backward compatible for one release so rollback needs no schema reversal.

9. Supplier and third-party item control

10. SCM tools and infrastructure

11. SCM schedule and resources

12. Records and plan maintenance

This plan is reviewed [at each major release and at least annually]. Changes to it are made by pull request and approved by the CCB.

13. Glossary and references

References: [Project management plan], [SQA plan], [Release plan], [Dependency policy], IEEE 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering.

Standard and licence note

Structure aligned with IEEE 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering, configuration management plan content. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from IEEE for its normative requirements. Template licence: MIT.