Change Management Flowchart: ITIL-Based Change Control Process

Every IT outage investigation eventually asks the same question: "What changed?" Effective change management provides the answer before the question needs asking. A change management flowchart documents how modifications move from request through approval to implementation, ensuring visibility into what's changing, why, and who approved it.

This guide covers how to create a change management flowchart based on ITIL best practices that balances control with velocity.

Why change management needs a flowchart

IT changes are inevitable—patches, deployments, configuration updates, infrastructure modifications. A flowchart provides:

Visibility. When changes are documented and approved through a visible process, there are no surprises. Everyone knows what's happening and when, reducing "what changed?" investigations.

Risk reduction. A structured process forces risk assessment before implementation. Changes that could cause outages get appropriate review instead of sailing through unchecked.

Accountability. Approvals create a record of who authorized what. When changes cause problems, the trail shows whether process was followed and where decisions were made.

Compliance support. Many regulatory frameworks require change management evidence. A documented flowchart and its execution records demonstrate control over the environment.

Understanding change types

Not all changes need the same level of oversight. ITIL defines three categories:

Standard changes

Pre-approved, low-risk changes following established procedures:

• Routine patches with known impact
• Password resets
• Adding users to groups
• Certificate renewals
• Scheduled maintenance activities

Characteristics:

• Low risk and well-understood
• Procedure is documented
• Pre-authorized (no individual approval needed)
• Often automated

Change requested → Is this a standard change?
                   ↓ Yes → Follow documented procedure → Implement → Log completion
                   ↓ No → Proceed to normal change process

Normal changes

Changes requiring assessment and approval before implementation:

• Application deployments
• Configuration changes
• Infrastructure modifications
• New system implementations
• Significant updates or upgrades

Characteristics:

• Risk varies (low to high)
• Requires individual assessment
• Needs appropriate approval level
• Scheduled for implementation window

Emergency changes

Changes needed urgently to restore service or prevent imminent failure:

• Security patches for active vulnerabilities
• Fixes for production outages
• Critical bug patches
• Emergency configuration changes

Characteristics:

• Urgent timeline
• Expedited approval process
• Higher risk tolerance (often)
• Retroactive documentation acceptable

Urgent issue identified → Emergency change required?
                          ↓ Yes → Emergency approval → Implement immediately → Document after
                          ↓ No → Normal change process with urgency flag

Core elements of a change management flowchart

Change request initiation

Every change starts with a request:

Request information:

• Change description and justification
• Business reason and benefits
• Systems and services affected
• Proposed implementation approach
• Requestor and stakeholders

Initial categorization:

• Change type (standard/normal/emergency)
• Urgency level
• Impact scope (users, systems, services)
• Initial risk estimate

Change need identified → Submit change request
                        → Request complete?
                          ↓ Yes → Proceed to assessment
                          ↓ No → Return for additional information

Risk and impact assessment

Understanding what could go wrong and who's affected:

Risk factors:

• Technical complexity
• Past experience with similar changes
• Systems affected (criticality)
• Dependencies and integration points
• Rollback complexity

Impact analysis:

• Users affected (number, criticality)
• Services affected (availability impact)
• Business processes impacted
• Compliance implications

Risk scoring:

Assess risk factors → Calculate risk score (Low/Medium/High)
                     → High risk → Additional review required
                     → Medium risk → Standard approval path
                     → Low risk → Expedited approval possible

Implementation planning

How the change will be executed:

Implementation details:

• Step-by-step procedure
• Required resources and access
• Timeline and maintenance window
• Team members involved

Testing plan:

• Pre-implementation testing completed
• Validation steps post-implementation
• Success criteria defined
• User acceptance requirements

Backout plan:

• Rollback procedure documented
• Rollback trigger criteria
• Rollback timeline estimate
• Data preservation approach

Communication plan:

• Stakeholders to notify
• Timing of notifications
• Status update schedule
• Escalation contacts

Approval workflow

Getting authorization to proceed:

Approval levels:

• Low-risk changes: Team lead or technical manager
• Medium-risk changes: Change manager or department head
• High-risk changes: Change Advisory Board (CAB)
• Emergency changes: Emergency CAB or on-call authority

CAB process:

• Change request reviewed
• Questions addressed
• Risk assessment validated
• Implementation plan evaluated
• Approval, rejection, or defer decision

Change ready for approval → Determine approval level
                            ↓ Team-level → Manager approval
                            ↓ CAB required → Schedule for CAB review
                              → CAB decision
                                ↓ Approved → Schedule implementation
                                ↓ Rejected → Return with feedback
                                ↓ Deferred → Reschedule for future review

Scheduling and coordination

Timing the change appropriately:

Window selection:

• Approved maintenance windows
• Low-traffic periods
• Avoid blackout dates
• Coordinate with related changes

Resource coordination:

• Team availability confirmed
• Dependencies sequenced
• Communication scheduled
• Monitoring prepared

Conflict checking:

• Other changes in same window
• System dependencies
• Freeze periods
• Business events

Implementation execution

Performing the change:

Pre-implementation:

• Final go/no-go check
• Team assembled
• Systems accessible
• Stakeholders notified

Implementation steps:

• Follow documented procedure
• Log actions taken
• Monitor for issues
• Validate at checkpoints

Post-implementation verification:

• Success criteria checked
• Service restored/functional
• Users can access
• No unexpected impacts

Implementation window opens → Pre-checks pass?
                               ↓ Yes → Execute change steps → Verify success
                                       ↓ Success → Notify completion
                                       ↓ Issues → Troubleshoot or rollback
                               ↓ No → Postpone and reschedule

Rollback decision

When changes don't go as planned:

Rollback triggers:

