IT Change Management Template: CAB Process & Workflow Guide

What Is IT Change Management?

IT change management is the ITIL practice of controlling the lifecycle of all changes to IT services and infrastructure. A "change" is any addition, modification, or removal of anything that could affect IT services — from a firewall rule update to a full platform migration.

The goal is not to prevent change. It is to reduce the risk of failed changes while maintaining the velocity that the business demands. Without a formal process, teams deploy conflicting changes, skip testing, and lack rollback options when things go wrong.

ITIL 4 renamed this practice to "Change Enablement" to emphasize facilitation over gatekeeping. This guide uses the more widely recognized term "change management." For a broader look at how it fits within ITIL service management, see our ITIL Foundation Templates & Service Management Guide.

The Three Types of Changes

Every IT change management template must classify changes into three types. Each type follows a different approval workflow with different speed and oversight levels.

1. Standard Changes

Definition: Pre-authorized, low-risk changes that follow a documented procedure. These do not require CAB approval for each occurrence.

Examples:

• Password resets
• Adding a user to an existing security group
• Deploying a pre-approved software patch
• Provisioning a standard virtual machine from an approved template
• Updating DNS records for existing services

Approval: Pre-approved by change authority during initial assessment. Executed by the assigned team without per-instance approval.

Template Requirements:

• Documented procedure with step-by-step instructions
• Defined trigger conditions
• Known risk profile (previously assessed)
• Automated where possible

2. Normal Changes

Definition: Changes that must follow the full change management process, including risk assessment and CAB review. This is the default type for any change that is not standard or emergency.

Examples:

• Server operating system upgrades
• Network topology modifications
• Application version deployments
• Database schema changes
• Security policy modifications
• Third-party integration implementations

Approval: Requires formal change request, risk assessment, CAB review, and scheduled implementation window.

Template Requirements:

• Complete change request form
• Risk and impact assessment
• Test plan and results
• Rollback plan
• Communication plan
• Post-implementation review

3. Emergency Changes

Definition: Changes that must be implemented immediately to resolve a high-impact incident or security vulnerability. These bypass the normal CAB schedule but still require authorization.

Examples:

• Critical security patch for an actively exploited vulnerability
• Emergency fix for a production outage
• Regulatory compliance change with an immediate deadline
• Disaster recovery failover

Approval: Authorized by the Emergency CAB (ECAB) — a smaller group that can convene within minutes. Full documentation is completed retroactively.

Template Requirements:

• Abbreviated change request (minimum fields)
• Verbal or instant-message authorization from ECAB
• Post-implementation documentation within 24-48 hours
• Retrospective review at next scheduled CAB meeting

Change Request Workflow

A structured change request workflow ensures every change moves through the same stages regardless of type. Here is the seven-stage process that your IT change management template should support.

Stage 1: Request Submission

The change initiator completes a change request form. At minimum, capture these fields:

Required Fields:

• Change title and description
• Requester name and department
• Change type (standard/normal/emergency)
• Affected services and configuration items
• Business justification
• Proposed implementation date and window
• Estimated duration
• Risk assessment scores (see below)
• Rollback plan summary

Stage 2: Initial Assessment

The Change Manager reviews the submission for completeness and assigns a change type and priority. Incomplete requests are returned to the submitter.

Assessment Checklist:

• All required fields completed
• Change type correctly classified
• Affected CIs identified in the CMDB
• No scheduling conflicts with other changes
• Appropriate testing evidence provided

Stage 3: Risk Assessment

Every normal and emergency change undergoes a risk assessment using a standardized matrix. Rate each change on two dimensions:

Impact Score (1-5):

Likelihood of Failure (1-5):

Risk Score = Impact x Likelihood

For a deeper look at risk assessment practices in IT operations, read our IT Operations Excellence & ITIL Implementation Guide.

Stage 4: CAB Review

The Change Advisory Board reviews normal changes that score medium risk or above. The CAB does not approve or reject — it advises the change authority (typically the Change Manager or IT Director) who makes the final decision.

