Skip to content

CONCEPT Cited by 1 source

Change management

Change management is the organizational process by which a production environment's intended mutations are proposed, reviewed, approved, documented, scheduled, executed, and post-reviewed. In its traditional ITIL / SOX-audited form, it centers on manual approval gates — typically a Change Advisory Board (CAB) — plus change windows, freeze periods, and a change-request ticketing workflow.

What it promises

  • Documented intent: every change has a known proposer, approver, window, and rollback plan.
  • Separation of duties: the person requesting the change is not the person approving it.
  • Risk review: a cross-functional group assesses whether the change is safe before it lands.
  • Audit trail: regulators, auditors, and incident responders can trace "what changed when, and why" — see concepts/audit-trail.

What it actually delivers, per the research

The empirical record on change management in its CAB-driven form, surfaced in the 2023-08-16 High Scalability post, is bleak:

  1. Approval rates are ~100% — UK FCA's multi-firm review of ~1M changes found "CABs approved over 90% of the major changes they reviewed, and in some firms the CAB had not rejected a single change during 2019." A 100% approval rate is definitionally not a risk filter.

  2. External approvals correlate negatively with stability — the DORA / Accelerate research (concepts/dora-metrics) found external approvals are "negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate… worse than having no change approval process at all."

  3. They catch documentation, not risk — "Change management gathers documentation of process conformance, but it doesn't reduce risk in the way that you'd think. It reduces the risk of undocumented changes, but risks in changes that are fully documented can sail through the approval process unnoticed."

Why orgs keep doing it

Two pressures, both structural:

  • Regulatory liability. In the Swedbank case, Finansinspektionen fined the bank SEK 850M (~USD 85M) partly for "insufficient controls" and non-compliance with its own declared process. In the UK and US, fines can attach to individuals as well as orgs. Following the process is the CYA floor even if the process is ineffective.
  • Separation-of-duties audit requirements (SOX, PCI-DSS, ISO 27001): some form of approval-by-a-second-party is mandated, regardless of that process's empirical risk-reduction effect.

The self-referential regulator trap

From the source post: "You said you'd do something to manage risk, it wasn't done, therefore you are in violation." The regulator's framing creates a ratchet: a bank that has a weak change process and no outage is never asked to improve it; a bank that has a documented change process and skips it once gets fined for the skip regardless of whether the process would have caught the fault. The rational response is to add more change controls whether or not they reduce real risk.

What actually reduces risk

The DORA framing, which the FCA data corroborates:

Legacy-systems caveat

The 2023 post explicitly notes that legacy and outsourced financial systems often cannot adopt continuous delivery economically: "Many next generation systems in financial services are so dynamic and distributed that it is really hard to get a handle on the volume of changes occurring." In those settings change management remains the default control, even though its limitations are known. See concepts/legacy-system-risk.

Seen in

Last updated · 319 distilled / 1,201 read