ServiceNow Change Management: Roles, Process & Change Types

Introduction: Why Change Management Is the Backbone of ITSM

Every IT organization eventually asks the same question: how do we make changes to our systems without breaking something important? That question is exactly what ServiceNow Change Management was built to answer.

Whether you are an IT professional managing enterprise infrastructure, a ServiceNow administrator configuring workflows, or a candidate studying for the CIS-ITSM certification, understanding change management is not optional — it is foundational. This guide breaks down everything you need to know: what a change actually is, who is responsible for what, how the change request lifecycle works, and how Standard, Normal, and Emergency changes differ.

What Is a Change in ServiceNow?

In ServiceNow, a Change is any addition, modification, or removal of an IT service, system, or piece of infrastructure that has the potential to impact the business. That could be a server upgrade, a firewall rule change, a new application deployment, or something as small as a configuration tweak on a critical Configuration Item (CI).

The keyword is potential. You do not need proof that something will go wrong — you just need the possibility, which is why even routine-looking updates flow through a formal review process.

What Is Change Request Management?

Change Request Management is the structured, end-to-end process for handling that potential impact. It governs a change's full lifecycle — submission, evaluation, approval, implementation, and post-implementation review — so that every change is deliberate, documented, and reversible if something goes wrong.

The goal is not to slow teams down for its own sake. It is to reduce risk and downtime while keeping the organization audit- and compliance-ready.

Key Roles in ServiceNow Change Management

Understanding who does what is one of the most heavily tested areas in ITSM certification exams — and one of the most useful things to get right in a real production environment.

Change Initiator

The person who proposes the change. They gather the relevant details, document the business case, and put together an initial implementation plan. In many organizations, a software developer fills this role when the change originates from a code or application deployment.

Change Owner

The person accountable for the change record itself. The Change Owner drives the request through its lifecycle, keeps the documentation accurate, and ensures related tasks (implementation, testing, backout) actually get completed.

Change Manager

The process owner. The Change Manager runs the Change Advisory Board (CAB), coordinates across teams and stakeholders, and holds final decision-making authority — approving or rejecting proposed changes and directing how approved changes get implemented.

Change Advisory Board (CAB)

A cross-functional group — often technical leads, service owners, and business stakeholders — that evaluates proposed changes and provides a recommendation. This is a critical nuance: the CAB advises, but it is the Change Manager who makes the final call.

Quick Reference: Roles at a Glance

Role	Function
Change Initiator	Proposes the change and drafts the plan
Change Owner	Owns the record and drives it to completion
Change Manager	Approves/rejects and directs implementation
CAB	Evaluates risk and provides recommendations
Software Developer	Frequently acts as the Change Initiator

Why Change Management Matters: Core Business Benefits

Organizations invest in disciplined change management because it delivers measurable, recurring value:

• Minimizes risk by controlling how IT changes are introduced
• Enforces approval so nothing reaches production without sign-off
• Creates a full audit trail of every change's history and business impact
• Supports compliance with frameworks like ISO 20000, SOX, and internal governance standards
• Improves cross-team coordination, preventing conflicting changes from colliding during execution

How to Create a Change Request in ServiceNow (Step-by-Step)

1. Navigate: Go to Change → Create New in the Application Navigator.
2. Select a Change Type: Standard, Normal, or Emergency — this decision determines the entire approval workflow.
3. Complete required fields: Short Description, Assignment Group, Configuration Items (CIs), Planned Start/End Dates, Risk, and Impact.
4. Add supporting tasks as needed: Implementation Task, Test Task, and Backout Task (a rollback plan is expected for anything beyond a Standard change).
5. Submit the request, which enters the appropriate workflow for review, approval, and scheduling.

Types of Changes: Standard vs. Normal vs. Emergency

Choosing the right change type is one of the most important decisions in the process — it determines how much governance a change goes through and how fast it can move.

Standard Change

Pre-authorized, low-risk, and repeatable. Standard changes are built from a template or catalog item that was already vetted once; because the risk assessment happened at template-creation time, individual instances skip CAB review and formal approval. Think: provisioning a known VM image, or adding a user to a distribution list.

Normal Change

The default path for anything that is not routine or urgent. Normal changes go through formal review — risk and impact assessment, CAB evaluation, and Change Manager approval — before they are scheduled and implemented.

Emergency Change (EC)

Reserved for changes that must happen immediately to resolve a critical incident or prevent serious business impact. Emergency changes typically bypass the standard approval workflow for speed, but they are still governed:

1. Identify the need
2. Create the Emergency Change record
3. Implement immediately
4. Conduct a Post-Implementation Review (PIR) to document outcomes and lessons learned

Standard vs. Normal vs. Emergency: Comparison Table

Attribute	Standard	Normal	Emergency
Risk level	Low, well-known	Variable	High/urgent
Approval timing	Pre-approved via template	Before implementation	After the fact (via PIR)
CAB involvement	Not required	Usually required	Not required upfront
Speed	Fast	Planned/slower	Immediate
Common trigger	Routine, repeatable request	Planned enhancement or project work	Active incident or imminent risk

Frequently Asked Questions

What is the difference between a Change Manager and the CAB in ServiceNow? The CAB evaluates proposed changes and makes recommendations. The Change Manager holds final approval authority and makes the actual decision to approve, reject, or reschedule a change.

Do Standard Changes require CAB approval? No. Standard Changes are pre-authorized through a vetted template or catalog item, so they skip individual CAB review and formal approval at the time of submission.

What happens after an Emergency Change is implemented? A Post-Implementation Review (PIR) is conducted to document what happened, confirm the change achieved its goal, and capture lessons learned — even though formal pre-approval was bypassed.

Who typically acts as the Change Initiator? Anyone can initiate a change, but in practice it is frequently a software developer or engineer proposing a change tied to a deployment or fix.

Why is Change Management important for certification exams like CIS-ITSM? Because it is one of the most heavily weighted process areas — exams frequently test the distinction between roles (especially CAB vs. Change Manager) and the differences between change types.

Key Takeaways

• A Change is any modification with the potential to impact the business — not just changes guaranteed to cause problems.
• Roles matter: Initiator proposes, Owner drives, CAB advises, Change Manager decides.
• Change type selection (Standard, Normal, Emergency) determines the governance path a change follows.
• Even Emergency Changes — which bypass upfront approval — remain accountable through a mandatory Post-Implementation Review.

Where to go next

Explore related ITSM processes to see how they interconnect with Change Management across the platform:

• Incident Management — where many changes originate
• Problem Management — root-cause fixes that trigger changes
• CMDB & Configuration Management — the CIs a change affects
• Test yourself with a free CIS-ITSM practice test