Change Enablement

Why change enablement exists

Ask experienced operations staff what caused their worst outages, and many will name a change: a firewall rule that blocked more than intended, a database upgrade on the evening of the monthly billing run, two teams working on the same server in the same night. Many incidents start with someone changing something.

Organizations cannot stop changing, though. Security patches, new features for the customer portal, capacity for winter peaks: the business needs change, and needs it fast. Change enablement is the practice that maximizes the number of successful changes by making sure risks are properly assessed, changes are authorized by the right people, and the change schedule is managed. The word "enablement" is deliberate: the goal is to help changes happen safely, not to block them.

What counts as a change

A change is adding, modifying or removing anything that could affect a service, directly or indirectly. That covers more than people expect:

• Deploying a new version of the customer portal or mobile app.
• Changing a firewall rule, a DNS record or a load balancer setting.
• Upgrading the database server, patching an operating system, replacing a disk.
• Changing a scheduled job's time, a backup policy or a monitoring threshold.
• Decommissioning an old server that "nobody uses anymore".

Each organization decides the scope: which components are under change control and which are not. A user moving a desktop shortcut is not a change in this sense; a developer changing the production configuration of the billing system certainly is. The configuration items in scope are typically those recorded in the configuration management database.

Standard, normal and emergency changes

Treating every change the same way would either make small changes painfully slow or let big ones through without a second look. So changes are divided into three types, each with its own route:

A standard change is a low-risk, pre-authorized change that follows a documented and tested procedure. Its risk was assessed once, when the procedure was approved, so each instance can be carried out without asking again. Many standard changes are fully automated, and some are ordered by users through the service catalog.

A normal change is a change that must be scheduled, assessed and authorized individually. Most changes start here. Normal changes are not all equal: a low-risk one may only need a colleague's review, a high-risk one a wider discussion.

An emergency change is a change that must be implemented as soon as possible, for example to resolve a major incident or to apply an urgent security patch. It is assessed and authorized faster and by fewer people, but it is still assessed, authorized, recorded and reviewed. During the storm outage described on incident management, moving the outage map to a static page was emergency change CHG-8840, authorized by the on-call service owner within minutes.

The request for change

A request for change (RFC) is the formal proposal for a change, usually a change record in the ITSM tool, describing what will be changed, why, the risk, and how it will be done and undone. The record follows the change through assessment, authorization, implementation and review. A good change record answers the questions a reviewer would ask before they ask them:

Number:        CHG-8851        Type: Normal
Title:         Recreate index readings(customer_id, read_at) on db01
Requested by:  Hamid Rahimi (database team)
Reason:        Removes cause of known error KE-0087 (PRB-0207):
               nightly billing job times out without this index
Services/CIs:  Billing / db01 (primary + replica), batch-01
Risk:          Likelihood 2, impact 4 -> 8 (medium)
               Index build locks writes to table for est. 12 min
Impact:        Meter reading import paused during build; no customer-
               facing impact at night
Test evidence: Built on acceptance copy with full production volume:
               11 min 40 s; billing job runtime 52 min (was 3 h 10 min)
Plan:          1. Pause meter import  2. Create index  3. Verify plan
               uses index  4. Resume import  5. Run billing job check
Back-out:      Drop new index (1 min), resume import; job runs as before
Window:        Sat 2026-05-16 02:00-03:00 (billing maintenance window)
Authority:     Service owner billing (Joost Bakker) - approved
Linked:        PRB-0207, KE-0087, INC-6101, INC-6112, INC-6131, INC-6140

Notice the back-out plan: how to return to the previous state if the change fails. Back-out plans are covered with releases on release and deployment management. A change without a realistic way back deserves much more scrutiny.

Who authorizes a change

ITIL 4 uses the term change authority: the person or group that has the authority to authorize a particular change. The key idea is that the authority depends on the type and risk of the change. Different changes go to different authorities, and the authority should sit as close as possible to the work, so that low-risk changes are approved quickly by people who understand them, while high-risk changes get a broader view.

Many organizations still have a change advisory board (CAB): a regular meeting of representatives from operations, development, security, the service desk and the business, who review significant changes and advise the change authority, or act as one. A CAB is useful for spotting conflicts ("the network team plans maintenance on the same night") and for changes that affect many teams. It becomes a problem when every small change waits for a weekly meeting, and members approve dozens of changes they cannot judge in a few minutes each.

In teams that deploy many times a day, authorization is built into the deployment pipeline: a peer review of the code is the approval, and automated tests, security scans and policy checks provide the evidence. Each deployment is recorded automatically. This still is change enablement: risk is assessed and someone authorized the change, but the assessment is done by people and tools close to the work, not by a distant board. The 2019 Accelerate State of DevOps report (DORA) found that approval by an external body, such as a CAB or a senior manager, was associated with worse software delivery performance and not with fewer failed changes. It recommends peer review and automated checks instead. For infrastructure, Infrastructure as Code in Pipelines shows how the pull request, the reviewed plan, the approval and the run log together form the change record.

