LEARN. PRACTICE. GROW.Concept and mechanism
A change decision needs to be linked to the content that will actually run. Identify artifact version, configuration, dependencies, test results, and approved conditions. A name such as latest does not establish that the current package matches the validated one. If the version changes after review, assess the effect on evidence and authorization. Tools can record review, automated results, and approvals, but their configuration must match the intended control. Do not assume that an approval button guarantees separation of duties, reviewer count, or inability to bypass a protection.
Guided application
In a fictional exercise, a team configures two reviewers for a GitHub environment and believes both must approve. The inspected documentation says one listed reviewer’s approval can suffice; options also exist to prevent self-approval and control administrative bypass. In GitLab, required approval rules must be satisfied, and approval does not itself start the deployment job. These examples show why a Change Manager should confirm actual semantics with platform owners. Check the applicable plan, version, and configuration while preserving traceable evidence. The tool supports the control; acceptance of its design still requires local authority and understanding.
Two names in a list do not by themselves establish two required approvals.
Common pitfalls
Mutable label treated as version; approval without an artifact; assumed configuration; available control treated as active control.
Related topics: Mandate, models, and authorization · Impact, dependencies, and calendar · Readiness and execution decision
Link evidence to the artifact and check the control actually configured.
Reference: Release engineering · NIST SP 800-128 updated October 2019; DORA five-metric model and change approval guidance; vendor documentation inspected 2026-10-01