Change enablement I: types, authority and risk

Most serious incidents follow a change. A configuration edited in production, a patch applied in a hurry, a new release pushed on a Friday afternoon: change is the main source of risk in a running service. Yet change is also how services improve. An organization that changes nothing never fixes defects, adds features or patches security holes. Change enablement exists to resolve this tension. In plain words, its purpose is to maximize the number of successful service and product changes by ensuring that risks are properly assessed, authorizing changes to proceed, and managing the change schedule.

ITIL 4 renamed the older change management practice change enablement on purpose. The emphasis is on enabling valuable change to flow quickly and safely, not on controlling or slowing it. This lesson covers what a change is, the three types of change, who authorizes changes and how risk is assessed. Lesson 8 covers scheduling, DevOps and measuring change.

What a change is

ITIL defines a change as the addition, modification or removal of anything that could have a direct or indirect effect on services. That is a broad definition on purpose. It includes software releases, infrastructure updates, configuration edits, firewall rule changes, database schema changes, supplier changes, new processes and documentation that operators rely on. The scope of change enablement is set by each organization: it decides which kinds of change the practice covers and which are handled elsewhere, such as changes to business strategy or to products that do not touch services.

A change differs from a service request in that it usually needs some assessment of risk and impact. The overlap is the standard change: a low-risk, pre-authorized change that may be fulfilled as a service request. A change also differs from a release, which is a version of a service or component made available for use, and from a deployment, which is the movement of components into an environment. Release and deployment management are covered in ITIL-141; change enablement decides whether and when changes may go ahead.

Three types of change

ITIL 4 describes three types of change, each with its own path through authorization.

Standard changes are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without additional authorization. Examples include adding memory to a server using an approved procedure, creating a user account, or deploying a routine configuration update through an automated pipeline. A standard change has a documented procedure, a known and low risk, and a record of being performed successfully many times. Its risk is assessed once, when the procedure is created or changed, not each time it is used.

Normal changes must be scheduled, assessed and authorized following a defined process. Depending on the risk, authorization may come from a peer, a team lead, a service owner, a change advisory board, or senior management. Low-risk normal changes can be authorized quickly by someone close to the work; high-risk ones need wider review. In many modern organizations, normal changes flow through automated pipelines that perform tests and checks and record the evidence, with human approval only where risk requires it.

Emergency changes must be implemented as soon as possible, for example to resolve an incident or apply a security patch for an actively exploited vulnerability. They are assessed and authorized as quickly as possible, often by a smaller emergency authority, and the documentation may be completed after implementation. Emergency changes should be rare. If many changes are emergencies, the organization has a planning problem, or people are using the emergency path to bypass normal assessment.

Building a library of standard changes

Moving frequent, low-risk changes into the standard category is one of the most effective improvements a change practice can make. It frees change authorities to focus on genuinely risky work and lets routine changes flow without waiting. A typical approach is to review normal changes over several months, identify those that are frequent, follow the same steps and have a high success rate, and propose them as standard change models. Each model is documented, tested, approved once and reviewed periodically, and is withdrawn if it starts causing incidents.

Change authority

A change authority is the person or group responsible for authorizing a change. ITIL 4 stresses that authority should be assigned to the right level for the type and risk of each change, and that decentralizing authority where possible speeds up flow. In high-performing organizations, the default change authority is often a peer reviewer within the team, supported by automated testing. A change advisory board (CAB) is reserved for changes with wide impact, cross-team dependencies or high risk, and may be advisory rather than the decision-maker.

The traditional weekly CAB meeting, where dozens of changes are reviewed in a room by people who know little about most of them, is widely criticized. Research summarized in the State of DevOps reports and the book Accelerate found that heavyweight external approval processes were associated with lower delivery performance and no better stability. That does not mean oversight is useless; it means oversight should be proportionate, close to the work and supported by evidence such as test results, rather than by meetings alone.

Assessing risk

