Change management

Most change processes descend from ITIL, which classifies changes into three types. Standard changes are low-risk, pre-authorised and repeatable (adding a user to a group, a routine certificate renewal) and follow a documented procedure without individual approval. Normal changes are assessed and authorised case by case, by a change authority whose level scales with risk - a peer, a team lead or a change advisory board (CAB). Emergency changes are expedited to fix an incident or close an actively exploited hole, with reduced up-front approval and mandatory retrospective review. ITIL 4 renamed the practice change enablement and deliberately decoupled authority from the CAB meeting, recognising that a weekly board is a bottleneck for high-frequency delivery.

A well-formed change record contains the scope and affected configuration items (which is why the process depends on an asset inventory or CMDB), a risk and impact assessment, a test result, an implementation window, a tested backout plan, and post-implementation verification. The security value lies in three properties: segregation of duties (the requester is not the sole approver), traceability (every production difference maps to an authorised record) and detection of unauthorised change, typically by comparing configuration baselines, file integrity monitoring or infrastructure-as-code drift detection against approved state.

In DevOps and GitOps environments the same control objectives are met by the pipeline rather than by a meeting: a pull request with mandatory peer review and branch protection is the change request and approval, automated tests are the impact assessment, the merge commit is the audit trail, and progressive delivery with automated rollback is the backout plan. The research published in Accelerate (Forsgren, Humble and Kim, 2018) found that approval by an external body such as a CAB was negatively correlated with delivery performance and not correlated with lower change failure rates - an argument for lightweight, peer-based approval backed by automation, not for dropping control.

Normative references: ISO/IEC 27002:2022 control 8.32 (change management), closely tied to 8.9 (configuration management); ISO/IEC 20000-1 for service management; and, not to be confused with operational change, ISO/IEC 27001:2022 clause 6.3, which requires changes to the ISMS itself to be planned. Auditors test it by sampling production changes from system logs and tracing each back to an approved record; unrecorded changes, self-approved changes and emergency changes that never got their retrospective review are the classic findings. Many outages attributed to "configuration errors" - including cloud misconfigurations that expose storage publicly - are change-management failures in this sense.