Stage 5: Authorization

The appropriate change authority approves or rejects the change based on CAB advice and risk assessment. Approved changes receive a scheduled implementation window.

Stage 6: Implementation

The implementation team executes the change according to the approved plan. Key requirements during implementation:

• Follow the documented implementation steps exactly
• Monitor affected services in real time
• Maintain a communication channel with the change coordinator
• Execute the rollback plan immediately if success criteria are not met within the defined window

Stage 7: Post-Implementation Review (PIR)

Every change — successful or not — receives a post-implementation review. Document:

• Was the change implemented as planned?
• Did the change achieve its stated objective?
• Were there any unexpected impacts?
• What lessons were learned?
• Should the process be updated for similar future changes?

Failed changes require a more detailed review that feeds into the problem management process.

Change Advisory Board (CAB) Structure

The CAB is the governance body that reviews proposed changes and advises the change authority. A well-structured CAB accelerates safe changes rather than creating a bureaucratic bottleneck.

CAB Composition

Standing Members (attend every meeting):

• Change Manager (chair)
• IT Operations lead
• Security representative
• Service Desk representative

Rotating Members (attend when their area is affected):

• Application owners
• Database administrators
• Network engineers
• Business stakeholders from affected departments
• Vendor representatives (for third-party changes)

Emergency CAB (ECAB)

The ECAB is a subset of the full CAB authorized to make rapid decisions for emergency changes. Define:

• Minimum quorum: 2-3 people (Change Manager + one technical lead)
• Availability: 24/7 on-call rotation
• Communication: Dedicated Slack/Teams channel and phone bridge
• Decision window: 15-30 minutes maximum
• Documentation: Verbal approval recorded, full paperwork within 48 hours

CAB Meeting Structure

Frequency: Weekly for most organizations. High-change-volume environments may need twice weekly.

Agenda Template:

1. Review of previous changes (5 min) — Status of changes implemented since last meeting
2. Failed change review (10 min) — Root cause and lessons learned from any failures
3. Normal change requests (30 min) — Review each pending change request
4. Emergency change retrospectives (10 min) — Review any emergency changes that bypassed normal CAB
5. Change calendar review (5 min) — Upcoming change windows, blackout periods, conflicts
6. Process improvements (5 min) — Any updates to the change management process itself

Meeting Duration: 60 minutes maximum. If the agenda cannot be covered, schedule a follow-up for overflow items rather than extending the meeting.

CAB Decision Framework

For each change, the CAB considers:

1. Technical merit — Is the implementation plan sound?
2. Risk assessment accuracy — Are the impact and likelihood scores reasonable?
3. Testing sufficiency — Has the change been adequately tested?
4. Rollback viability — Can the change be reversed if it fails?
5. Scheduling — Does the window avoid conflicts and blackout periods?
6. Communication — Are affected stakeholders informed?

Possible outcomes:

• Approved — Proceed as planned
• Approved with conditions — Proceed after specific modifications
• Deferred — Needs more information or testing
• Rejected — Risk is unacceptable or justification is insufficient

Rollback Planning

Every non-standard change must include a rollback plan. A rollback plan is not optional — it is a prerequisite for approval.

Rollback Plan Template

Required Elements:

1. Rollback trigger criteria — Define specific, measurable conditions that trigger a rollback (e.g., "Error rate exceeds 5% within 15 minutes of deployment")
2. Rollback decision authority — Who authorizes the rollback? (Change coordinator, on-call lead)
3. Rollback steps — Documented, tested procedure to reverse the change
4. Estimated rollback duration — How long will the reversal take?
5. Data considerations — Will any data created after the change be lost during rollback?
6. Communication plan — Who is notified during rollback and through which channels?
7. Verification steps — How do you confirm the rollback was successful?

Rollback Decision Matrix

Change Management KPIs

Track these metrics to measure the health of your change management process and identify areas for improvement.

Primary KPIs

Secondary KPIs

