Change control process: the route from request to release

A change control process is the route a proposed change takes from someone wanting it to it being live and recorded. Every organisation has one, whether it is written down or not; the unwritten version is usually "ask whoever owns the system, and if they are busy, do it anyway". The written version exists so that the risk of a change is assessed by someone other than the person who wants it, and so that when something breaks at two in the morning the first question — what changed — has an answer.

The stages of a change control process

1. Request: what is changing, why, and what happens if it does not. A change request that cannot answer the third question is usually a preference.
2. Assessment: technical impact, business impact, dependencies, and the effort to reverse it. This is the stage most often skipped under time pressure.
3. Categorisation: standard, normal or emergency. Getting this right is what keeps the process proportionate — routing a password reset through the same path as a database migration discredits the whole thing.
4. Approval: by an authority proportionate to the risk, which for significant changes is the change advisory board and for routine ones is a pre-agreed standing approval.
5. Scheduling: when, in what window, and what else is happening at the same time.
6. Implementation with a rollback plan that someone has actually read.
7. Verification and closure, recording what was done and whether it worked.

Making it proportionate

• Pre-approve standard changes — low-risk, well-understood, done often — with a documented procedure rather than an approval each time.
• Define emergency change properly, including who can invoke it and the requirement to document retrospectively within a set period. Emergency routes that are never reviewed become the normal route.
• Set the approval threshold by risk, not by cost. A cheap change to a customer-facing system outranks an expensive one to a test environment.
• Keep a change freeze available for peak periods, and write down in advance what still gets through.
• Measure the proportion of changes that fail or are rolled back. A process with no failures is either excellent or not capturing everything, and the second is more common.

The record is the deliverable, not the approval. Approval protects the organisation before the change; the record protects it afterwards, when an incident investigation needs to know what moved in the last twenty-four hours. A process that approves diligently and records loosely has bought the less valuable half.

Where it goes wrong

• Approval as a formality: a board that reviews forty changes in twenty minutes has approved nothing meaningfully.
• Changes made outside the process because the process is too slow, which is a design problem rather than a discipline problem.
• No rollback plan, or one that has never been tested — the two are almost equivalent in practice.
• Unbundled changes bundled: five unrelated changes in one release window, so a failure cannot be attributed.
• The link to incidents never made, so problem management never learns which changes cause outages.
• Product and engineering changes handled under a separate scheme with different rules, which is legitimate — an engineering change order has different concerns — but should be a stated boundary rather than a gap.

Where the process lives

Ettex Forms gives the request a consistent shape — what, why, impact, rollback, requested window — so that assessment starts from complete information rather than a chat message. Each submission becomes a dated record with the approval, the outcome and the verification attached, which is the change history an incident investigation needs. Ettex is not a change management platform and does not integrate with deployment tooling or a CMDB; where changes are frequent and automated, that integration is the point and a dedicated ITSM tool is the answer. What this replaces is the process that exists only in a wiki page.