Change Management

Change management controls modifications to IT services, infrastructure, and configuration items through structured assessment, approval, and implementation procedures. This task covers the complete change lifecycle from initial request through post-implementation verification, applicable whenever you modify production systems, alter service configurations, or deploy new capabilities.

Change

The addition, modification, or removal of anything that could have a direct or indirect effect on services. This includes hardware, software, configuration, documentation, and processes.

Change Advisory Board (CAB)

A group that assesses, prioritises, and authorises changes. Composition varies by change scope and risk.

Request for Change (RFC)

A formal proposal containing details required to assess and approve a change.

Configuration Item (CI)

Any component that needs to be managed to deliver an IT service. Changes modify one or more CIs.

Change Schedule

A calendar showing planned changes and their implementation windows, used to coordinate activities and avoid conflicts.

Prerequisites

Before submitting or processing changes, verify these requirements are met.

Access and authority requirements depend on your role. Change requesters need access to the change management system and authority to request changes for their service area. Change assessors need read access to the configuration management database (CMDB) and service catalogue. CAB members need calendar access for scheduling and authority to approve changes within their scope. Change implementers need administrative access to affected systems and documented rollback procedures.

System requirements include an operational change management system with RFC submission capability, a CMDB populated with CIs for affected services, and a shared calendar for the change schedule. If your organisation lacks a dedicated change management tool, a structured request form with manual tracking through a shared spreadsheet provides minimum viable capability.

Information you need before starting includes the business justification for the change, the configuration items affected (from the CMDB), the implementation plan with specific steps, the rollback plan if implementation fails, the testing evidence or test plan, and the communication plan for stakeholders. Gather this information before submitting the RFC to avoid delays during assessment.

Change categorisation

Changes fall into three categories that determine their approval path and documentation requirements. Correct categorisation at submission prevents delays and ensures appropriate oversight.

Standard changes are pre-authorised, low-risk changes with established procedures. They follow a documented process without requiring individual CAB assessment. Examples include password resets, standard software installations from an approved list, user account creation following standard templates, and scheduled backup configuration updates. Standard changes require a catalogue entry that defines the scope, procedure, and conditions. The catalogue entry itself requires initial CAB approval, after which individual instances proceed without further authorisation. Organisations with mature change management maintain 40-60 standard change models covering routine operations.

Normal changes require individual assessment and authorisation through the CAB process. They carry moderate risk, require coordination across teams, or fall outside standard change definitions. Most changes in organisations fall into this category. Normal changes follow the full RFC lifecycle: submission, assessment, CAB review, scheduling, implementation, and closure. Implementation windows are scheduled to minimise service impact, with most organisations designating specific maintenance windows.

Emergency changes address incidents causing or threatening significant service disruption where the standard process would cause unacceptable delay. Emergency changes bypass normal CAB scheduling but still require authorisation from a designated authority and retrospective CAB review. The emergency change authority is typically a senior technical manager or on-call manager with decision-making authority. Emergency changes carry higher risk because reduced assessment time increases the probability of unintended consequences. Organisations track emergency change rates as a quality indicator; rates above 10% of total changes suggest either inadequate standard change catalogues or insufficient forward planning.

+------------------------------------------------------------------+
|                    CHANGE CATEGORISATION                         |
+------------------------------------------------------------------+
                              |
                              v
                 +------------+------------+
                 | Does documented         |
                 | standard change         |
                 | model exist?            |
                 +------------+------------+
                              |
              +---------------+---------------+
              |                               |
              | Yes                           | No
              v                               v
    +---------+---------+          +----------+----------+
    | STANDARD CHANGE   |          | Is there imminent   |
    | Follow catalogue  |          | or actual service   |
    | procedure         |          | disruption?         |
    +-------------------+          +----------+----------+
                                              |
                            +-----------------+-----------------+
                            |                                   |
                            | Yes                               | No
                            v                                   v
                  +---------+---------+              +----------+----------+
                  | EMERGENCY CHANGE  |              | NORMAL CHANGE       |
                  | Emergency CAB     |              | Full CAB process    |
                  | approval required |              | required            |
                  +-------------------+              +---------------------+

