Skip to main content

Change Management

change-management · tx-change-management

Controlled, reviewed, tested paths from code change to production — PR-based flow, CI gates, review requirements, deploy pipelines, migration discipline — where the defect is an ungoverned change path.

Change management

The change-path layer: how code gets from a developer's editor to production, and which gates it must clear on the way.

In scope. PR-based workflow evidence (CODEOWNERS, review requirements, branch-protection configuration committed as code), CI gates that block merges or deploys (tests, linting, type checks, security scans), deploy pipelines defined in the repo rather than run ad hoc, database-migration discipline (tested, reversible, never edited after application), pinned third-party build dependencies (actions, orbs, container base images), and environment separation between staging and production.

Not in scope. What the pipeline scans for — a secret-scanning gate is change-management (the gate exists in the pipeline) plus cryptography-and-secrets (the mechanism); the underlying vulnerability class belongs to its own mechanism taxon. Package-registry trust and dependency provenance are supply-chain. Runtime deployment health is operational-readiness.

Distinct because. The defect is "changes reach production without a controlled, reviewable path" — the harm is process-shaped, not a single exploitable bug. This is the most heavily audited technical territory in compliance frameworks (SOC 2 CC8.1, ISO 27001 A.8.32, CMMC CM practices): an auditor's first question is "show me how a change ships."

Conceptual sub-structure. Review gates, CI verification gates, deploy-path integrity, migration discipline, build-input pinning.

Patterns in this taxon (4)