IT Change Management: Types, Approval and Risk Explained

In IT service management, a change is the addition, modification or removal of anything that could affect a service. A software release, a firewall rule, a database upgrade, a certificate renewal and a change to an on-call schedule are all changes. Change management is the practice that decides which changes are made, when and by whom, and that records what was done.

Its purpose is a balance. Too little control, and changes cause outages, because nobody checked how they interact. Too much, and changes queue for weeks, the business routes around the process and the real risk moves into unofficial workarounds. A good change process puts effort where the risk is, and removes it where the risk is low.

Some organisations use the term change enablement instead, which stresses that the aim is to let beneficial change happen safely and quickly. The substance is the same: assess, approve, schedule, implement, review and record.

The three types of change

The ITIL framework describes three types of change, and nearly every change process, whether or not it uses ITIL's language, has some version of them.

• Standard change: a low-risk, repeatable change that follows a documented procedure and is pre-approved. Examples are creating a user account, renewing a certificate on a known process or applying a routine patch to a defined set of systems. Because approval is given once for the type, an individual standard change does not go to the advisory board.
• Normal change: any change that is neither standard nor an emergency. It needs assessment, review and authorisation before implementation, in proportion to its risk. Most meaningful changes are normal changes.
• Emergency change: an urgent change to restore service or to address a serious security issue. It follows a shortened route with its own approvers, and it is reviewed in full afterwards.

A fourth label some teams add

Some organisations add the label major change for normal changes with broad impact, long duration or high cost. It is not one of the three ITIL types, but it is a useful local convention that sends the largest changes to a more senior review. If you use it, define the criteria.

The lifecycle of a normal change

• Request: someone proposes the change, with a reason, the systems involved and a requested time.
• Assess: the risk and impact are evaluated, along with dependencies, the plan to implement, the test evidence and the way back.
• Approve: authority is given, by an individual or an advisory board according to the risk.
• Schedule: the change is placed in an agreed window that avoids conflicts and freezes.
• Implement: the change is made as planned, by the named people, and each step is recorded.
• Verify: the result is checked against the success criteria.
• Review: afterwards, the team compares the plan with what happened and closes the record.

Assess risk with a few honest questions

Risk scoring need not be elaborate. A short set of questions gives a consistent answer.

• Impact: what is the worst reasonable outcome, and how many users or customers would feel it?
• Likelihood: has this exact change been done before, and how did it go?
• Reversibility: can it be undone quickly? A change that cannot be undone is riskier by its nature.
• Complexity: how many systems and teams are involved?
• Timing: is it near a freeze, a peak period or a staffing gap?
• Evidence: has it been tested in an environment that resembles production?

Match approval to risk

Approval should scale. A pre-approved standard change needs none beyond the rule that created it. A low-risk normal change may need only a peer and the service owner. A high-risk change goes to the change advisory board, which brings together the people affected. The advisory board guide covers how to run one without it becoming a bottleneck.

Do not let the approver be the person making the change. Separation of duties is a basic control, and it also improves quality, because a second person reads the plan.

Schedule around conflicts

Two safe changes can be unsafe together. Keep a calendar of planned changes and freeze windows, and check new requests against it. A visible calendar prevents the collision that nobody foresaw. See the change freeze guide.

Plan for failure

Every normal change should say how it will be undone and what will trigger that. The rollback plan guide gives a template. A change with no way back should be flagged as such and approved at a higher level.

Review after implementation

Close each change with a short review: did it succeed, was it on time, did it cause incidents, and did the plan match what happened? Aggregate the results. The share of changes that cause incidents, and the share that need emergency work afterwards, are useful measures of whether the process is working. Define them before measuring.

What to record

• What is changing and why.
• Who requested it, who approved it and who implemented it, with times.
• The risk assessment and the evidence behind it.
• The implementation and rollback plans.
• The window, and the freeze windows checked.
• The outcome, and any incident linked to it.

Change models and the standard change catalogue

A change model is a predefined approach for a particular kind of change: the steps, the people, the evidence and the approval route. The most valuable model is the standard change, because it removes work. When a type of change has been done many times, is well understood and has a documented procedure, it can be approved once for the type and then performed without further review each time.

A standard change catalogue is the list of these types. Each entry should state what the change is, the conditions under which it qualifies, the procedure, the person or role who may perform it, the verification and the rollback. Adding an entry is itself a decision, made by the people who would otherwise review each instance, based on evidence that the change is reliably safe. Review the catalogue periodically and remove entries whose conditions no longer hold.

