{"id":107,"date":"2026-10-12T07:11:24","date_gmt":"2026-10-12T07:11:24","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2009\/01\/13\/the-four-basic-requirements-for-an-scm\/"},"modified":"2026-10-12T07:11:24","modified_gmt":"2026-10-12T07:11:24","slug":"the-four-basic-requirements-for-an-scm","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/the-four-basic-requirements-for-an-scm\/","title":{"rendered":"The 4 Core SCM Requirements: Identification, Control, Auditing, and Status Accounting"},"content":{"rendered":"\n

Originally published on 2009-01-13; fully revised and updated.<\/em><\/p>\n\n\n\n

Software Configuration Management (SCM) is the discipline that keeps software changes traceable, controlled, and recoverable over time. This article explains the four foundational SCM requirements and how engineering teams can implement them with practical processes and tooling. For historical context, see the original post<\/a>.<\/p>\n\n\n

\n
\"Four<\/figure>\n<\/div>\n\n\n

The four SCM requirements at a glance<\/h2>\n\n\n\n

The original SCM guidance is still valid: regardless of whether your process is mostly manual or highly automated, you need all four capabilities to manage releases safely.<\/p>\n\n\n\n

Requirement<\/th>Primary question it answers<\/th>Typical evidence<\/th>Risk if missing<\/th><\/tr><\/thead>
Identification<\/td>What exactly is in this release?<\/td>Version labels, tags, baselines, bill of materials<\/td>Cannot determine impacted releases or components<\/td><\/tr>
Control<\/td>Was this change reviewed and approved?<\/td>Change requests, approvals, branch\/merge history<\/td>Untracked or risky changes enter production<\/td><\/tr>
Auditing<\/td>Was the approved change implemented correctly?<\/td>Audit trail, test evidence, release verification<\/td>Mismatch between intent and delivered software<\/td><\/tr>
Status accounting<\/td>What changed, when, and why?<\/td>Reports, release notes, configuration records<\/td>Poor traceability and weak planning metrics<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

1) Identification: define and label configuration items<\/h2>\n\n\n\n

Identification<\/strong> means every relevant software part can be uniquely recognized across versions. In practice, this includes source code, dependencies, build scripts, infrastructure definitions, and release artifacts. The goal is to reconstruct any shipped configuration item without guesswork.<\/p>\n\n\n\n

A useful mental model is a software bill of materials for each release baseline: if a defect appears, the team can quickly identify all versions and products that contain the affected component.<\/p>\n\n\n\n

2) Control: evaluate and authorize change<\/h2>\n\n\n\n

Control<\/strong> means proposed changes to configuration items are reviewed before being accepted into a baseline. This is where technical and business impact are considered: compatibility, risk, schedule, and downstream dependencies.<\/p>\n\n\n\n

Without control, a fix for one customer or platform can unintentionally break another. With control, teams can decide deliberately and preserve release integrity.<\/p>\n\n\n\n

3) Auditing: confirm implementation matches approval<\/h2>\n\n\n\n

Auditing<\/strong> verifies that approved changes were actually implemented and that resulting configurations conform to requirements. Audits rely on traceable records: what was requested, what was changed, and what was released.<\/p>\n\n\n\n

When documentation and traceability are consistently maintained, audits become straightforward and reliable instead of ad hoc investigations.<\/p>\n\n\n\n

4) Status accounting: maintain the project memory<\/h2>\n\n\n\n

Status accounting<\/strong> is the reporting function of SCM. It records the lifecycle of each approved change and each configuration item transition (for example, from one baseline version to the next).<\/p>\n\n\n\n

These records support audits, incident response, and management decisions. They also provide historical data that helps teams estimate future work and improve delivery predictability.<\/p>\n\n\n\n

How the four requirements work together in a change lifecycle<\/h2>\n\n\n\n
\nflowchart TD\n    A[Change request opened] --> B[Identify affected configuration items]\n    B --> C{Change approved}\n    C -- no --> D[Rework or close request]\n    C -- yes --> E[Implement and commit change]\n    E --> F[Audit against approved scope]\n    F --> G[Update status records and release notes]\n    G --> H[Create or update release baseline]\n<\/pre>\n\n\n\n
Practical example using Git-based workflows<\/h2>\n\n\n\n
The commands below are illustrative examples of how modern teams often implement classic SCM requirements. The SCM principles are tool-agnostic; Git is one common implementation.<\/p>\n\n\n
# Identification<\/span>: create<\/span> a<\/span> release<\/span> baseline<\/span> and<\/span> capture<\/span> artifact<\/span> list<\/span>\ngit<\/span> tag<\/span> -a<\/span> v2<\/span>.3<\/span>.1<\/span> -m<\/span> \"Release<\/span> baseline<\/span> v2<\/span>.3<\/span>.1<\/span>\"\ngit<\/span> ls-tree<\/span> -r<\/span> --name-only<\/span> v2<\/span>.3<\/span>.1<\/span> > release-v2<\/span>.3<\/span>.1-bom<\/span>.txt<\/span><\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n
# Control: isolate and review a hotfix before merging<\/span>\ngit switch<\/span> -c hotfix\/linux-audio-driver v2.3<\/span>.1<\/span>\ngit commit -am \"Fix buffer handling in Linux audio driver\"<\/span>\ngit push origin hotfix\/linux-audio-driver<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n
# Auditing and status accounting: verify delta and tag approved release<\/span>\ngit log --oneline --decorate v2.3<\/span>.1<\/span>..hotfix\/linux-audio-driver\ngit tag -a v2.3<\/span>.2<\/span> -m \"Approved hotfix release\"<\/span>\ngit show --name-status v2.3<\/span>.2<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Best practices and common pitfalls<\/h2>\n\n\n\n
  • Define configuration items explicitly; do not limit SCM to source code only.<\/li>
  • Treat release baselines as immutable references for traceability.<\/li>
  • Require documented approval paths for production-impacting changes.<\/li>
  • Audit both process compliance and technical correctness.<\/li>
  • Keep status accounting lightweight but complete: who, what, when, why, and where released.<\/li>
  • Avoid tool-first thinking; start with SCM policy, then implement with tools.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
    Software Configuration Management depends on four non-negotiable capabilities: identification, control, auditing, and status accounting. This guide explains each requirement and shows how to apply them in modern DevOps workflows.<\/p>\n","protected":false},"author":1,"featured_media":3960,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[1707,1122,2903,593,2444,397,2895,2776,2899,2904,2900,2901,2435,2902,213,670],"class_list":["post-107","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorised","tag-basic","tag-guide","tag-prerequisite","tag-process","tag-requirements","tag-scm","tag-scm-guide","tag-scm-process","tag-scm-process-basic-requirements","tag-scm-process-prerequisite","tag-scm-process-requirements","tag-scm-tutorial","tag-software-configuration-management","tag-software-configuration-management-system-requirements","tag-tutorial","tag-what"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/107","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=107"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/107\/revisions"}],"predecessor-version":[{"id":78932,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/107\/revisions\/78932"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3960"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}