IT change management is the structured process that governs how technical changes move from request to live deployment without breaking the services a business depends on. The immediate action for any team without a mature process: raise every change as a formal RFC, log it against a visible schedule of change, and never implement without a tested back-out plan. This guide follows ITIL and ISO/IEC 20000-1 principles alongside DORA-style KPIs.
What is IT change management and why it matters
IT change management is an ITIL/ITSM discipline for planning and controlling the lifecycle of technical changes so they deliver their intended benefit without degrading service. Service management good practice from GOV.UK describes a typical process built around four stages: Request, Plan, Implement and Verify, each with defined ownership and a mandatory back-out plan.
The process helps teams manage the risk of unplanned outages from uncontrolled change. A single unapproved configuration update can cascade through a network, and when several teams or suppliers change systems independently, conflicts become almost inevitable. Formal change management coordinates that activity, assigns accountability and gives every change a documented trail.
A well-run process rests on a small set of recurring artefacts:
- A Request for Change (RFC) capturing what will change, why and how
- A named change owner responsible for delivery
- A change authority who approves or rejects the request
- A defined change window and a tested back-out plan
Types of change and corresponding approval routes
Not every change carries the same risk, so ITIL-aligned processes sort requests into categories with proportionate controls.
Standard changes are low-risk, pre-authorised and repeatable, such as routine patching or a password reset script that has already been tested and approved once. Normal (or non-routine) changes carry higher risk or novelty and typically need review by a Change Advisory Board (CAB) before approval, covering items like a major application upgrade or a new network segment.
Emergency changes address an active incident or imminent threat, such as a critical security hotfix, and often bypass the standard CAB cycle in favour of a faster eCAB or retrospective approval. Institutional policy guidance is clear that this route exists for genuine urgency only; it should never be used to paper over poor planning or a missed deadline, a point echoed in both the IT Change Management Policy & Procedure and the Digital and Data Services Change Advisory Board Procedure.
Typical examples by category:
- Standard: routine patches, scheduled backups, minor configuration tweaks
- Normal: major software upgrades, new integrations, infrastructure migrations
- Emergency: critical security hotfixes, active incident remediation
The change lifecycle: request, plan, implement, verify and close
Every change should move through the same disciplined sequence, regardless of category.
- Raise the RFC. The requester (often a business stakeholder) or the change owner submits the request with a clear description, justification, affected systems and evidence of testing, following the structure set out in public-sector change management policy templates.
- Assess impact and plan. The change owner completes a risk and impact assessment, defines a back-out plan, and books the work into the schedule of change to avoid conflicting with other activity. Our own risk assessment guide covers this step in more depth for teams building the habit internally.
- Implement within the approved window. Take backups before starting, follow the approved plan without deviation, and record every action taken, including timestamps and outcomes.
- Verify and review. Confirm the change met its success criteria, run a post-implementation review to capture lessons learned, and feed the result back into the KPI set.
A migration or infrastructure change benefits from the same scheduling discipline described in our cloud migration checklist, particularly around change windows and rollback planning.
Pro Tip: Never schedule a high-risk change on a Friday afternoon; you want your team and your rollback window available if something goes wrong.
Roles and governance: who decides and who does what
Clear ownership is what makes a change process predictable rather than political. Public-sector policy templates, including Change Management Policy and Process v1.0, consistently define the same core roles.
- Change manager: the single point of contact for the process, chairs the CAB and maintains the schedule of change.
- Change requester: raises the RFC and provides the business justification.
- Change owner: plans, tests and takes delivery accountability for the change.
- Implementer: carries out the technical work within the approved window.
- CAB (and eCAB): a cross-functional group that reviews normal changes and, for emergencies, convenes a smaller eCAB to approve or retrospectively ratify urgent work, as described in the Policy Template V6 00.
Separating approval, delivery and oversight can help keep scheduling realistic and risk assessment balanced.
Measuring success: KPIs to track and how to use them
A change process only improves when it is measured. Alongside traditional counts of successful changes, failed changes and incidents caused by change, DORA-style metrics give a sharper view of delivery health: change lead time, deployment frequency, change failure rate and time to recover from a failed deployment.
Organisations increasingly track these through service management dashboards, reviewing them regularly or alongside CAB meetings to spot bottlenecks before they become recurring incidents.
Tracking these figures consistently also supports a wider finding from the Office for National Statistics: firms that regularly review processes and set clear KPI targets tend to perform better, even though 36% of UK businesses cite time constraints as a barrier to making those improvements. A documented review cadence is what turns KPIs from a reporting exercise into a genuine maturity lever, a point also reflected in ISO/IEC 20000-1 service management guidance.
Practical best practices and an immediate checklist for IT teams
A handful of habits account for most of the difference between a controlled change process and constant firefighting.
- Keep the schedule of change visible to every team so conflicting work gets caught before it collides
- Pre-authorise genuinely low-risk standard changes, but require testing evidence for anything normal or above
- Make a back-out plan mandatory before any implementation window opens
- Run a post-implementation review every time, not just when something breaks
- Limit emergency changes to real emergencies and automate repetitive, low-risk tasks where you can
Pro Tip: Train new starters on RFC discipline so everyone raises requests consistently.
Where change volume is driven by too many overlapping tools, consolidating the stack reduces the number of changes you need to govern in the first place, a point covered in SmartFlowCRM’s guide to tech stack consolidation. Teams tracking deployment frequency alongside infrastructure spend may also find Koritsu’s notes on DevOps cloud cost management a useful companion when cadence and cost start to pull in different directions.
How Abersecure can support change management through managed services
Running a disciplined change process takes time most internal IT teams do not have spare: writing RFCs, chasing testing evidence, maintaining the schedule and chairing reviews all compete with day-to-day support tickets. Through Managed IT Support, we provide IT support to businesses.
Discuss with Abersecure which services, if any, could support your organisation’s change management requirements.
If your team wants structured change control running in the background rather than managed on top of an already full workload, our Managed IT Support service is the practical next step.
FAQ
What is change management in software development?
In software development, change management governs how code, configuration or infrastructure changes move from request through testing to release, usually via version control, peer review and a defined deployment pipeline. It applies the same core principles as ITIL change management: a documented request, an impact assessment, a tested rollback option and a review after release.
What is ITIL change enablement?
ITIL change enablement (formerly called change management in older ITIL versions) is the practice that ensures changes to services and products are assessed, authorised and scheduled to maximise successful outcomes. It relies on a change authority, a defined change window and back-out planning, following the stages set out in GOV.UK service management guidance: Request, Plan, Implement and Verify.
What is technology change management?
Technology change management is the broader discipline of controlling changes across an organisation’s hardware, software, networks and cloud systems to protect stability and security. It typically categorises changes as standard, normal or emergency, each with its own approval route and testing requirement.
What is the role of change management in organisations?
Change management gives organisations a consistent way to introduce beneficial technical changes while limiting the risk of outages, security gaps or conflicting work. It creates accountability through defined roles such as the change manager and CAB, and it produces an audit trail that supports compliance and continuous improvement.
