5.1.2. Apply change management procedures. (Obj. 4.2)

💡 First Principle: Controlled, documented change minimizes business impact and reduces risk.

In IT, change is constant: new software is deployed, servers are patched, and network hardware is upgraded. However, uncontrolled change is the number one cause of unexpected outages and business disruption. Change management is a formal process for managing these changes in a planned, predictable, and controlled manner. It's not about preventing change; it's about making sure change happens smoothly and safely.

A formal change management process typically includes several key components, often submitted as a "Request for Change" (RFC):

• Purpose and Scope: A clear statement of why the change is needed and exactly which systems will be affected.
• Risk Analysis: What could go wrong? What is the potential impact on the business if the change fails? This is a critical thinking step.
• Change Plan: A detailed, step-by-step procedure of how the change will be implemented.
• Rollback Plan: This is arguably the most important component. A rollback plan is a pre-defined, step-by-step procedure to revert the system to its original, working state if the change causes unforeseen problems. A change should not be approved without a viable rollback plan.
• Backup Plan and Sandbox Testing: Back up the affected system before the change so data can be restored if the rollback is not enough, and test the change in a sandbox (a non-production copy) first—production is never the test environment.
• Communication Plan: Who needs to be notified about the change and when? This includes end-users who might be affected and other IT teams.
• Approval: The change request is reviewed by a Change Advisory Board (CAB), which includes stakeholders from different parts of the business. They assess the risk and either approve, deny, or request more information about the change.
• Peer Review and Scheduling: The plan is peer-reviewed by another technician, and the RFC names the responsible staff member, the affected systems, a risk level, and the date and time. Changes are normally scheduled into a maintenance window, an agreed period (often after hours) when work can be done with the least disruption to users.
• Implementation, End-User Acceptance, and Closure: After implementation, the people who actually use the system confirm that it works and their workflow is unaffected (end-user acceptance). The outcome is then documented and the change record closed.
• Change Types: A standard change is routine, low-risk, and pre-approved, following a documented procedure without a CAB review each time (e.g., installing an application from the approved software catalog). A normal change goes through full CAB review. An emergency change fixes an urgent problem, such as a major outage or an actively exploited vulnerability, through expedited approval (often an emergency CAB or a manager's verbal approval), with documentation completed afterward. It still needs a rollback plan. A change freeze is a period (e.g., quarter-end) during which non-emergency changes are not allowed.

Technician's Action Plan: Scenario: You need to apply a critical security patch to the company's primary file server. This will require a server reboot and will cause a brief outage. The maintenance must be done outside of business hours.

1. Submit a Request for Change (RFC): You don't just take the server down. You fill out a formal RFC document.
2. Fill Out the RFC Details:
   • Purpose: "To apply critical security patch KB5012345 to FILESRV01 to mitigate a known remote code execution vulnerability."
   • Scope: "This change affects only FILESRV01."
   • Risk Analysis: "Low risk of failure as the patch is from the vendor. However, the impact of failure is high as all users rely on this server. The reboot will cause a 15-minute outage for all network shares."
   • Change Plan: Provide the exact steps: 1. Notify users of impending maintenance. 2. Log into FILESRV01. 3. Install patch KB5012345 from Windows Update. 4. Reboot the server. 5. After reboot, verify network shares are accessible.
   • Rollback Plan: "If the server fails to boot or network shares are inaccessible after the patch, the plan is to: 1. Boot into the Windows Recovery Environment. 2. Use the command line to uninstall the last installed quality update. 3. Reboot the server to its pre-patch state."
   • Communication Plan: "An all-staff email will be sent 24 hours prior to the maintenance window. A final reminder will be sent 1 hour before."
3. Obtain Approval: Submit the RFC to the CAB for approval. Once approved, you can proceed with the change during the scheduled maintenance window, knowing that you have a well-documented plan and have minimized risk to the business.

Reflection Question: Why is a "Rollback Plan" considered the most important component of a change management request?