SOP owner: IT / Operations — Last reviewed: [Date] — ID: SOP-IT-002
Overview
The Change Management process ensures that changes to systems, processes, and infrastructure are introduced in a controlled and coordinated manner to minimize disruption and risk. All significant changes require formal review and approval before implementation. Why this matters: Uncontrolled changes are one of the most common causes of system outages and security incidents. A structured change management process reduces risk, improves predictability, and creates an audit trail. Key stakeholders:| Role | Responsibility |
|---|---|
| Change requester | Submits the Change Request; owns the change |
| IT Security | Reviews security implications; required for all high-risk changes |
| Change Advisory Board (CAB) | Reviews and approves high-risk changes |
| Department head | Approves low- and medium-risk changes for their area |
| Operations | Maintains the change register; coordinates scheduling |
What requires a Change Request
A formal Change Request (CR) is required for any change that could affect the availability, security, or integrity of production systems or core business processes. Examples include:- Deploying new software or infrastructure to production
- Modifying access controls or authentication systems
- Changes to network configuration, firewall rules, or VPN settings
- Migrating data between systems
- Updating integrations or APIs that affect business-critical workflows
- Retiring or replacing a system used by employees or clients
- Routine maintenance within a pre-approved maintenance window
- Emergency changes to restore service (these are documented retroactively — see Emergency Changes)
- Minor content or configuration changes with no system-level impact (e.g., updating a document)
Change categories
Changes are categorized by risk level:| Category | Description | Approval required |
|---|---|---|
| Standard | Pre-approved, routine changes with well-understood steps and low risk | Department head (pre-approved templates) |
| Low | Minor changes with limited scope, reversible, minimal impact if they fail | Department head |
| Medium | Moderate scope and impact; risk is manageable but warrants IT review | IT lead + Department head |
| High | Broad impact, difficult to reverse, or high risk if something goes wrong | Change Advisory Board (CAB) |
| Emergency | Unplanned change required immediately to restore service | Post-implementation review required |
Process steps
Submit a Change Request
Who: Change requesterAll changes begin with a formal Change Request (CR) submitted through [change management system — link to be added]. The CR must include:
- Change description — What is changing and why
- Business justification — The purpose and expected outcome
- Scope — Systems, services, or data affected
- Proposed implementation date and time — Including time zone
- Rollback plan — Specific steps to reverse the change if it fails
- Testing approach — How the change will be validated before and after
- Named approvers — Based on the risk category
Risk categorization
Who: IT / OperationsIT or Operations reviews the CR and assigns a risk category (Standard, Low, Medium, High). The requester is notified of the assigned category and any additional information needed before review can proceed.If the requester disagrees with the risk categorization, they may escalate to the IT Lead or Head of Operations for a final determination.
Review and approval
Who: Approvers per risk categoryApprovers review the CR and may:
- Approve — Change proceeds on the proposed schedule
- Approve with conditions — Change may proceed subject to specific requirements (e.g., additional testing, restricted window)
- Defer — Change should be rescheduled (e.g., conflicts with a business-critical period)
- Reject — Change cannot proceed as submitted; requester must revise and resubmit
Schedule and communicate
Who: Change requester + OperationsOnce approved, Operations schedules the change and communicates to affected stakeholders:
- Maintenance window — When the change will occur
- Expected impact — Any downtime or degraded service
- Contact point — Who to notify if something goes wrong
- Rollback trigger — Under what conditions the change will be reversed
Implement
Who: Change requester (with IT support as needed)The change is implemented per the approved CR. During implementation:
- Follow the documented steps exactly
- Monitor for unexpected behavior in real time
- Keep the rollback plan ready to execute
- Log any deviations from the plan in the CR
Post-implementation review
Who: Change requester + ITWithin 5 business days of implementation, the requester documents the outcome in the CR:
- Did the change achieve its intended result?
- Were there any unexpected side effects?
- Did the rollback plan need to be executed? If so, why?
- What would be done differently next time?
Emergency changes
An emergency change is an unplanned change required immediately to restore a degraded or down service. Emergency changes bypass normal approval gates but must be documented retroactively. Procedure for emergency changes:- Notify the IT Lead and On-Call contact before making any change
- Document what is being changed and why (verbally or in writing)
- Implement the minimum change required to restore service
- Submit a retroactive CR within 24 hours of the change
- Schedule a post-incident review within 5 business days
Change Advisory Board (CAB)
The CAB reviews high-risk changes and provides a structured forum for assessing risk, coordinating scheduling, and sharing learnings. CAB members include:- Head of IT / CTO (chair)
- IT Security Lead
- Head of Operations
- Representatives from affected business units (as needed)
SOP owner: IT / Operations