Change Management in IT Operations: Reducing Risk

Studies consistently show that between 60% and 80% of IT outages are caused by changes — not hardware failures, not cyberattacks, but well-intentioned modifications that introduced unintended consequences. A network engineer updates a switch ACL and accidentally blocks a critical VLAN. A sysadmin applies a Windows update that breaks a line-of-business application. A developer pushes a config change to production instead of staging. Change management exists to inject a pause between "I want to change something" and "I have changed something," filling that pause with risk assessment, peer review, approval, scheduling, communication, and rollback planning.

For managed service providers, change management is also a contractual obligation. Many SLAs explicitly state that outages caused by unapproved changes are not eligible for service credits — meaning the MSP bears the full cost of remediation. Regulatory frameworks like ISO 27001 and the Essential Eight require documented change control processes. Clients undergoing audits will ask for evidence of your change management practice, and the absence of one can disqualify you from enterprise contracts.

ITIL (Information Technology Infrastructure Library) defines a widely adopted change management workflow. The process begins with a Request for Change (RFC), which is a formal document or ticket describing what will change, why it is needed, what systems are affected, and what the rollback plan is. The RFC is then assessed for risk, impact, and resource requirements. Low-risk changes may be pre-approved under standard change policies, while higher-risk changes are reviewed by a Change Advisory Board (CAB). Once approved, the change is scheduled, implemented during an agreed maintenance window, tested, and then closed with a post-implementation review (PIR) to capture lessons learned.

Not every change needs to go through the full CAB review. ITIL categorises changes into three types to balance speed with control. Standard changes are low-risk, pre-approved, and follow a documented procedure — think adding a new user account, deploying a pre-tested patch to a known platform, or provisioning a new mailbox. These are logged for audit purposes but do not require individual approval. Normal changes require full assessment and CAB approval because they carry moderate to high risk — examples include firewall rule changes, server migrations, or software upgrades. Emergency changes bypass the normal scheduling process because they address an active incident or critical vulnerability, but they still require expedited approval (often from a smaller Emergency CAB or ECAB) and must be retrospectively documented.

The CAB is a cross-functional group responsible for evaluating and approving normal changes. Its membership typically includes the change manager (who chairs the meeting), representatives from the technical teams affected by the change, a service delivery or account manager who can speak to client impact, and occasionally the client themselves for high-impact changes. The CAB meets on a regular schedule — weekly is common — to review pending RFCs. For each change, they assess the risk, confirm the rollback plan is viable, check for scheduling conflicts with other changes or business events, and either approve, reject, or defer the change.

A common pitfall is making the CAB too large or too bureaucratic, which slows the process to the point where engineers start bypassing it. Keep the standing membership small — three to five people — and invite additional stakeholders only when their specific expertise is needed. Use a structured agenda, time-box each RFC review to five minutes, and distribute RFC details before the meeting so members arrive prepared. The goal is informed decision-making, not death by committee.

Every change must have a documented rollback plan — a step-by-step procedure for reverting the environment to its pre-change state if something goes wrong. The rollback plan should be tested where possible, not just theoretical. For example, if you are upgrading a firewall firmware, your rollback plan should include having the previous firmware image on hand, confirming the downgrade procedure works on a lab device, and knowing the expected rollback time. If a rollback is not feasible (such as a database schema migration that cannot be reversed), this must be explicitly acknowledged in the RFC so the CAB can factor that irreversibility into their risk assessment.

Most ITSM (IT Service Management) platforms include change management modules. ServiceNow is the enterprise standard, offering full ITIL-aligned change workflows with risk calculators, approval chains, and integration with CMDB (Configuration Management Database) for impact analysis. Jira Service Management provides lighter-weight change management that integrates tightly with development workflows — useful for DevOps teams. ConnectWise Manage and Datto Autotask include change management features within their PSA platforms, making them natural choices for MSPs who already use these tools for ticketing and billing. For infrastructure-as-code environments, tools like Terraform and Ansible provide version-controlled, auditable change execution that complements the ITSM approval process.

After a change is implemented, a Post-Implementation Review (PIR) evaluates whether the change achieved its objective, whether any unintended side effects occurred, and whether the process itself worked well. PIRs are especially important for failed changes — understanding why a rollback was triggered prevents the same mistake recurring. Document PIR findings in the change record and feed improvements back into your standard operating procedures. Over time, PIR data also helps you calibrate risk assessments more accurately, as you build a historical record of which types of changes succeed reliably and which are prone to complications.

Traditional CAB-driven change management can feel at odds with DevOps culture, where the goal is frequent, small, automated deployments. The solution is not to abandon change management but to adapt it. Classify CI/CD pipeline deployments that pass automated testing and follow approved patterns as standard changes — pre-approved and logged automatically. Reserve CAB review for infrastructure changes, architectural shifts, and anything that touches shared services. This approach maintains governance without throttling deployment velocity, and it aligns with the ITIL 4 principle of "optimise and automate."

Start by classifying your most common changes and building a standard change catalogue — this alone can reduce CAB workload by 50% or more. Implement a simple RFC template in your PSA tool, set up a weekly CAB meeting with a lean standing membership, and enforce the rule that no production change happens without a logged record. Train your engineers to write clear rollback plans, and conduct PIRs for every failed change. Over time, your change success rate will improve, your outage frequency will drop, and you will have the documentation to prove it to clients and auditors alike.