If you've ever worked in IT, you know the drill. A developer needs a new test server. A department head requests 50 new software licenses. The security team pushes a critical patch. For years, each of these might have triggered a formal, often sluggish, change management process. Meetings, forms, approvals, delays. It's exhausting and slows everything down.
ITIL 4 flips this script for the right kind of work. It introduces a powerful concept that, when used correctly, can cut through the red tape and make your IT team remarkably efficient: the standard change. This isn't just a minor tweak to the old ITIL v3 way of thinking; it's a fundamental shift towards enabling agility while maintaining control.
Let's cut through the jargon. A standard change in ITIL 4 is a pre-authorized, low-risk, repeatable change that follows a well-defined procedure. Think of it like a recipe. Once the chef (your change advisory board) approves the recipe, any trained cook (your IT staff) can follow it without calling a meeting to ask if making pasta is okay tonight. The outcome is predictable, the steps are known, and the risk is minimal.
What You’ll Learn in This Guide
The Core Definition: What Makes a Change "Standard"?
According to the official ITIL 4 Foundation guidance from AXELOS, a standard change is a change that is "pre-authorized, low-risk, and follows a procedure or work instruction." That's the textbook answer, but it needs unpacking.
In my experience across multiple organizations, a change earns the "standard" label only when it hits three specific marks:
- It's Routine and Repeatable: This isn't a one-off. It's a task you do regularly—resetting a password, provisioning a standard virtual machine, deploying a monthly security update to a non-critical system, renewing a bulk software subscription.
- The Risk is Understood and Acceptable: The potential for something going wrong is low, and the impact of a failure is minimal and contained. If the VM provisioning script fails, it doesn't take down the corporate email. You just try again.
- There's a Locked-Down Procedure: This is the most critical part. The "how" is documented, tested, and cannot be deviated from. The procedure defines the exact steps, tools, checks, and who is authorized to perform it. No improvisation allowed.
A subtle point most guides miss: People often confuse "standard" with "simple." A standard change can be technically complex. Deploying a complex, pre-tested application module via an automated pipeline to a pre-production environment can be a standard change. The complexity is handled by the procedure and automation, not by ad-hoc decision-making during execution. The risk is low because the path is well-trodden and automated.
How Does a Standard Change Work in Practice?
Let's walk through a real scenario. Your company uses a cloud platform, and new hires need a standard development environment.
Under an old, rigid model:
The hiring manager submits a ticket. A sysadmin creates a change request. The request goes to a weekly CAB meeting. Someone asks about cost implications. Another person questions the specific OS version. Approval takes three days. The sysadmin finally builds the environment manually, maybe making a small mistake along the way.
With a properly implemented ITIL 4 standard change:
The hiring manager submits a request tagged "New Dev Env." The service desk tool recognizes this as a trigger for the standard change "SC-102: Provision Standard Developer Workspace." Because it's pre-authorized, it bypasses the CAB queue entirely. An automated workflow kicks off: it checks resource quotas, runs a pre-approved Terraform script in the cloud, installs the standard software package via configuration management, runs a post-deployment health check, and emails the credentials to the new hire. All within an hour. The entire process is logged as a change record automatically.
The Three-Phase Lifecycle of a Standard Change
It's helpful to break it down.
1. Creation & Authorization (The One-Time Setup): This is where the real work happens upfront. A team proposes a repeatable task to become a standard change. They document the procedure, perform a risk assessment, define success criteria, and specify who can execute it. The Change Authority (often a CAB) reviews and pre-approves it once. This authorization is a blanket OK for all future instances that follow the script.
2. Execution (The Repeatable Part): This is the fast, efficient part users see. An authorized person or an automated system triggers the standard change. They follow the baked-in procedure—no new approvals needed. The key is adherence. If you need to tweak the script, you're moving out of "standard" territory and back into a normal change process.
3. Logging & Review (The Control): Every execution is still recorded. You track who did what, when, and the outcome. Periodically (say, every quarter), you review the logs for all executions of that standard change. Are there failures? Is the procedure still optimal? This review might lead to updating the procedure or even revoking its "standard" status if it's become unstable.
Standard vs. Normal vs. Emergency: Knowing the Difference
This is where teams get tangled. They try to force everything into "standard" to avoid process, or they treat everything as "normal" and drown in bureaucracy. Clarity is power.
| Change Type | Risk Level | Approval Process | Example | Key Mindset |
|---|---|---|---|---|
| Standard Change | Low, Pre-defined | Pre-authorized (no CAB for each instance) | Adding a user to a standard mailing list; deploying a pre-tested minor bug fix to staging. | "Follow the recipe." |
| Normal Change | Medium to High | Requires formal assessment and authorization (by CAB or delegated authority) | Upgrading the core database version; implementing a new network firewall rule. | "We need to plan and get approval for this." |
| Emergency Change | Very High (but urgent) | Expedited process, post-implementation review | Applying a zero-day security patch to a live production server under attack. | "Break glass, fix now, justify later." |
The biggest mistake I see? Teams label a change as "standard" but then allow operators to "use their judgment" during execution. That instantly turns it into a normal change without the oversight. If judgment is required, it's not standard.
How to Implement Standard Changes Successfully
Rolling this out isn't about declaring a bunch of tasks "standard." It's a deliberate project. Here’s a battle-tested approach.
Step 1: The Inventory Hunt. Don't brainstorm in a vacuum. Go look at your ticketing system (ServiceNow, Jira, whatever). What requests or tasks do you do 10, 50, 100 times a month? Password resets? Access grants for App X? Specific VM configurations? That's your candidate list.
Step 2: The Risk Filter. For each candidate, run a quick risk assessment. What's the worst that could happen if this procedure fails? If the answer is "a minor inconvenience for one user" or "a service restart that's already accounted for," you're on the right track. If the answer involves financial loss, major service outage, or compliance breach, it's not a standard change candidate.
Step 3: Procedure Lockdown. This is the make-or-break phase. For your top candidate, document the procedure with insane specificity. Use screenshots, code snippets, CLI commands. Remove all ambiguity. Then, test it. Then, have someone else test it following only your document. Does it work identically? Good.
Step 4: Formal Pre-Approval. Take the documented procedure and your risk assessment to your Change Authority. You're asking for a one-time, blanket approval: "Whenever we need to do [Task], we will follow [This Procedure]. Do you authorize this?" Get the sign-off.
Step 5: Integrate and Automate. Bake the procedure into your tools. Create a template in your service desk. Build a runbook in your automation platform (like Rundeck or Ansible Tower). The goal is to make executing the standard change easier than doing it the old, ad-hoc way.
Step 6: The Feedback Loop. Set a calendar reminder to review this standard change in 90 days. Look at the records. Any failures? Any deviations? Use that data to improve the procedure or, in rare cases, pull it back for re-assessment.
Common Pitfalls and How to Avoid Them
I've watched implementations stumble. Here’s what goes wrong.
Pitfall 1: The "Set and Forget" Standard Change. You create it, approve it, and never look back. Three years later, the underlying technology has changed twice, but you're still following the old procedure, now full of hidden risks. The fix: Mandate an annual or bi-annual review for every standard change. Treat the procedure as a living document.
Pitfall 2: Scope Creep in Execution. "Well, while I'm adding this user to the finance group, they also need special access to this legacy report... I'll just do that too since I'm here." This invalidates the risk profile. The extra step wasn't assessed or approved. The fix: Training and culture. Hammer home that deviation is not allowed. If extra work is needed, it's a separate request, possibly triggering a new normal change.
Pitfall 3: Using Standard Changes to Bypass Necessary Governance. This is a political danger. A team wants to avoid scrutiny for a risky change, so they dress it up as a "standard deployment." The fix: Empower your Change Authority to audit standard changes randomly and to revoke status immediately if abused. The threat of losing that efficiency is a powerful deterrent.