Review KPIs monthly. A high emergency change percentage indicates poor planning. A low change success rate suggests inadequate testing requirements. Long mean time to approve means the CAB process may be a bottleneck — consider increasing meeting frequency or delegating low-risk approvals.

For help setting up service desk workflows that complement your change management process, see our IT Service Desk Best Practices & Free Templates.

Implementing Change Management: Step by Step

Follow this phased approach to implement or improve your IT change management process. Rushing the implementation creates the same chaos the process is meant to prevent.

Phase 1: Foundation (Weeks 1-4)

Define the Process:

• Document the change management policy and scope
• Define change types and classification criteria
• Create the change request form template
• Establish the risk assessment matrix
• Define the approval authority matrix

Establish Governance:

• Appoint the Change Manager
• Define CAB membership and meeting schedule
• Create the ECAB roster and escalation procedure
• Set up the change calendar and blackout periods

Phase 2: Tooling and Catalog (Weeks 5-8)

Configure Your ITSM Tool:

• Set up the change request workflow in your ITSM platform
• Configure mandatory fields and validation rules
• Create approval routing based on risk scores
• Build the change calendar dashboard
• Set up notification templates for each workflow stage

Build the Standard Change Catalog:

• Identify the top 20-30 most frequent changes
• Document the procedure for each
• Assess and record the risk profile
• Submit to CAB for pre-authorization
• Add to the standard change catalog

Phase 3: Pilot, Training, and Rollout (Weeks 9-16)

• Select one or two teams to pilot the process for 4 weeks and collect feedback
• Train CAB members, change requesters, and implementation teams
• Extend the process to all IT teams and begin regular CAB meetings
• Track all KPIs from day one and review monthly
• Update the standard change catalog quarterly

For a comprehensive framework approach to change management, see our Change Management Framework & Templates Guide.

Common Change Management Pitfalls

• Treating the CAB as a rubber stamp — If the CAB approves everything without review, it provides no value. Ensure members receive details in advance and are empowered to defer changes.
• Overloading the normal change process — When every change requires full CAB review, the process becomes a bottleneck. Build a comprehensive standard change catalog to free the CAB for genuinely risky changes.
• Skipping post-implementation reviews — PIRs feel unnecessary when changes succeed, but skipping them means you miss near-misses and improvement opportunities.
• Emergency change abuse — If more than 10-15% of changes are emergency, the classification system is broken. Review whether the normal process is too slow.
• Neglecting the change calendar — Conflicting changes deployed simultaneously are a leading cause of outages. All approved changes must appear on the calendar.
• No integration with incident management — Changes that cause incidents should automatically trigger a review to prevent repeat failures.

For more on building effective IT operations processes, visit our IT Operations resource hub and explore the full IT Management Templates collection.

Integrating Change Management with DevOps

Traditional change management and DevOps are not enemies. The goal is to automate the controls, not eliminate them.

Strategies for Integration:

• Automate standard changes — If a change follows a tested CI/CD pipeline with automated rollback, classify it as standard
• Use deployment pipelines as evidence — Automated test results, code review approvals, and deployment logs serve as change documentation
• Risk-based gating — Only high-risk changes require manual CAB review. Low-risk deployments flow through automated approval
• Change records from pipeline metadata — Generate change records automatically from deployment pipeline data rather than requiring manual form completion

For a deeper dive into managing change processes across IT teams, see our Change Management Process for IT Teams guide.

Next Steps

1. Assess your current state — Use the maturity model above to identify your starting point
2. Download the templates — Get the Change Management Log Template and Change Management Plan Template to structure your process
3. Define your change types — Classify your most common changes into standard, normal, and emergency
4. Stand up the CAB — Appoint members, set the meeting cadence, and distribute the first agenda
5. Start measuring — Track the four primary KPIs from day one so you have baseline data
6. Iterate — Use PIR findings and KPI trends to continuously improve the process

Visit our IT Management Hub for more templates, guides, and best practices for running efficient IT operations.