The catalogue is the main way to keep a change process from becoming a bottleneck. If more than a small share of changes need individual review, the catalogue is probably too short.

Roles

• Change requester: proposes the change and explains why it is needed.
• Change owner or implementer: is accountable for planning and carrying it out.
• Approver: authorises it. The approver should not be the implementer.
• Service owner: confirms the change is acceptable for the service they are accountable for.
• Change manager or coordinator: maintains the process and the calendar, chairs the board and reports on results. In a small team this is a part of someone's role.

Change in a continuous delivery environment

A team that deploys many times a day cannot send every deployment to a board. Research on software delivery has found that heavy external approval is not associated with better stability, and that lighter approaches built on peer review and automation perform better. The practical lesson is to move control earlier and make it automatic.

In practice this means that routine deployments are treated as standard changes, with the pipeline as the procedure: peer review of every change, automated tests that must pass, staged rollout and an automatic way back. The pipeline's own record of what was deployed, when and by whom becomes the change record. The human approval is kept for changes that fall outside the routine, such as a data migration, a change to authentication or a change during a freeze window.

Atlas fits this pattern. Send deployment events from the pipeline through the API so that the release record shows each deployment by environment with status and times, and keep sign-off and the readiness checklist for the releases that warrant them.

A worked example

A team plans to upgrade the database engine that supports its customer-facing application. It raises a normal change. The requester explains that the current version will soon lose vendor support. The implementer lists the steps: take a verified backup, upgrade the staging copy, run the test suite and a performance check, schedule a maintenance window outside business hours, upgrade production, verify the key journeys and monitor for two hours.

The risk assessment records that the worst reasonable outcome is several hours of downtime, that the upgrade is reversible only by restoring the backup, which would take about an hour, and that the staging rehearsal succeeded. Because the change cannot be easily undone, the team classifies it as higher risk and sends it to the advisory board. The board asks about the freeze calendar and finds that the planned window falls one week before a quarter-end close. It approves the change with a condition to move the window two weeks earlier.

On the night, the implementer records each step and its time. A check fails after the upgrade, a background job is not running. The change owner invokes the rollback decision point in the plan, finds the cause is a configuration value and fixes it in minutes without restoring the backup. The review the next day notes that the rehearsal had not included background jobs, adds them to the checklist and records the change as successful with one minor issue. The record is complete, and the next upgrade starts from a better plan.

Communicating change

A change that is technically perfect can still cause trouble if the people affected were not expecting it. Decide for each change who needs to know, what they need to know and when. Support needs to know in advance so that they can recognise a related request. Users need notice if their work will be interrupted, with the time, the duration and what to do. Other teams need to know if their systems depend on the one being changed.

Put the change on a calendar that people can see, and send a short message at three points: before, when the window opens and when it ends. State the outcome plainly. If it overran or was rolled back, say so. Users forgive an announced interruption far more readily than a surprise.

Measuring change

• Change success rate: the share of changes completed without causing an incident, a rollback or unplanned work. Define failure once and keep the definition.
• Emergency share: the proportion of changes that are emergencies. A rising share points to weak planning or testing.
• Lead time: from request to approval, and from approval to implementation. Rising lead time signals a bottleneck.
• Incidents caused by change: the count and the types of change responsible. They show where to strengthen the process.
• Unauthorised changes: changes found that did not go through the process. A non-zero count means that the process is too hard or is not known.

How Atlas fits, and where it does not

Atlas is not a full IT service management suite. It does not include a configuration management database or a dedicated change advisory board workflow. What it does provide maps well to software and platform changes.

Release Management gathers the tasks that ship together, holds a readiness checklist with required and optional checks, asks named people for sign-off, records deployments by environment with status and times, and refuses to release to Production during a freeze window unless a workspace owner or administrator overrides it with a recorded reason of up to 500 characters. That covers scope, assessment evidence, approval, scheduling and the record for changes delivered as releases. Atlas does not run the pipeline. It records what the pipeline did.

For changes that are not releases, such as an infrastructure modification, you can use a task with a checklist and an approval, or create a release of the type that fits. Incident Management links back: when a change causes an incident, the release record answers the first question of any response, which is what changed.

Common mistakes

• Treating every change as high risk, which creates a queue and teaches people to bypass the process.
• A standard change catalogue that nobody maintains.
• Approval by silence.
• Emergency changes with no later review.
• Recording changes after the event.
• Measuring the number of approvals instead of the number of failures.