Figure 1: Change categorisation decision flow

Procedure

Submitting a change request

1. Open the change management system and select “New Request for Change”. If using a manual system, obtain the current RFC template from the service desk.

2. Complete the identification section with your name, contact details, department, and the date. Assign a unique reference number following your organisation’s numbering convention. A typical format is CHG-YYYY-NNNN where YYYY is the year and NNNN is a sequential number.

3. Describe the change in the summary field using specific language that identifies the action and target. Write “Upgrade PostgreSQL from 13.4 to 15.2 on grants-db-prod-01” rather than “Database upgrade”. The summary appears on the change schedule and in notifications, so precision prevents confusion.

4. Document the business justification explaining why this change is necessary. Link to the business requirement, incident, problem, or project that initiated the change. Quantify benefits where possible: “Resolves PRB-2024-0089 affecting 120 users with 4-hour monthly downtime” provides stronger justification than “Improves stability”.

5. List all configuration items affected by the change. Query the CMDB for the primary CI and its dependencies. For a database upgrade, affected CIs include the database server, all applications connecting to it, backup jobs targeting it, and monitoring configurations. Missing CIs cause unexpected failures during implementation.

6. Specify the implementation plan with numbered steps, responsible parties, and estimated duration for each step. Include pre-implementation checks, the implementation actions, and post-implementation validation. A database upgrade implementation plan contains 15-25 discrete steps.

7. Document the rollback plan with specific steps to reverse the change if implementation fails. The rollback plan must be executable within your maintenance window. For the database upgrade example, rollback involves restoring from the pre-upgrade backup, reverting connection strings, and validating application connectivity. Test rollback procedures in non-production environments before submitting the RFC.

8. Complete the risk assessment section. Evaluate likelihood of failure (1-5 scale) and impact if the change fails (1-5 scale). Multiply these values to produce a risk score. Document mitigating controls that reduce either likelihood or impact.

9. Define success criteria that objectively determine whether the change succeeded. “Database responds to queries within 50ms” is verifiable; “Database works correctly” is not. Include specific tests to perform after implementation.

10. Identify stakeholders requiring communication before, during, or after the change. Include service owners, affected user groups, dependent service teams, and management if the change carries significant risk.

11. Submit the RFC. The system assigns it to the change coordinator for initial review. Expect acknowledgement within one business day.

Assessing a change request

1. Receive the RFC from the submission queue. Verify the request is complete by checking that all mandatory fields contain substantive content. Return incomplete RFCs to the requester with specific feedback on what information is missing.

2. Validate CI information against the CMDB. Confirm listed CIs exist, are correctly identified, and that the dependency analysis is complete. Use CMDB relationship queries to identify upstream and downstream CIs not listed in the RFC. A common gap is omitting monitoring configurations that require updates when infrastructure changes.

3. Review the implementation plan for completeness and accuracy. Verify that steps are in logical order, time estimates are realistic based on historical data for similar changes, and required resources (staff, systems, access) are identified. Flag implementation plans that lack specificity or contain steps like “configure as needed”.

4. Evaluate the rollback plan. Confirm rollback is technically feasible within the maintenance window. If the change involves database schema modifications or data transformations, verify that rollback preserves data integrity. Rollback plans requiring more than 50% of the maintenance window indicate excessive risk.

5. Assess risk using your organisation’s risk matrix. The standard approach multiplies likelihood (1-5) by impact (1-5) to produce a risk score from 1-25.

6. Check the change schedule for conflicts. Query for other changes affecting the same CIs, same maintenance window, or dependent services. Two changes modifying the same CI in the same window require sequencing or separation. Changes to dependent services during the same window complicate troubleshooting if issues arise.

