Change

What Is Change?

Change is the addition, modification, or removal of anything that could affect IT services. In ITSM and ITIL frameworks, a change represents a planned alteration to the IT environment—whether infrastructure, applications, documentation, processes, or configurations—that must be assessed, approved, and tracked to minimize service disruption and maintain operational stability. Changes range from routine patches and configuration updates to major system migrations and architectural overhauls, and each carries inherent risk that must be weighed against business need.

The scope of what constitutes a change varies by organization, but the underlying principle remains consistent: any modification to the production environment or service delivery model that could impact availability, performance, security, or user experience requires formal change control. This includes not only technical alterations but also procedural updates, vendor contract modifications, and shifts in service level agreements that affect how IT delivers value to the business.

Why Change Matters

Change is the primary mechanism through which IT evolves to meet business demands, yet it is also the leading cause of unplanned outages and service degradation. Industry data consistently shows that 60–80% of major incidents stem from poorly planned, inadequately tested, or improperly communicated changes. When change processes fail, the consequences cascade: extended downtime, revenue loss, compliance violations, eroded customer trust, and teams forced into reactive firefighting mode instead of strategic work.

Effective change management reduces MTTR by ensuring that responders have complete context when incidents occur—knowing what changed, when, and by whom accelerates root cause identification and rollback decisions. It also protects audit readiness: regulated industries require documented evidence that changes follow approved procedures, maintain separation of duties, and preserve data integrity. Organizations that treat change as an afterthought face not only operational instability but also regulatory penalties and failed audits.

Beyond risk mitigation, disciplined change control enables velocity. When teams trust that changes move through a predictable, transparent workflow with appropriate review gates, they can deploy faster without sacrificing safety. Automation of standard changes—pre-approved, low-risk modifications that follow documented procedures—removes bottlenecks and frees change advisory boards to focus on high-impact decisions. The goal is not to slow delivery but to balance speed with accountability.

How Change Works

Change management follows a structured lifecycle designed to assess risk, coordinate stakeholders, and maintain a complete audit trail. The process begins with a change request, which documents what will change, why it's needed, who is responsible, the implementation plan, the rollback plan, and the expected impact on services and users. This request enters a workflow where it is categorized by risk and urgency—standard, normal, or emergency—which determines the approval path and level of scrutiny required.

For normal changes, a Change Advisory Board (CAB) evaluates the request, reviewing technical feasibility, business justification, resource requirements, and potential conflicts with other planned work. The CAB may approve, reject, or request modifications before granting authorization. Standard changes bypass the CAB because they follow pre-approved templates with known risk profiles, while emergency changes receive expedited review to address critical incidents or security vulnerabilities, often with post-implementation validation.

Once approved, the change moves to scheduling and implementation. The change owner coordinates with affected teams, communicates maintenance windows to stakeholders, and executes the plan according to the documented procedure. Throughout implementation, status updates flow to the ITSM system, and any deviations from the plan are logged. After completion, a post-implementation review verifies that the change achieved its objectives without introducing new issues. If problems arise, the rollback plan is executed and the change is reassessed.

All changes are recorded in the CMDB (Configuration Management Database), linking modifications to specific configuration items and creating a historical record that supports incident investigation, compliance reporting, and continuous improvement. This linkage between change records and incident tickets is foundational to ITxM (IT Collaboration Management), where service, operations, and incident data flow seamlessly across teams to prevent repeated failures and ensure accountability.

Examples of Change

-  A financial services company deploys a quarterly security patch to 500+ servers across production environments.  The change is classified as standard because it follows a tested runbook, includes automated rollback, and has been pre-approved by the CAB. Implementation occurs during a scheduled maintenance window with minimal user impact, and the CMDB is automatically updated to reflect new patch levels across all affected systems.

-  An e-commerce platform migrates its payment processing service from on-premises infrastructure to a cloud-based API.  This normal change requires CAB review due to its high business impact and technical complexity. The change request includes load testing results, a phased rollback plan, and coordination with the vendor's support team. Post-implementation review confirms transaction latency improvements and validates that no customer data was lost during cutover.

-  A healthcare provider's EHR system experiences a critical database corruption issue during peak hours.  An emergency change is initiated to restore from backup and apply a vendor-supplied hotfix. The change bypasses standard approval gates but is documented in real time, with the change owner notifying the CAB within 24 hours. A post-incident review identifies the root cause and creates follow-up changes to prevent recurrence, which are tracked through the normal change process.

Related Terms

- Incident
- Problem
- Change Advisory Board (CAB)
- Configuration Item (CI)
- Release Management

---

Frequently Asked Questions

• How do we decide which changes actually need CAB review versus just rubber-stamping everything through to avoid bottlenecks?
  Build your CAB filter around blast radius and reversibility—if a change affects a tier-1 service or cannot be rolled back within your RTO, it warrants full CAB scrutiny regardless of how routine it feels to the team submitting it. Changes that are low-blast-radius and fully reversible are strong candidates for pre-approval as standard changes, which removes them from the CAB queue entirely. Audit your CAB backlog quarterly and reclassify any change type that has passed review without modification three or more consecutive times—that pattern signals a candidate for standardization.
• What's the most common way change management breaks down in organizations that think they're doing it right?
  The most frequent failure mode is change records that are technically complete but operationally disconnected—teams log the change, get approval, and then execute without notifying downstream service owners or on-call responders, so when something breaks, incident responders have no visibility into what changed minutes before the alert fired. A second common gap is treating the rollback plan as a checkbox rather than a tested procedure; rollbacks that have never been rehearsed routinely fail under production pressure, extending outage windows significantly. Closing both gaps requires integrating your change calendar directly with your on-call scheduling tool so responders always have change context at the moment of alert.
• How should we handle changes initiated by third-party vendors or SaaS providers that we don't control?
  Require vendors to submit change notifications into your ITSM system on a defined lead-time SLA—typically 5–10 business days for normal changes—so your team can assess downstream impact and coordinate freeze windows before the vendor acts. Map each vendor-managed component to its dependent configuration items in your CMDB so that when a vendor change triggers an incident, your responders can trace the impact path without manual investigation. For SaaS providers who won't integrate with your change process, establish a dedicated monitoring alert rule tied to their published maintenance calendars so your on-call team is never caught off-guard.
• When a change causes an incident, what's the right way to hand off between the change owner and the incident response team without losing time?
  The change owner should remain engaged as a technical advisor through the incident bridge rather than handing off entirely—they hold implementation context, deviation logs, and rollback authorization that incident responders cannot reconstruct quickly under pressure. Pre-define in your change template who holds rollback authority and what the trigger threshold is (e.g., P1 incident within 60 minutes of change completion automatically initiates rollback review), so the decision point never stalls on an escalation chain during an active outage. Link the incident ticket to the originating change record at the moment the incident is declared so the post-incident review has a complete, timestamped audit trail without requiring manual reconstruction.
• Is there a point where too many standard changes actually creates risk rather than reducing it?
  Yes—over-standardization creates risk when teams treat the standard change template as a substitute for situational judgment, executing pre-approved procedures against environments that have drifted from the baseline the template was designed for. Configuration drift in the CMDB is the primary culprit: if your CI records are stale, a standard change approved against documented state can behave unpredictably against actual production state. Require standard change templates to include an explicit pre-execution environment validation step, and trigger an automatic template review whenever a standard change generates a post-implementation incident.