Many incidents start with a change: a patch without an impact check, a configuration pushed outside its window, a release with no way back. SMC Consulting's ITIL v4 certified consultants set up change management in HaloITSM so every change has the right level of control: standard changes flow, normal changes get a proportionate review, and your CAB decides with the impact in front of it.
The full theory is in our guide to change management in ITSM and in the ITIL processes explained. Change enablement is one of the practices of our practical guide to ITSM; this page is about running it in HaloITSM, the tool we recommend most often.
Source: the ITIL 4 Change Enablement practice, ITIL 4 by PeopleCert.
Standard, normal and emergency changes each follow their own workflow, approvals and templates.
Affected services and CIs come from the CMDB relationships, so the risk assessment rests on real dependencies.
Implementation plan, test evidence and rollback steps sit on the change itself, where the CAB and the implementer read them.
Planned changes, maintenance windows and freeze periods in one calendar, so collisions show before they happen.
A live demo on one of your own change scenarios, or a free trial: 30 days, 15 of them guided by SMC Consulting.
The seven stages of the change lifecycle, each mapped to what we configure in HaloITSM (CAB review and authorisation share one step).
One RFC template per change type: what changes, why, the affected services and the rollback plan. No RFC, no change.
A risk and impact matrix scores the change and sets its type, which decides the approval path.
Implementation tasks, owners, the maintenance window and the test approach, checked against the change calendar.
Approval steps by risk level: pre-authorised, team lead, CAB or ECAB, each decision recorded on the change.
Tasks executed in the window, with the service desk aware of the change and the rollback ready to trigger.
Did it work, did it cause incidents, what do we keep? The review closes the change and feeds the knowledge base.
In ITIL 4, the change advisory board (CAB) is one form of change authority, not a meeting every change must pass. Standard changes are pre-authorised and never reach it. Normal changes go to the authority that matches their risk: a team lead for a low-risk change, the CAB for a change that can hurt several services. Emergency changes go to a small emergency CAB (ECAB) that can decide quickly, on demand.
| CAB | ECAB | |
|---|---|---|
| Which changes | Normal changes above the agreed risk level | Emergency changes that cannot wait for the next CAB |
| When it meets | On a fixed rhythm, often weekly, with an agenda of the changes awaiting review | On demand, as soon as an emergency change is raised |
| Who sits on it | The change manager (chair), service owners, IT operations, security, and a business representative for high-impact changes | The change manager or a delegate, the service owner and the technical lead; security when relevant |
| What HaloITSM records | The approval step on each change, the risk and impact assessment, the comments and the decision | A shorter approval path, the reason for urgency, and a mandatory review after implementation |
In HaloITSM, the CAB works from the list of changes awaiting review and the change calendar, so the agenda builds itself from the records rather than from a spreadsheet. Approvers are notified by email and in Microsoft Teams. We set the risk levels and approval chains with you, so the CAB spends its time on the changes that matter.
Our method, applied to change, in Belgium, Luxembourg and France.
Not sure where your change process stands today? Book my free ITSM audit: 30 minutes with a senior consultant. Still choosing a tool? Our comparison of the 10 best ITSM tools sets HaloITSM against the alternatives.
A senior consultant reviews how changes are raised, approved and recorded today, and where incidents come from.
Change types, the risk matrix, change authorities and the standard change catalogue agreed with your teams.
RFC templates, approval workflows, the change calendar and the CAB view built in HaloITSM.
Change managers, CAB members and implementers trained on your own scenarios; the first CABs run with us in the room.
The KPIs below measured again, the standard change catalogue grown, and the approval chains adjusted.
A problem often ends in a change that removes the root cause; the problem record stays linked until the change is reviewed.
An incident raised after a change is linked back to it, which is how the change failure rate is measured rather than guessed.
Each change names the configuration items it touches, so the CAB sees the dependent services and the CMDB is updated when the change closes.
Who see incidents after changes and want a process that prevents them without slowing every patch.
Who want a CAB that reviews the right changes with the impact in front of it.
Who must show auditors who approved what, when, and on which evidence.
Usually the change manager, who prepares the agenda, runs the meeting and makes sure each decision is recorded. The members depend on the change: service owners, IT operations, security and, for high-impact changes, a business representative.
When a change must happen before the next CAB: to restore a service, close a security vulnerability or meet a legal deadline. The ECAB is small and can decide fast; the change still gets a review after implementation.
A standard change is low-risk, repeatable and pre-authorised, such as adding a user to a group. A normal change is assessed and authorised according to its risk. An emergency change is needed immediately and follows a shortened approval path.
Approvers can be notified in Microsoft Teams and open the change from there to approve or reject it; the decision is recorded on the change in HaloITSM. We show the exact flow on your own Teams tenant during the demo.
It depends on the number of change types, approval chains and integrations. Change can be part of the first release of a HaloITSM implementation or follow once incident and request management are stable. Your change models and approval chains set the plan, which we date with you after scoping.
A problem often ends in a change that removes the root cause, and an incident after a change is linked back to it. Both links live in HaloITSM, which is how the "changes causing incidents" KPI is measured. See problem management in HaloITSM.
Book a live demo on your own change scenarios. You can also start a free trial: 30 days, 15 of them guided by SMC Consulting.
Learn how the ServiceNow MCP server connects AI agents to governed ITSM workflows, Action Fabric and secure enterprise automation, plus readiness steps for 2026.
Read more →
Learn how a HaloITSM Lansweeper integration connects discovery data to HaloITSM, enabling cleaner CMDB records, faster triage, and better change decisions.
Read more →
A practical ServiceNow migration cutover plan helps reduce risk, protect service continuity, validate integrations and support confident ITSM modernisation.
Read more →