7. Assign the RFC to the appropriate CAB based on risk level, affected services, and technical domain. Organisations with multiple CABs (infrastructure, applications, security) route changes based on primary impact area.

8. Document your assessment findings in the RFC record, including any concerns, conditions, or questions for the CAB to address.

Conducting CAB review

1. Publish the CAB agenda 48 hours before the meeting. Include all RFCs scheduled for review with links to full documentation. CAB members who cannot review changes in advance should not approve them.

2. Open the CAB meeting by confirming attendance and quorum. Minimum quorum includes representation from operations, the affected service area, and security for changes with security implications.

3. Review each RFC in sequence. For each change, the requester or change coordinator presents the summary, justification, risk assessment, and implementation plan. Limit presentations to 5 minutes for low-risk changes and 15 minutes for high-risk changes.

4. CAB members ask clarifying questions and raise concerns. Common areas of inquiry include rollback feasibility, testing adequacy, stakeholder communication, and resource availability. Document all questions and responses in the meeting record.

5. Vote on each RFC. Outcomes include: approved as submitted, approved with conditions, deferred pending additional information, or rejected. Approved with conditions requires the requester to satisfy specified conditions before implementation; the change coordinator verifies condition satisfaction. Deferred changes return to a future CAB with requested information. Rejected changes require documented rationale.

6. For approved changes, confirm the scheduled implementation window. Verify no conflicts emerged since initial assessment. Record the approved window in the change schedule.

7. Review emergency changes implemented since the last CAB meeting. Assess whether emergency classification was appropriate and whether the change followed emergency procedures. High rates of emergency changes warrant process improvement discussion.

8. Publish CAB meeting minutes within 24 hours, including all decisions, conditions, and action items.

+------------------------------------------------------------------+
|                      CAB REVIEW PROCESS                          |
+------------------------------------------------------------------+
|                                                                  |
|    +-------------+     +-------------+     +-------------+       |
|    | Publish     |     | Present     |     | CAB         |       |
|    | agenda      +---->| RFC         +---->| questions   |       |
|    | (48 hrs)    |     |             |     | & concerns  |       |
|    +-------------+     +-------------+     +------+------+       |
|                                                   |              |
|                                                   v              |
|    +-------------+     +-------------+     +------+------+       |
|    | Update      |     | Record      |     | Vote on     |       |
|    | change      |<----+ decision    |<----+ RFC         |       |
|    | schedule    |     |             |     |             |       |
|    +-------------+     +-------------+     +-------------+       |
|          |                                                       |
|          v                                                       |
|    +-----+-------+                                               |
|    | Notify      |          DECISION OUTCOMES                    |
|    | requester   |          +---------------------------+        |
|    +-------------+          | - Approved                |        |
|                             | - Approved with conditions|        |
|                             | - Deferred                |        |
|                             | - Rejected                |        |
|                             +---------------------------+        |
+------------------------------------------------------------------+

Figure 2: CAB review workflow

Implementing an approved change

1. Confirm all pre-implementation conditions are satisfied. Verify CAB conditions are met if the change was approved conditionally. Confirm implementation resources are available and the maintenance window is still valid.

2. Send pre-implementation communications to stakeholders per the communication plan. For changes affecting users, send notification 24-48 hours before the maintenance window. Include the expected duration, services affected, and contact information for questions.

3. Create a checkpoint before beginning implementation. For infrastructure changes, this means verified backups, configuration exports, or snapshots depending on the technology. Document the checkpoint with timestamps and verification results.

4. Execute the implementation plan step by step. Record the actual start time, completion time, and outcome for each step. Deviations from the plan require documentation. If you encounter a step that cannot be completed as documented, assess whether to proceed with modification, pause for consultation, or initiate rollback.

5. Perform post-implementation validation tests defined in the RFC. Compare results against success criteria. Document test results with specific values, not just pass/fail. “Response time 42ms against 50ms threshold: PASS” provides useful data for future changes.