• Success criteria not met
• Service degradation detected
• Unexpected errors occurring
• Timeline exceeded

Rollback execution:

• Follow backout procedure
• Validate service restoration
• Document what happened
• Notify stakeholders

Issues detected → Severity assessment
                  ↓ Minor → Continue with workaround
                  ↓ Major → Can be fixed in window? → Fix and verify
                  ↓ Critical → Initiate rollback → Verify restoration

Post-implementation review

Learning from changes:

Review elements:

• Was the change successful?
• Were there issues? What caused them?
• Was the process followed?
• Were estimates accurate?
• What should be improved?

Documentation:

• Actual versus planned comparison
• Issues and resolutions
• Lessons learned
• Knowledge base updates

Closure:

• Change record updated
• Metrics captured
• Ticket closed
• Stakeholders informed

Building your change management flowchart

Align with your risk tolerance

Different organizations have different needs:

High-control environments:

• More approval levels
• Longer lead times
• Comprehensive documentation
• Stricter change windows

Agile environments:

• Streamlined approvals
• Shorter lead times
• Lighter documentation
• Flexible timing

The flowchart should match your organization's risk appetite and operational needs.

Define clear criteria

Ambiguous criteria slow the process:

Change classification:

• What qualifies as standard vs. normal vs. emergency?
• How is risk scored?
• What determines approval level?

Success criteria:

• What does "successful" mean for this change?
• How is success verified?
• Who confirms completion?

Rollback triggers:

• When do we decide to roll back?
• Who makes that call?
• How long do we try before giving up?

Include specific criteria in the flowchart or linked documentation.

Map to your ITSM tool

The flowchart should reflect your tooling:

Ticket workflow:

• States match flowchart stages
• Transitions require flowchart criteria
• Approvals documented in system
• Audit trail maintained

Automation opportunities:

• Standard changes auto-approved
• Risk scoring calculated
• Calendar conflicts detected
• Notifications automated

Reporting alignment:

• Metrics match flowchart stages
• Approval times tracked
• Success rates measured
• Rollback frequency captured

Handle exceptions

Real operations require flexibility:

Expedited approvals:

• When can normal process be shortened?
• Who can authorize expedited changes?
• What documentation is still required?

After-hours changes:

• Who approves outside business hours?
• How is documentation handled?
• What's the escalation path?

Failed changes:

• How are failed changes handled?
• What review is required?
• How do they re-enter the process?

Common change management patterns

CAB-centric model

Change request → Assessment → CAB review
                               ↓ Approved → Implementation → PIR → Close
                               ↓ Rejected → Return to requestor

Weekly CAB reviews all normal changes. Works for organizations with predictable change volumes.

Delegated approval model

Change request → Assessment → Risk-based routing
                               ↓ Low risk → Peer review → Implement
                               ↓ Medium risk → Manager approval → Implement
                               ↓ High risk → CAB → Implement

Approval authority distributed based on risk. Enables faster flow for lower-risk changes.

Continuous delivery model

Code merged → Automated tests → Automated security scan
                                ↓ Pass → Auto-deploy to staging
                                ↓ Pass → Auto-deploy to production
                                ↓ Fail → Block and notify

Automated pipelines handle low-risk code changes. Manual approval reserved for infrastructure and high-risk changes.

Integrating with related processes

Change management connects to other ITIL processes:

Incident management:

• Incidents trigger emergency changes
• Change-related incidents link back
• Post-incident changes follow process

Problem management:

• Problem fixes become changes
• Root cause drives change requirements
• Known error workarounds become standard changes

Release management:

• Releases contain multiple changes
• Release calendar drives change windows
• Change coordination within releases

Configuration management:

• Changes update CMDB
• CI relationships inform impact
• Baseline tracking validates changes

Measuring change management

The flowchart enables performance measurement:

Volume metrics:

• Changes by type and category
• Changes by approval level
• Changes by team/system

Time metrics:

• Request to approval time
• Approval to implementation time
• Total change cycle time

Quality metrics:

• Change success rate
• Rollback frequency
• Change-related incidents
• Emergency change percentage

Track these to identify process improvements.

Common change management problems

Process too slow: Lead times frustrate teams. Solution: streamline low-risk paths, enable delegation, reduce approval bottlenecks.

Changes bypass process: Teams work around change management. Solution: understand why (usually speed), address root cause, make compliance easier.

High failure rates: Too many changes cause incidents. Solution: improve risk assessment, better testing requirements, more thorough backout planning.

CAB bottleneck: Everything waits for weekly CAB. Solution: enable delegation, add CAB sessions, pre-approve more standard changes.

The flowchart helps identify where process friction occurs.

Creating your change management flowchart with Flowova

Change management processes often exist in policy documents, ITSM tool configurations, and institutional knowledge. Converting this to a clear flowchart manually takes time. An AI flowchart generator like Flowova can help:

1. Gather existing materials: Collect your change policy, approval matrices, ITSM workflows, and CAB procedures.

2. Describe the flow: Input a description covering request initiation, assessment, approval levels, implementation, and review stages.

3. Generate and refine: The AI produces an initial flowchart. Review against your actual process, add your specific approval criteria and escalation paths.

4. Export for use: PNG for policy documentation and training materials, Mermaid for IT governance wikis.

The goal is a flowchart that change submitters can follow, approvers can reference, and auditors can verify. When change management is visible and consistent, fewer changes cause incidents and the organization maintains control while enabling progress.

Related resources

Build better IT governance processes with these templates:

• Project Approval Process Template – Manage approval workflows
• Incident Response Workflow Template – Handle incidents
• CI/CD Pipeline Workflow Template – Automate deployments
• Browse all templates – Explore our full library of flowchart templates