Risk assessment is the core of change enablement. A simple approach scores two dimensions: the likelihood that the change will fail or cause an unwanted effect, and the impact if it does. Factors that raise likelihood include complexity, unfamiliar technology, changes to many components at once, lack of testing, no rollback plan and a team new to the system. Factors that raise impact include the criticality of affected services, the number of users, timing (month-end, peak season), regulatory exposure and how hard it would be to recover.

Many organizations use a questionnaire that converts answers into a risk score. The score then determines the change authority and the evidence required. Questionnaires should be short and should be calibrated against outcomes: if changes scored "low" keep causing incidents, the questions or thresholds need adjusting. The program below implements a simple scoring model and shows how a change's score drives its authority and required evidence.

# A simple change risk questionnaire (weights and thresholds are illustrative)
QUESTIONS = {
    "affects a critical service":           3,
    "touches more than one component":      2,
    "no automated tests cover it":          3,
    "no tested rollback or backout plan":   3,
    "team has not done this change before": 2,
    "during a peak business period":        2,
    "involves a supplier dependency":       1,
}
BANDS = [(0, 3, "low", "peer review in the pipeline"),
         (4, 8, "medium", "service owner after test evidence"),
         (9, 16, "high", "affected service owners plus CAB review")]

def assess(name, answers):
    score = sum(w for q, w in QUESTIONS.items() if q in answers)
    for lo, hi, band, authority in BANDS:
        if lo <= score <= hi:
            return f"{name:34} score {score:>2}  {band:6}  -> {authority}"

print(assess("Add log field, full test suite", set()))
print(assess("New checkout feature", {"affects a critical service", "touches more than one component"}))
print(assess("Database engine upgrade", {"affects a critical service", "touches more than one component",
                                         "team has not done this change before",
                                         "no tested rollback or backout plan"}))
print(assess("Untested month-end patch", {"affects a critical service", "no automated tests cover it",
                                          "no tested rollback or backout plan",
                                          "during a peak business period"}))

Add log field, full test suite     score  0  low     -> peer review in the pipeline
New checkout feature               score  5  medium  -> service owner after test evidence
Database engine upgrade            score 10  high    -> affected service owners plus CAB review
Untested month-end patch           score 11  high    -> affected service owners plus CAB review

The last two changes land in the high band for different reasons. The database upgrade is risky because it is unfamiliar and broad; better rehearsal and a tested backout plan would lower its score. The month-end patch is risky because it is untested and badly timed; moving it out of the peak period and adding tests could bring it down to medium. A good risk model does not just sort changes; it tells the team what to do to make a change safer.

Information needed for a change

A change request, sometimes called a request for change, records what is proposed and why. Typical contents include a description and reason, the services and configuration items affected, the planned implementation steps and schedule, test evidence, a backout or rollback plan, the risk assessment, resources needed and communication plans. In automated pipelines, much of this information is captured automatically: the code diff, test results, approval records and deployment logs together form the change record.

Records should be proportionate. A standard change may need only a reference to its model and a timestamp. A high-risk normal change needs a full plan. Demanding a twenty-field form for every small change wastes time and encourages people to fill in fields carelessly, which defeats the purpose.

Changes and incidents

Change enablement and incident management are tightly linked. When an incident occurs, one of the first questions is whether something changed recently. Change records linked to configuration items let the service desk and resolvers see recent changes to affected components. Conversely, the share of changes that lead to incidents, often called the change failure rate, is one of the most important measures of change enablement. Lesson 8 measures it in detail. Emergency changes made during incidents need special care: they are made under pressure and can introduce new faults.

Regulation and audit

Regulated organizations often face external requirements for change control. Financial institutions in Canada follow guidance such as OSFI Guideline B-13 on technology and cyber risk management, which expects sound change and release management. US public companies must maintain internal control over financial reporting under the Sarbanes-Oxley Act, and auditors routinely test change management for systems that affect financial data. Healthcare and government bodies have similar expectations. Regulators generally want evidence that changes are assessed, authorized by someone other than the implementer where appropriate, tested and traceable. Automated pipelines that record test results, peer approvals and deployment logs can satisfy these expectations at least as well as manual forms, often better.