6. If validation fails, evaluate whether defects can be corrected within the maintenance window. Minor issues may be addressable; significant failures require rollback decision. The implementation lead makes the rollback decision based on remaining window time, defect severity, and rollback plan readiness.

7. If rollback is required, execute the rollback plan. Record rollback start time and each step’s completion. After rollback, perform validation to confirm services are restored to pre-change state.

8. Send post-implementation communication confirming completion status. For successful changes, confirm service restoration and any user actions required. For failed changes, communicate service status, impact, and next steps.

9. Update the RFC record with implementation outcome, actual duration, test results, and any issues encountered.

Closing a change

1. Verify implementation is complete and validated. All post-implementation tests must show passing results against defined success criteria.

2. Confirm no related incidents opened during or immediately following implementation. A 24-72 hour stabilisation period before closure allows latent issues to surface.

3. Update the CMDB to reflect the new configuration state. For the database upgrade example, update the version attribute on the database CI from 13.4 to 15.2. CMDB accuracy depends on consistent post-change updates.

4. Archive implementation evidence including test results, communication records, and any deviation documentation. This evidence supports audits and provides reference data for future similar changes.

5. Set the RFC status to closed. Include a closure summary noting whether the change achieved its objectives and any lessons learned.

6. For changes that caused issues or required rollback, create a problem record to investigate root cause and prevent recurrence. Link the problem record to the RFC for traceability.

Emergency change procedure

Emergency changes follow a compressed process when standard timelines would cause unacceptable service impact. Invoke the emergency change procedure only when delaying the change causes greater harm than reduced assessment.

1. Contact the emergency change authority. This is the designated manager authorised to approve changes outside normal CAB process. Provide verbal briefing on the situation, proposed change, and risks.

2. Submit an abbreviated RFC capturing essential information: what you will change, why it cannot wait, what the risks are, and how you will roll back. Complete documentation follows after implementation.

3. Obtain verbal approval from the emergency change authority. Record the approver name, time, and any conditions imposed.

4. Implement the change following the same implementation discipline as normal changes. Document steps, create checkpoints, and validate results. The compressed approval timeline does not reduce implementation quality requirements.

5. Complete the full RFC documentation within 24 hours of implementation. Include all fields that would have been completed for a normal change.

6. Present the emergency change at the next CAB for retrospective review. CAB assesses whether emergency classification was appropriate and whether the change followed proper emergency procedures. Patterns of inappropriate emergency classification indicate process problems requiring correction.

+------------------------------------------------------------------+
|                   EMERGENCY CHANGE FLOW                          |
+------------------------------------------------------------------+
|                                                                  |
|  +-------------+     +----------------+     +---------------+    |
|  | Incident or |     | Contact        |     | Submit        |    |
|  | imminent    +---->| emergency      +---->| abbreviated   |    |
|  | disruption  |     | change         |     | RFC           |    |
|  +-------------+     | authority      |     +-------+-------+    |
|                      +----------------+             |            |
|                                                     v            |
|  +-------------+     +----------------+     +-------+-------+    |
|  | Present at  |     | Complete full  |     | Obtain verbal |    |
|  | next CAB    |<----+ documentation  |<----+ approval      |    |
|  | (retro)     |     | (24 hrs)       |     |               |    |
|  +------+------+     +----------------+     +-------+-------+    |
|         |                                           |            |
|         v                                           v            |
|  +------+------+                            +-------+-------+    |
|  | Document    |                            | Implement     |    |
|  | lessons     |                            | with full     |    |
|  | learned     |                            | documentation |    |
|  +-------------+                            +---------------+    |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Emergency change procedure flow

Risk assessment framework

Risk assessment quantifies the probability and potential impact of change failure to inform approval decisions and implementation planning. The assessment produces a risk score that determines approval authority and may trigger additional controls.

Calculate risk score by multiplying likelihood and impact ratings. Each dimension uses a 1-5 scale with defined criteria.

