An IT change management process is a controlled way to request, assess, approve, test, implement and review changes to your systems, so that updates improve service instead of breaking it. The version that works is not the heaviest one. It matches the amount of review to the risk of each change, records a rollback plan before anything goes live, and checks the result afterward. This guide walks through the stages, the change types, who sits on a change advisory board, and the mistakes that turn a good process into paperwork.
TL;DR
- A solid process has seven stages: request, impact analysis, approval, design and build, testing, implementation, and post-implementation review.
- Sort changes by risk: routine changes are pre-approved, normal changes get full review, and emergency changes move fast but are documented and reviewed afterward.
- Write the back-out plan before implementation starts. Missing rollback plans are the most common failure practitioners point to.
- Keep the change advisory board small and include business voices, not only engineers. Scale the process so low-risk work does not queue behind high-risk work.
- Security impact analysis belongs inside the process, not after it.
Table of Contents
- What IT change management actually controls
- The seven stages of an IT change management process
- Change types: routine, normal and emergency
- The change advisory board: who sits on it and why
- Back-out plans: the step teams skip
- Scale the process to the risk
- What a good process can deliver
- How to build or fix your process in five steps
- Our perspective: change control is where security and operations meet
- Where Nexus can help
- FAQ
- Sources
What IT change management actually controls
The FFIEC IT Examination Handbook describes change management as the continuous process of maintaining the integrity of hardware, software, firmware and documentation, and of controlling and approving additions, modifications and removals. In plain terms: nothing in production changes because someone felt like it on a Tuesday afternoon.
The goal behind that control is the familiar security triad. The same FFIEC guidance frames change management around keeping services confidential, intact and available while limiting disruption. A patch, a firewall rule edit, a cloud configuration tweak, a new SaaS integration and a database upgrade all count.
People often use "change management" for two different things. Organizational change management is about helping people adopt new ways of working. IT change management, the subject here, is about technical changes to infrastructure, applications and configurations. ITIL 4 calls the second one "change enablement", a name that signals the intent: make good changes happen safely and quickly, not block them.
The seven stages of an IT change management process
Guidance from NIST SP 800-128 and the FFIEC handbook converges on a sequence like the one below. The ITIL-based process practice guide lists very similar activities: receiving requests, stratifying changes, planning, impact analysis including back-out, approval, scheduling, execution and review.
1. Request submission
Every change starts as a written request. It should state what is changing, why, which systems are touched, the requested window and who owns it. A standard intake form beats an email thread because it forces the same questions every time.
2. Impact analysis and review
The change manager, or a delegate, assesses risk: which services depend on the component, what could fail, how many users would notice, and whether the change touches security controls. This is also where the change gets classified (routine, normal or emergency, covered below).
Security belongs here. NIST's guidance stresses that changes made without a prior security impact analysis often introduce unanticipated vulnerabilities or operational disruption. If your configuration management database or asset inventory is out of date, this step is where you feel it.
3. Formal approval
Approval authority should match risk. A routine change may be pre-approved by policy. A normal change goes to a named approver or the change advisory board. A change to a core payment, patient or identity system may need executive or business-owner sign-off as well.
4. Design and build
The implementer prepares the change: scripts, configuration, deployment packages, and the runbook that says exactly what will be done and in what order. The runbook should be good enough that someone other than the author could execute it.
5. Independent testing
Test in an environment that resembles production, and ideally have someone other than the builder verify it. Testing is also where you rehearse the rollback, not only the happy path.
6. Implementation
Schedule the change, ideally in an off-peak window, and communicate it to the people who will be affected. During execution, log what actually happened against the runbook, including any deviation.
7. Verification and post-implementation review
Confirm the service works, close the ticket and hold a short review. Did the change achieve its purpose? Did anything unexpected happen? NIST treats the post-implementation review as critical because it validates both the technical success of the change and its security integrity. The review is also what feeds improvement: patterns of failed changes tell you which systems or teams need attention.
Change types: routine, normal and emergency
The FFIEC material categorizes changes by risk: planned or normal changes follow the full process, routine changes are often pre-approved, and emergency changes are prioritized for immediate restoration of service. ITIL 4 uses "standard" for what the FFIEC calls routine. Here is how the three differ in practice.
| Type | Typical examples | Approval | Documentation |
|---|---|---|---|
| Routine (standard) | Adding a user, resetting access, installing a low-impact update from an approved list | Pre-approved by policy; no per-change review | Logged, follows a fixed procedure |
| Normal | Server upgrade, new firewall rule set, cloud migration step, application release | Change manager or CAB reviews each one | Full record, test evidence, rollback plan |
| Emergency | Fixing an outage in progress, closing an actively exploited vulnerability | Fast-track authority, often a small emergency group | Shortened workflow, but still recorded and reviewed afterward |
The examples are ours; the classification logic comes from the sources above. One point from the research deserves emphasis: emergency changes may shorten the workflow, but standards still expect them to be documented and reviewed after implementation so the audit trail stays intact. An emergency is not an exemption.
If you manage vulnerabilities, you will see this daily. A critical remediation can be an emergency change, while monthly operating system patches are better handled as a standard change with a pre-approved procedure. Our guides on vulnerability remediation and patch management policy show how to connect those workflows to change records.
The change advisory board: who sits on it and why
A change advisory board (CAB) reviews higher-risk changes and advises the change manager. The question people search for is who belongs on it. Based on the Reed College CAB standard and the monday.com CAB guide, a workable roster looks like this:
- Change manager (chair). Runs the meeting, owns the process, makes the call when the board is split, and keeps the change schedule.
- Change requestor or implementer. Presents the change, the risks and the rollback plan, and answers questions.
- Technical representatives. Infrastructure, network, application and database leads who understand dependencies.
- Security representative. Judges the security impact and whether controls are affected.
- Business stakeholders. People who can say whether a technical update collides with a critical sales cycle or a financial reporting period.
- Service desk representative. Knows what users will experience and prepares support for the change window.
The monday.com guide argues a CAB should act as a guardian of risk and stakeholder alignment rather than a rubber stamp. The business seats are the part most teams skip, and they are the part that prevents a Friday-afternoon migration landing on quarter-end close.
For emergencies, a smaller group (often called an emergency CAB) can approve quickly by phone or chat. Define in advance who is on it and who deputizes when they are away, because you cannot design that during an outage.
Keep the board lean. Large boards that meet weekly to read every ticket aloud become the bottleneck that drives teams to work around the process.
Back-out plans: the step teams skip
Practitioners cited in the research name one failure above others: not documenting a rollback plan before implementation begins. When a change goes wrong in production without one, the team improvises under pressure.
A usable back-out plan answers four questions:
- What is the trigger? Define the symptom or time limit that means "we roll back", for example a failed health check or a set number of minutes past the window.
- What are the exact steps? Written, ordered, and tested where possible.
- What data could be lost or changed? Take backups or snapshots first and say where they are.
- Who decides, and who gets told? Name the person with authority to call it.
Backing out is only as good as your backups. If a change touches data stores, confirm that restores actually work. Our piece on disaster recovery testing covers how often each system tier should be tested.
Scale the process to the risk
The most common design error is a single heavy workflow for everything. The research points the other way. ITIL 4 principles emphasize working holistically and keeping things simple and practical, tailoring rigor to the risk of the change rather than forcing every request through the same approval. Older ITIL guidance makes the same point: there is no universal best change flow, and the right one balances speed against risk tolerance and the need for formal authorization.
When low-risk work waits in the same queue as a core database migration, people stop filing requests. The monday.com guide describes this as process fatigue, which pushes teams toward shadow IT and unauthorized changes. A tiered model prevents it:
- Tier 1, routine: pre-approved procedures, automated where possible, reviewed in aggregate.
- Tier 2, normal and low or medium risk: approved by the change manager or a named delegate, no board meeting.
- Tier 3, high risk: full CAB review with business input, test evidence and rehearsed rollback.
- Emergency: fast-track authority, retrospective review within a set number of days.
The Virginia Tech operational change management guide is a useful example of a university IT group explaining its standard in practical terms for the professionals who apply it.
What a good process can deliver
Results vary by organization, so treat published figures as illustrations, not promises. In a Hewlett Packard Enterprise ITIL 4 success story, the company reported a 3.5% improvement in change success rates and a 15% reduction in emergency changes after implementing a structured framework. It also reported a 50% reduction in major incidents and a 25% reduction in mean time to repair. That program ran in three phases beginning with an internal assessment of current process maturity, which is a sensible model for any team: measure first, then change the process.
Metrics worth tracking in your own environment:
- Change success rate (changes completed without incident or rollback).
- Share of changes that are emergencies, and whether it is falling.
- Incidents caused by changes.
- Time from request to implementation, by tier.
- Percentage of changes with a completed post-implementation review.
How to build or fix your process in five steps
- Assess where you are. List how changes actually happen today, including the informal ones. Count recent incidents traced to changes.
- Define your tiers and approval rules. Write down what is routine, what is normal, what is an emergency, and who can approve each.
- Create one intake form and one record. Every change, whatever the tier, leaves the same minimum trail: what, why, who, when, rollback.
- Stand up a lean CAB. Set a short, regular slot, publish the agenda in advance and invite the business seats.
- Review monthly. Look at failed and emergency changes, adjust the tiers, and retire rules that add friction without reducing risk.
If you work in a regulated setting, check what your auditors expect. Healthcare organizations may look at the CMS change management policy as an example of how a federal agency frames the requirement, and financial institutions should read the FFIEC's guidance on implementing changes, which calls for a process covering request, decision, approval or rejection, test and implementation. Your compliance officer or external auditor has the final word on what applies to you.
Our perspective: change control is where security and operations meet
We see change management as the place where fragmented IT shows its cost. When security, cloud, network and compliance are handled by different vendors, nobody owns the full impact of a change. The network team opens a port, the cloud team adjusts an identity policy, and the compliance evidence is reconstructed months later for an audit.
Our view is that change records should do three jobs at once: protect uptime, prove control to auditors, and feed threat detection with context about what is supposed to be changing. A monitoring alert is far easier to triage when you can see an approved change that explains it, or notice that there is none.
We also hold that rigor should follow risk. Small teams with limited budgets do not need a weekly board meeting; they need a clear rule for what is routine, a named approver for the rest, and a rollback plan they can trust. Larger organizations need the opposite discipline: tiers that stop a big board from becoming a bottleneck. In both cases we would rather see a simple process that people use than an elaborate one that they avoid.
— Nick - Sr. Executive
Where Nexus can help
If you would rather not build and run this alone, Nexus brings IT management, cybersecurity, cloud and compliance work under one provider with a single point of accountability. That means change requests, security review and compliance evidence sit with the same team. You can see the full range on our services page, or read our guide to managed IT services to judge whether outsourcing fits your situation. To talk through your own change process, start at accountnext-nexus.com.
FAQ
What are the steps in the IT change management process?
The common sequence is request, impact analysis, approval, design and build, independent testing, implementation and post-implementation review. Emergency changes compress the sequence but still need documentation and review afterward. Exact names vary between ITIL, NIST and your own policy.
What is the difference between a standard, normal and emergency change?
A standard (routine) change is low risk and pre-approved, so it follows a fixed procedure without per-change review. A normal change is assessed and approved individually, often by a CAB. An emergency change is urgent, usually to restore service or close a serious exposure, and gets fast-track approval with a review after the fact.
Who should be on a change advisory board?
At minimum: a change manager as chair, the implementer, technical leads, a security representative and business stakeholders who know about critical periods such as sales cycles or financial reporting. A service desk representative is useful for user impact. Keep it small, and use a separate emergency group for urgent decisions.
Does a small business need formal change control?
Yes, but a light version. A shared request form, a named approver, a short list of pre-approved routine tasks and a written rollback plan for anything that touches production cover most of the value. Add a board only when the volume or risk justifies it.
Sources
- FFIEC IT Examination Handbook: III.D.1 Change Management
- FFIEC IT Examination Handbook: VII.B.1 Implementing Changes
- NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems
- IT Operational Process Practice: Change Management
- Change Advisory Board: Roles, Process, And Best Practices (monday.com)
- Change Advisory Board (CAB) Standard, Reed College
- Operational Change Management Practical Guide, Virginia Tech
- Transformative ITIL 4 adoption, Hewlett Packard Enterprise success story
- CMS Policy for Change Management