Normal Change ITIL: How to Manage Changes Without Chaos

If you've worked in IT for more than a month, you've probably sat through a Change Advisory Board (CAB) meeting that felt like a complete waste of time. I've been there — six people on a call, arguing about a normal change that should've taken 10 minutes. The ITIL framework defines three types of changes: standard, normal, and emergency. But the normal change is the one that trips up most teams. It's not automated like standard changes, and it's not urgent like emergency ones. It sits in the middle, and if you don't handle it well, it becomes a bottleneck.

In this guide, I'll walk you through everything I've learned about ITIL normal change management from years in the trenches. You'll get the exact steps, real examples, and the pitfalls everyone falls into — plus the FAQ that actually answers your pain points.

What Exactly Is a Normal Change in ITIL?

According to the ITIL 4 framework, a normal change is any change that isn't pre-approved (standard) and doesn't need immediate deployment (emergency). It requires assessment and approval through a formal process — often via the CAB. The key difference from a standard change is that a normal change has a unique risk profile each time, so you can't just execute it from a checklist.

I've seen organizations label a routine server update as a normal change, and then wonder why everything slows down. Normal changes are meant for modifications that are not fully predictable. For example: migrating a database to a new version, deploying a new software module, or restructuring a network segment. Each instance carries variables that need a fresh risk assessment.

But here's the thing — many teams default to normal change for everything because they never bother to define standard changes properly. That's the first mistake you want to avoid.

How the Normal Change Process Works (Step by Step)

Let's break down the typical lifecycle of a normal change. I'll use a real scenario: upgrading a critical internal CRM from version 3.1 to 4.0.

Step 1: Initiation

The change requester (say, the CRM admin) creates a Request for Change (RFC) in the IT service management (ITSM) tool. This RFC includes: description, reason, implementation plan, rollback plan, risk category (low/medium/high), and impact assessment. I always tell my teams: don't skip the rollback plan. I've seen too many RFCs with “rollback: restore from backup” — that's not a plan if the backup is two days old. Be specific: “Run the restore script from /scripts/rollback-crm.sh and verify data integrity within 30 minutes.”

Step 2: Assessment

The change manager (or CAB) reviews the RFC. This is where the “normal” part gets real. For low-risk changes, a single person might approve. For medium or high, it goes to the CAB meeting. In my experience, the CAB works best when it's not a weekly meeting but a daily standup (or even a Slack thread). Speed matters. If your CAB meets only on Wednesdays, you're creating a 7-day lead time for every normal change. That's unacceptable in modern IT.

Step 3: Approval

The CAB either approves, rejects, or asks for more info. A good CAB doesn't just rubber-stamp — they ask sharp questions. “What's the rollback time?” “Has the vendor tested this version with our logging system?” “Who's on standby if it fails?” I once had a CAB member who always asked “What's the worst that can happen?” and that single question prevented several disasters.

Step 4: Implementation

The assigned team executes the change during the scheduled maintenance window. For the CRM upgrade, they'd back up the database, install the new package, run migration scripts, and verify functionality.

Step 5: Review & Closure

After the change, it's closed in the tool. But a formal post-implementation review (PIR) happens for high-risk normal changes. Did the actual outcome match the plan? What can be improved? I've found that teams often skip PIR for normal changes, but that's where you learn to convert them into standard changes over time.

Normal Change vs. Standard Change vs. Emergency Change

One of the biggest sources of confusion in ITIL is the difference between these three. Let me lay it out clearly.

A mistake I often see is teams treating all changes as normal because they haven't built a standard change library. Spend a quarter identifying the top 20 recurring low-risk changes and move them to standard. Your velocity will jump.

When Should You Use a Normal Change? (Real Examples)

You should use a normal change when the activity isn't already a standard change and doesn't require immediate deployment. But that's too generic. Here are three real scenarios where normal change is appropriate:

• Database migration with schema changes: Even if you've done it before, each migration might have different data volumes or column changes. You need a fresh risk assessment.
• Adding a new third-party integration: The API might behave differently in production. A normal change lets you test and rollback if needed.
• Changing a core network configuration: Firewall rules, load balancer tweaks — these affect multiple services. It's not standard (too risky) and not emergency (planning possible).

What about something like “updating a wiki page”? If it's a standard change (pre-approved), great. If your organization hasn't defined it, someone might submit it as normal — and that's exactly the kind of waste you want to eliminate. I've literally seen a CAB discuss a wiki update for 20 minutes. Don't let that be your team.

Common Mistakes Teams Make with Normal Changes (and How to Avoid Them)

I've audited dozens of change management processes; these are the top three things that slow teams down.

Mistake 1: The CAB is a bottleneck

If your CAB only meets once a week and you have 50 normal changes pending, you're already failing. My non-obvious tip: split the CAB into two — a triage CAB (daily 15-minute meeting) for low-risk normal changes, and a strategic CAB (weekly) for high-risk ones. I've seen average approval time drop from 5 days to 1 day with this change.

Mistake 2: No explicit rollback criteria

The RFC asks for a rollback plan, but most teams write “reverse change” and think that's enough. Clarify: “What metric tells you the change failed? What's the automatic rollback trigger?” For example, if error rate increases by >5% within 10 minutes, automatically roll back. Without that threshold, you're making decisions under pressure — and that's when mistakes happen.

Mistake 3: Treating every normal change as unique

After a normal change is done successfully three times under similar conditions, you should promote it to a standard change. I've worked with teams that have done the same server patch 50 times and still call it normal. That's bureaucratic inertia. Create a quarterly review where the change manager identifies repeatable normal changes and moves them to standard.

Best Practices for Managing Normal Changes in ITIL

Here's what I've found works in practice — not just textbook theory.

• Use a centralized ITSM tool with automation. Tools like ServiceNow or Jira Service Management can enforce mandatory fields, auto-assign risk scores, and even trigger automatic approvals for low-risk normal changes. I've seen teams use an ITIL module to score each RFC based on scope, impact, and complexity. That score determines if it needs a full CAB or just a manager sign-off.
• Create a culture of pre-approval for certain categories. At one client, we pre-approved all normal changes for non-production environments (dev, test). That cut approval time by 40% without increasing incidents.
• Implement a “change freeze” calendar. We defined periods (like end-of-quarter) where no high-risk normal changes were allowed. It forced teams to plan ahead. One team hated it, but their incident rate dropped sharply.
• Measure what matters. Don't just track number of changes approved. Track average time to approve (by risk level), change success rate (percentage that didn't cause incidents), and number of normal changes escalated to emergency. That last one is a red flag for poor planning.

Practical Checklist for Normal Change Success

Use this checklist when preparing any normal change RFC. I print it out and tape it near my desk.

• ☐ RFC contains clear scope and justification — why is this change needed?
• ☐ Risk assessment completed (low/medium/high) with rationale.
• ☐ Implementation plan includes specific commands or scripts.
• ☐ Rollback plan includes automated threshold (e.g., “rollback if error rate >5%”) and manual steps with estimated time.
• ☐ Testing results from staging or similar environment attached.
• ☐ Communication plan — who needs to know before and after?
• ☐ Scheduled window — does it conflict with any change freeze or other major changes?
• ☐ Post-implementation review planned for high-risk changes.

If you can't tick all boxes, the change isn't ready. I've seen teams skip the testing attachment and then blame the CAB for delaying. Don't be that team.

Frequently Asked Questions

This article is based on real ITIL experience and has been accuracy-checked against the ITIL 4 framework.