Likelihood rating reflects the probability that the change will cause unplanned service disruption.

A rating of 1 indicates very low likelihood. The change uses a proven procedure executed many times without failure, affects a single low-complexity component, and includes comprehensive testing in an environment matching production. Automated deployments with extensive test coverage typically score 1.

A rating of 2 indicates low likelihood. The change follows a documented procedure with occasional historical issues, affects multiple components with well-understood relationships, and includes testing that covers primary scenarios. Most well-planned infrastructure changes score 2.

A rating of 3 indicates moderate likelihood. The change involves some novel elements or components with moderate complexity, dependencies exist that complicate rollback, or testing could not fully replicate production conditions. First-time implementation of a new pattern scores at least 3.

A rating of 4 indicates high likelihood. The change affects complex interdependent systems, has limited rollback options, or historical similar changes show elevated failure rates. Major version upgrades with schema changes typically score 4.

A rating of 5 indicates very high likelihood. The change involves untested procedures, affects poorly documented systems, or has no viable rollback path. Changes scoring 5 on likelihood require re-evaluation of whether to proceed.

Impact rating reflects the consequence of change failure across service availability, data integrity, and organisational operations.

A rating of 1 indicates minimal impact. Failure affects a single non-critical service with workarounds available, fewer than 10 users impacted, and no data risk.

A rating of 2 indicates minor impact. Failure affects a single service used by 10-50 users, workarounds exist but reduce productivity, and no data integrity risk.

A rating of 3 indicates moderate impact. Failure affects multiple services or 50-200 users, significant productivity impact, potential for data issues requiring correction.

A rating of 4 indicates major impact. Failure affects critical services supporting core operations, 200-1000 users impacted, potential data loss or integrity issues, or financial impact exceeding £10,000.

A rating of 5 indicates severe impact. Failure affects life-safety systems, causes data loss affecting regulatory compliance, impacts over 1000 users, or causes financial impact exceeding £100,000.

Sample risk calculation: A database version upgrade affects the grants management system used by 150 staff. The upgrade follows a documented procedure but involves schema migrations. Testing in staging showed one issue requiring workaround. Historical upgrades show 85% success rate.

Likelihood: Novel schema migration with imperfect testing history rates 3. Impact: 150 users on a business-critical system with potential data issues rates 3. Risk score: 3 × 3 = 9 (medium risk, CAB approval required).

Scheduling and conflict management

The change schedule coordinates implementation timing to prevent conflicts and ensure adequate support resources. Effective scheduling balances implementation velocity against risk concentration.

Maintenance windows define pre-approved periods for change implementation. Most organisations establish weekly maintenance windows: a primary window (e.g., Sunday 02:00-06:00) for high-risk changes requiring extended time, and secondary windows (e.g., Wednesday 22:00-24:00) for lower-risk changes. Maintenance windows account for user impact, support staff availability, and system load patterns.

Change blackout periods prohibit non-emergency changes during high-risk organisational periods. Common blackouts include financial year-end processing (final 5 business days of fiscal year), major organisational events, and external audit periods. Document blackout periods in the change schedule with rationale and authority.

Conflict detection identifies changes that cannot safely proceed in the same window. Query the change schedule for conflicts when scheduling each RFC.

Direct conflicts occur when multiple changes modify the same CI. Two changes updating firewall rules cannot proceed simultaneously because the second change would overwrite the first.

Dependency conflicts occur when changes affect CIs with defined relationships. A change to the authentication service conflicts with changes to applications depending on that service because a authentication failure during the application change window complicates troubleshooting.

Resource conflicts occur when changes require the same implementation staff or specialised access. If your database administrator is implementing a database upgrade, they cannot simultaneously implement a data warehouse change.

Resolve conflicts by resequencing changes within the same window (if time permits), moving one change to a different window, or combining related changes into a coordinated release.

Verification

After processing a change, verify correct completion through these checks.

