Why Change Management Is Critical
The majority of service incidents are change-related. A misconfigured firewall rule, a database migration that fails, an application deployment with unintended side effects—these represent the failure mode of poor change management. Disciplined change management prevents unauthorized changes, reduces change-related outages, and creates the audit trail needed to diagnose incidents when they occur. ISO 20000 Clause 5.5 requires change management control; auditors verify this by sampling change records and cross-referencing them with infrastructure logs, CMDB audit trails, and incident records.
Change Types and Authorization Models
Standard changes are pre-authorized, documented, low-risk, and repeatable: examples include scheduled patching, standard account provisioning, routine firewall rule updates. Standard changes do not require per-instance CAB approval; instead, the process owner pre-authorizes the change type, and staff execute according to procedure. Every standard change must still be recorded in the change register, with execution date and outcome documented. Normal changes require assessment and approval before implementation; they go through the full CAB cycle. Risk assessment (likelihood, impact, risk score) is completed; implementation plan with step-by-step procedure is documented; rollback plan is prepared. The CAB reviews, discusses risks, and approves or defers. Emergency changes can be approved and executed immediately when a risk to the business requires action that cannot wait for the normal CAB cycle (service is down and repair is urgent); post-implementation, the emergency change is presented to CAB for retrospective review. The risk of emergency change overuse—when emergency changes exceed 5% of all changes—signals process bypass and lack of control.
Change Record Content
Every change record must contain: change ID (unique identifier), requester and change owner, clear description of what is being changed and why, affected CIs and services (queried from CMDB), risk assessment with likelihood, impact, and risk score, implementation plan with step-by-step procedure, rollback plan (what to do if change fails), test plan and test results (showing the change was tested before production implementation), scheduled implementation window and actual implementation window, approval history with names of CAB members, their decision, and decision date, implementation outcome, and post-implementation review. The change record serves as the audit trail; auditors will examine change records to verify that decisions were informed by risk data, that testing was documented, and that rollback plans were in place.
| KEY CONCEPT | The CAB is a governance body, not a bureaucratic bottleneck. A well-run CAB makes quick, informed decisions based on risk evidence. The goal is appropriate control, not maximum restriction. |
The Change Advisory Board: Composition and Authority
The CAB includes: service management lead (chair, who ensures decisions align with SMS objectives), technical architects (who understand service dependencies and risks), key service owners (who understand business criticality), customer representative (for business-impacting changes), security representative (who assesses security implications), and release manager (who coordinates change with deployment). CAB meets weekly or fortnightly; agenda is circulated in advance with change submissions. CAB authority levels are defined: the chair can approve low-risk normal changes; high-risk changes require consensus or escalation to a steering committee. CAB minutes are required documented evidence—not just an approval rubber stamp, but a record of discussion, identified risks, and decisions.
The Forward Schedule of Change
The FSC is the approved change calendar showing all planned implementation windows. It is used to identify change conflicts (two critical changes on the same night increase risk), change freeze periods (e.g., no non-emergency changes during month-end), and business blackout dates (e.g., quarterly earnings release, critical compliance deadline). The FSC is shared with all teams and customers; this transparency prevents surprise changes and allows teams to prepare for likely impacts.
Post-Implementation Review
The PIR is conducted 24–72 hours after implementation. Questions: Did the change achieve its objective? Were there unintended impacts (new errors, performance degradation)? Was the CMDB updated with new configuration details? What went well? What would we do differently next time? PIR completion is a change record closure prerequisite; a change cannot be marked closed without a documented PIR. PIR findings inform continuous improvement (if a certain type of change repeatedly has post-implementation issues, the standard procedure needs revision).
| IMPORTANT | Changes implemented without CAB approval (unauthorized changes) are a major nonconformity. Auditors sample change records and cross-reference them with CMDB change logs and incident records to identify undocumented changes. |
Change Management Metrics
Metrics to track: change success rate (percentage of changes that achieved their objective with no rollback), emergency change rate (should be <5%), change-related incident rate (percentage of incidents with a change in the 24 hours preceding the incident), change cycle time (elapsed time from submission to approval and implementation), overdue change rate (changes that missed their scheduled implementation window). These metrics are reported monthly; sustained poor performance on any metric should trigger review and remediation planning.
Integrations with Other Practices
Change management is tightly integrated with the CMDB: affected CIs must be identified from the CMDB; CMDB relationships guide impact assessment; after change implementation, the CMDB must be updated to reflect any changes to CI attributes or relationships. Integration with release management ensures that changes are bundled into releases (coordinated deployments rather than ad-hoc changes). Integration with problem management means that permanent fixes are implemented as changes linked to problem records, creating full traceability from problem to fix to change record to closure.
| BITLION INSIGHT | Bitlion GRC change management workflow automates CAB meeting scheduling, integrates with the CMDB for impact assessment, provides templates for change records, and visualizes the Forward Schedule of Change with conflict detection. |