Change Management ITIL SOP
An ITIL change management SOP for logging, reviewing, approving, implementing, and validating IT changes with clear roles, risk checks, and rollback points. Use it to control change, reduce outages, and document decisions.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: It Services · Saas · Financial Services · Healthcare · Manufacturing
Overview
This Change Management ITIL SOP template defines how to record, assess, approve, implement, and verify an IT change before it affects production services. It is built for teams that need a repeatable change record, clear ownership, and a documented decision trail for routine, standard, or higher-risk changes.
Use it when a change could affect availability, security, performance, configuration, or user access. The template helps the requester capture the request cleanly, the reviewer check completeness, the approver evaluate risk and impact, and the implementer follow a controlled window with verification and escalation points. It also supports CAB review where coordination across service owners, operations, security, or business stakeholders is required.
Do not use this template as a substitute for a detailed technical runbook when the work itself is complex; instead, link the SOP to the runbook and use the SOP as the control layer. It is also not meant for truly trivial changes that your organization has formally classified as standard and pre-approved, unless you want the record for audit or traceability. The template is most useful when a missed step, unclear approval, or unverified outcome would create a service incident or a non-conformance.
Standards & compliance context
- This template supports ISO 9001-style documented information by recording the request, approval, implementation, and verification trail for controlled changes.
- It aligns with ITIL change management practices by separating request intake, risk review, authorization, execution, and post-change validation.
- Where changes affect security, access, or production stability, the approval and escalation structure helps demonstrate controlled operations during audits or internal reviews.
- If the change is part of a regulated environment, the record can support GMP, HACCP-adjacent controls, or other quality systems by showing who approved the deviation and how it was verified.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Steps
This section matters because it turns the change from an idea into a controlled sequence with ownership, approval, execution, and verification.
-
Log the change request
The change initiator records the change request in the change management system and includes the change title, business justification, affected services, requested implementation window, and requester contact information. The initiator classifies the change as standard, normal, or emergency if your process requires an initial classification.
-
Verify completeness of the request
The change manager verifies that the request includes scope, business reason, affected configuration items, dependencies, test evidence if available, implementation window, and rollback approach. If required information is missing, the change manager returns the request to the initiator for correction.
-
Assess risk and impact
The change manager and relevant technical owner assess the change for service impact, security impact, operational risk, customer impact, and dependency conflicts. The team documents the risk rating, expected downtime or degradation, test requirements, and any tolerance limits for the change window.
-
Consult stakeholders and CAB
The change manager notifies affected stakeholders, service owners, and the Change Advisory Board (CAB) as required by the change type and risk level. The change manager records feedback, objections, scheduling constraints, and any required conditions for approval.
-
Approve, defer, or reject the change
The authorized approver reviews the risk assessment, implementation plan, rollback plan, and stakeholder input. The approver decides whether to approve the change, defer it for more information or a better window, or reject it based on business risk and operational readiness.
-
Prepare the implementation window
The change implementer confirms the maintenance window, assigns roles, validates access, and verifies that monitoring, backups, and rollback steps are ready. The implementer communicates the planned start time, expected service impact, and escalation contacts to affected parties.
-
Implement the approved change
The implementer performs the change exactly as approved, follows the documented sequence, and records the actual start time, end time, and any deviations from the plan. The implementer pauses and escalates if the change exceeds tolerance limits, produces unexpected errors, or affects unapproved systems.
-
Verify service stability
The system owner or designated verifier checks service health, error rates, performance metrics, and user-facing functionality against the acceptance criteria. The verifier confirms whether the change met the expected outcome and whether any incident or non-conformance must be opened.
-
Document deviations and incidents
The change manager records any deviation from the approved plan, including timing changes, failed steps, rollback actions, service degradation, or incidents. The change manager links related incident records and identifies corrective and preventive actions if required.
-
Complete post-implementation review
The change manager conducts a post-implementation review for normal and high-risk changes. The review confirms whether the change met the business objective, whether the implementation followed the approved plan, whether rollback was needed, and whether any follow-up actions are required.
-
Close the change record
The change manager verifies that approvals, implementation notes, test results, incident links, and post-implementation review outcomes are attached to the record. The change manager then closes the change in the system and retains the documented information according to the organization’s record retention requirements.
-
Escalate rejected or failed changes
The change manager escalates rejected changes, failed implementations, or unresolved service impacts to the service owner, incident manager, or problem manager as appropriate. The escalation includes the reason for rejection or failure, current service status, and the required next action.
How to use this template
- The requester logs the change request with the affected service, reason, planned timing, expected outcome, and rollback summary.
- The change manager or reviewer verifies completeness of the request, confirms the owner and implementation role, and returns missing details for correction.
- The approver assesses risk and impact, consults stakeholders or the CAB when needed, and records approve, defer, or reject with the reason.
- The implementer prepares the implementation window, confirms prerequisites, and checks that the rollback plan, access, and required tools are ready.
- The implementer executes the approved change, records any deviation immediately, and escalates if the change exceeds tolerance or fails verification.
- The service owner or competent person verifies service stability, closes the record with outcomes and evidence, and opens follow-up action items for any non-conformance.
Best practices
- Write one change request per distinct service impact so the approval and rollback path stays clear.
- Require a named implementation role and a named verifier so accountability does not disappear during the window.
- Capture the rollback trigger before approval, not after implementation starts.
- Use explicit tolerance language for acceptable downtime, performance drift, or configuration deviation.
- Photograph or attach evidence of pre-change and post-change states when the change affects physical or visual controls, dashboards, or configuration screens.
- Escalate immediately when the actual outcome differs from the approved scope, even if the change still appears to be working.
- Link the SOP to the technical runbook, ticket, or deployment record so the change record and execution steps stay synchronized.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What does this change management SOP cover?
This template covers the full ITIL-style change flow from logging a request through completeness review, risk assessment, stakeholder consultation, approval, scheduling, implementation, and post-change verification. It is designed for standard, normal, and higher-risk changes that need documented control. It also includes escalation and rollback points so the team knows what to do if the change deviates from plan.
When should we use this SOP instead of an ad-hoc change?
Use this SOP whenever a change could affect service availability, security, configuration integrity, or user experience. It is especially useful for production systems, network changes, access changes, patching, and infrastructure updates. Ad-hoc changes are a common source of missed verification and unclear ownership, which this template helps prevent.
Who should run the process?
The change owner or requester usually starts the record, while the change manager or service owner coordinates review and approval. Technical implementers carry out the change, and a competent person or service owner should verify the outcome. For higher-risk changes, the CAB or designated approver should review the risk, impact, and rollback plan before execution.
How often is this SOP used?
It is used each time a change is proposed, whether that is daily for operational teams or less often for project-driven work. Many organizations use the same SOP for routine maintenance, emergency changes, and planned releases, with different approval paths. The cadence depends on how frequently your environment changes, but the record should exist for every controlled change.
Does this template align with ITIL and audit expectations?
Yes. The structure follows ITIL change management practices by requiring documented request intake, impact review, approval, implementation, and validation. It also supports ISO 9001-style documented information expectations because the record shows what was changed, who approved it, and what verification occurred. That makes it easier to demonstrate control during audits or internal reviews.
What are the most common mistakes when using a change SOP?
Common mistakes include skipping completeness checks, approving without a rollback plan, and treating the implementation window as optional. Another frequent issue is failing to record deviations, which makes troubleshooting and post-change review difficult. Teams also sometimes forget to confirm service stability after the change, leaving incidents to surface later without clear ownership.
Can we customize this for emergency changes or low-risk changes?
Yes. You can add a fast-track path for low-risk standard changes and a separate emergency approval path for urgent fixes. The key is to keep the same core controls: documented request, risk review, implementation owner, verification, and post-change review. Customization should change the approval depth, not remove accountability.
How does this connect with other IT processes and tools?
This SOP can link to incident management, problem management, release management, asset records, and configuration management databases. It also works well with ticketing systems, CAB calendars, and deployment tools because those systems can store approvals, timestamps, and implementation notes. If your team uses runbooks, this SOP can point to the exact implementation steps and verification checks.
What should we do if the change fails during implementation?
The SOP should require the implementer to stop at the defined escalation point, notify the approver or incident lead, and execute the rollback or contingency plan if safe to do so. If rollback is not possible, the team should document the deviation and open an incident or problem record immediately. The post-change review should capture the failure mode so the same issue does not repeat.
Related templates
Ready to use this template?
Get started with MangoApps and use Change Management ITIL SOP with your team — pricing built for small business.