For submitted changes, confirm the RFC appears in the change management system with status “Submitted” and an assigned reference number. Verify all mandatory fields contain complete information. Check that the requester received acknowledgement.

For assessed changes, confirm the RFC record contains assessment notes, risk score calculation, and CAB assignment. Verify the change schedule shows the proposed implementation window.

For CAB-reviewed changes, confirm the RFC record contains CAB decision, any conditions, and the approved implementation window. Verify CAB meeting minutes reflect the decision.

For implemented changes, confirm all success criteria tests show passing results. Verify the CMDB reflects the new configuration state. Query for incidents opened against affected CIs in the 72 hours following implementation; zero related incidents indicates successful implementation.

Expected system states after change completion: RFC status shows “Closed”, CMDB CIs show updated attributes matching the change, change schedule shows the completed change with actual dates, and no open incidents are linked to the change.

Troubleshooting

Change request form template

Use this template structure for RFC submissions. Adapt field labels to your change management system.

CHANGE REQUEST FORM

Section 1: Identification

RFC Number: [Auto-assigned or CHG-YYYY-NNNN] Requester Name: [Full name] Department: [Organisational unit] Contact Email: [Email address] Contact Phone: [Phone number] Date Submitted: [YYYY-MM-DD]

Section 2: Change Description

Summary: [Single sentence describing what will change, max 100 characters]

Detailed Description: [Full description of the change, what will be modified, added, or removed]

Business Justification: [Why this change is necessary, link to initiating requirement, incident, or project]

Related Records: [INC/PRB/PRJ numbers if applicable]

Section 3: Configuration Items

Primary CI: [Name and CI ID from CMDB]

Additional Affected CIs:

• [CI name and ID]
• [CI name and ID]
• [Add rows as needed]

Services Affected: [Service names from service catalogue]

Section 4: Implementation

Proposed Start Date/Time: [YYYY-MM-DD HH:MM timezone] Proposed End Date/Time: [YYYY-MM-DD HH:MM timezone] Estimated Duration: [Hours:Minutes]

Implementation Plan:

1. [Step description] - [Responsible person] - [Estimated duration]
2. [Step description] - [Responsible person] - [Estimated duration] [Continue as needed]

Pre-Implementation Checks:

• [Check description]
• [Check description]

Post-Implementation Validation:

• [Test description and success criteria]
• [Test description and success criteria]

Section 5: Rollback

Rollback Trigger: [Conditions that initiate rollback]

Rollback Plan:

1. [Step description] - [Estimated duration]
2. [Step description] - [Estimated duration] [Continue as needed]

Rollback Duration: [Hours:Minutes]

Section 6: Risk Assessment

Likelihood (1-5): [Rating] Likelihood Justification: [Explanation]

Impact (1-5): [Rating] Impact Justification: [Explanation]

Risk Score: [Likelihood × Impact]

Mitigating Controls: [Actions reducing likelihood or impact]

Section 7: Communication

Stakeholders to Notify:

Section 8: Approvals

Requester Approval: [Name, Date] Change Coordinator Review: [Name, Date, Assessment notes] CAB Decision: [Approved/Approved with conditions/Deferred/Rejected] CAB Date: [YYYY-MM-DD] Conditions (if applicable): [Condition details]

Section 9: Implementation Record

Actual Start: [YYYY-MM-DD HH:MM] Actual End: [YYYY-MM-DD HH:MM] Implementation Outcome: [Successful/Rolled back/Partially complete] Implementer: [Name]

Post-Implementation Notes: [Observations, issues encountered, deviations from plan]

Section 10: Closure

Closure Date: [YYYY-MM-DD] Closed By: [Name] Closure Summary: [Brief statement of outcome and any follow-up required] Related Problem Record: [PRB number if created]

See also

• Release Management
• Configuration Management
• Post-Implementation Review
• Rollback Procedures
• Change Management Policy
• Incident Management