Assessing risk

Risk is commonly estimated as likelihood times impact, the same approach used in security risk assessment. Likelihood depends on how complex the change is, how often it has been done before and how well it was tested; impact depends on which services and users would be hit if it fails. The program below routes a week of Kestrel changes to an authority based on that score:

# (change, type, likelihood, impact), each scored 1 (very low) to 5 (very high)
changes = [
    ("CHG-8846", "standard", 1, 2),
    ("CHG-8849", "normal", 2, 2),
    ("CHG-8851", "normal", 2, 4),
    ("CHG-8857", "normal", 3, 5),
    ("CHG-8860", "emergency", 3, 4),
    ("CHG-8862", "standard", 3, 3),
]


def change_authority(change_type, likelihood, impact):
    score = likelihood * impact
    if change_type == "standard":
        if score > 4:
            return score, "too risky for a standard change: assess as normal"
        return score, "pre-authorized"
    if change_type == "emergency":
        return score, "emergency change authority"
    if score <= 4:
        return score, "peer review in the team"
    if score <= 12:
        return score, "service owner"
    return score, "change advisory board"


for number, change_type, likelihood, impact in changes:
    score, authority = change_authority(change_type, likelihood, impact)
    print(f"{number}  {change_type:<9} risk {score:>2}  {authority}")

CHG-8846  standard  risk  2  pre-authorized
CHG-8849  normal    risk  4  peer review in the team
CHG-8851  normal    risk  8  service owner
CHG-8857  normal    risk 15  change advisory board
CHG-8860  emergency risk 12  emergency change authority
CHG-8862  standard  risk  9  too risky for a standard change: assess as normal

The last line is the interesting one: a team proposed a firmware update on the core switches as a standard change, but its risk does not fit the standard route. The thresholds here are Kestrel's own; every organization sets them for its situation. A score supports a judgment; it does not replace one.

The change schedule, maintenance windows and freezes

The change schedule is the calendar of planned and past changes. It is used to plan changes, spot conflicts (two changes on the same system in the same night), tell the service desk what is happening, and help incident investigators: the first question in many major incidents is "what changed?"

A maintenance window is a pre-agreed period, usually at a quiet time, in which changes that may disrupt a service are allowed to be carried out. Kestrel's billing systems have one early Saturday morning, 02:00–06:00; the customer portal, used around the clock, has a short weekly window (Sunday 02:00–05:00), announced on the status page five working days in advance. Windows are often written into service level agreements, so downtime inside them does not count against availability targets.

A change freeze is a period in which only emergency changes, and sometimes standard changes, are allowed, because the business cannot afford disruption. Kestrel freezes changes to billing in the last three working days of each month and to the outage systems when a severe storm is forecast. Freezes reduce risk during critical periods but create a queue of changes afterward, so the days after a freeze need extra care. Teams that use site reliability engineering trigger a freeze by measured reliability instead of the calendar; see the error budget policy.

After the change

A change is not finished when the command has run. Someone checks that it achieved its goal and did not break anything else, and the record is closed with the result: successful, successful with issues, failed and backed out. Significant changes, and all failed and emergency changes, get a post-implementation review: did it go as planned, were the risk and the test evidence realistic, and what should the next similar change do differently? Changes that keep going well are candidates to become standard changes.

Useful measures are the change success rate (the share of changes that achieved their goal without causing an incident), the number of incidents caused by changes, the number of emergency and unauthorized changes, and the time from request to implementation. The DevOps world measures the same idea as change failure rate, one of the DORA metrics.

Change enablement is not organizational change management

In everyday language "change management" can also mean helping people through changes in an organization: a reorganization, a new way of working, a new ITSM tool that the service desk must learn. That is a different discipline, about communication, training and resistance, and ITIL treats it as a separate practice, organizational change management. Change enablement is about changes to services and their components. When a colleague says "change management", check which one they mean.

Common mistakes

• Unauthorized changes. A quick fix on a production server "just this once" is invisible to the change schedule and to the next person investigating an incident. It is also how systems slowly drift away from their documented state; see configuration drift. A scheduled drift check finds such changes automatically.
• A CAB as a rubber stamp. Approving forty changes in an hour gives a false sense of control. Route low-risk changes elsewhere and let the board spend its time on the risky few.
• No realistic back-out plan. "Restore from backup" for a change on a system that processes orders all night is not a plan; it is a hope.
• Never promoting changes to standard. If the same low-risk change has gone well fifty times, asking for approval the fifty-first time wastes everyone's time.