Change enablement without bureaucracy: standard change models

In many regulated organizations, the change process has a bad reputation. Development teams see it as a queue; infrastructure teams, as one more form; leadership, as a cost needed to pass the audit. None of that is inevitable. The problem is rarely that there is control. It is that the control is the same for everything.

The issue is not control, it is uniform control

ITIL 4 renamed the practice from "change control" to "change enablement". That is not cosmetic. The purpose is to get as many changes as possible to succeed, with risk assessed, the right authorization and a coordinated schedule. The emphasis is on changes happening, and happening well.

When every change goes through the same board, with the same documentation and the same lead time, three predictable things happen. Low-risk changes wait as long as critical ones. The overloaded board reviews each change with less attention. And teams learn to bundle changes into large batches to go through the process less often, which raises the risk of every deployment.

The answer is not to remove review but to scale it. That is what change models are for.

Three types of change

Type	What it is	How it is authorized	Example
Standard	Low-risk, well-understood, repeatable and documented change	Pre-authorized when the model is approved; each execution is only logged	Extending a virtual disk within defined limits
Normal	Change that needs its own assessment and authorization	By the change authority that matches its risk level	Upgrading the database engine version
Emergency	Change that must be implemented as soon as possible, usually to resolve an incident	By a smaller emergency authority, with full documentation afterward	Applying a security patch for an actively exploited vulnerability

Two important clarifications. First, "standard" does not mean "uncontrolled": the control happens once, when the model is approved, and is then checked through periodic audits of executions. Second, emergency changes should be rare. If they make up a large share of the total, it is a sign that the normal process is so slow that teams route around it.

Every emergency change should get a post-implementation review within the following days, built around three questions: was it really an emergency, did the change achieve its goal without side effects, and is the documentation complete. That review does two jobs. It restores the control skipped for urgency, and it produces data to improve the normal process: if many emergency changes come from the same type of incident, there is a problem to manage or a standard change to create.

How to build the standard change catalog

The standard change catalog is the tool with the greatest effect on how the process is perceived. Every change that moves from normal to standard frees time for the board and for the teams. We recommend building it this way:

1. Pull the history. Review the normal changes from the last few months and group them by type. The most frequent ones with the best success rate are the first candidates.
2. Define the model. For each candidate, document scope and limits (for example, "up to a 50% disk extension"), steps, pre- and post-checks, rollback plan and who can run it.
3. Get it approved once. The change authority assesses the model, not each execution. Record the decision and the model's review date.
4. Publish it in the tool. The standard change should be requested from a form with the model's fields and logged automatically.
5. Review the results. If a standard change fails, analyze it. If it fails repeatedly, the model reverts to normal until it is fixed.

A good entry criterion: a change qualifies as standard when the team can describe in advance everything that can go wrong and how to roll it back.

Risk-based approval and change authority

For normal changes, authorization should depend on risk. ITIL 4 uses the term change authority: the person or group that authorizes a change. It does not have to be the same one every time. A practical scheme distinguishes three levels:

• Low risk: authorized by the technical lead of the affected service, or through peer review.
• Medium risk: authorized by the service owner, with visibility for teams that share infrastructure.
• High risk: authorized by a board with business, security and operations representation.

Risk can be estimated with a short questionnaire: scope of impact (users, services), ability to roll back, past experience with that type of change, execution window and third-party dependencies. What matters is that the questionnaire is the same for everyone and that the score determines the authority, with no case-by-case debate.

In regulated environments, this scheme also makes audits easier. It is simpler to show a consistent, applied risk criterion than to justify how a board approved hundreds of changes in one-hour meetings.

Automation turns normal changes into standard ones

A change is a candidate for standard when it is repeatable and predictable. Automation produces exactly that: the same procedure, always executed the same way, with built-in checks and recorded evidence. That is why automating a frequent change type is often the most direct way to take it off the board's agenda.

Continuous integration and deployment pipelines let you build the controls into the flow itself: automated tests, peer code review, security scanning and a recorded approval before production. When those controls live in the pipeline, the pipeline itself becomes evidence of the risk assessment.

For infrastructure, tools such as Ansible play an equivalent role. Here is an example of an automated standard change, updating the nginx configuration with a pre-check and a post-check:

---
# Standard change (example): update the nginx configuration
- name: Update nginx configuration
  hosts: web
  become: true
  serial: 1                      # one server at a time to limit impact
  tasks:
    - name: Deploy nginx.conf, validating syntax before replacing it
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        backup: true             # keeps the previous version for rollback
        validate: nginx -t -c %s # if validation fails, the file is not replaced
      notify: Reload nginx

    - name: Apply the reload before verifying
      ansible.builtin.meta: flush_handlers

    - name: Verify the service responds
      ansible.builtin.uri:
        url: http://localhost/health
        status_code: 200

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

The playbook validates before applying, keeps a copy for rollback, moves one server at a time and checks the result. If it also runs from a platform that records who launched it, when and with what outcome, the evidence is linked to the change record with no manual work.

To decide which change types to automate first, score them with the Value × Complexity prioritization. Frequent changes that currently wait days for the board and touch few systems usually land in the quick wins quadrant: high value because of the effort freed up, and low complexity because they vary little.

Metrics: success and lead time

Two main metrics, to be read together:

• Change success rate: percentage of changes implemented without causing an incident, without needing a rollback and without overrunning the window. Its counterpart, change failure rate, is one of the software delivery metrics popularized by the DORA research program.
• Change lead time: time from when a change is requested until it is in production. If the success rate is high but lead time keeps growing, the process is protecting at the cost of slowing everything down.

Useful supporting metrics: the share of standard changes in the total (it should grow over time), the share of emergency changes (it should stay low) and incidents attributed to changes, cross-checked with problem management.

A healthy change process shows up as a trend: more standard changes, smaller and more frequent, with a stable or better success rate. If the only thing growing is the board, something is wrong.