3.2.8 Change Management Procedure
Purpose
IT Change Management is a process designed to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.
Scope
Piedmont OIT follows ITIL v4 framework for Change Management and categorizes changes between the following three (3) categories: Standard Change, Normal Change, and Emergency Change.
Definitions/Acronyms
ITSM – IT service management
SNOW - Service Now
ITIL v4- Information Technology Infrastructure Library
ITPOC – Information Technology Projects Oversight Committee
Azure AD – Azure Active Directory
Procedures
Standard Change:
Changes to a service or to the IT infrastructure where the implementation process and the risks are known, upfront and low. These changes are managed according to the policies and procedures already existing in the organization and they are easy to prioritize, implement and back out from.
Example: Server Operating System Patching is a recurring work that is already standardized, easy to implement, low risk and easy to back out from based on our practice.
Approval Process:
Standard change process is documented and provided to ITPOC, but no official approval is required.
Normal Change:
Normal changes are those that must go through the change process before being approved and implemented. If they are determined to be high-risk, a ITPOC must decide if the suggested date and time will suffice for the campus for them to be implemented.
Example: Upgrade of the telecom system / other application system. There are lots of moving parts in such work, and testing and validation is integral part of this process.
Approval Process: Normal changes will require approval from application/data owners/stakeholders to ensure proper testing/validation/communication etc. is done prior and post execution.
Emergency Change:
Emergency changes arise when an unexpected error or threat occurs, such as when a flaw in the infrastructure related to services needs to be addressed immediately. A security threat is another example of an emergency that requires changes to be made immediately.
Example: Critical security patch is released by OS/Application vendors that requires immediate deployment.
Approval Process: Emergency changes do not require approval from the ITPOC, but they will be notified with the primary focus to return services to normal state. OIT senior staff approval is sufficient to execute Emergency Change.
Change Management Criteria for Patching
All standard OS security patch updates will be treated under the Standard Change Process described above.
All critical OS security patch updates will continue to be evaluated based on the Common Vulnerability Scoring System (CVSS) rating for criticality and will follow an emergency schedule as needed under the Emergency Change Management Process described above.
For Normal and Emergency Changes, appropriate parties will be notified.
For Standard Changes, a general notification method will be used.
For all changes and snapshots/backups of server state will be taken prior to changes.
Communication Requirements
Communication Requirements for Standard Changes
- Share the information with Helpdesk.
Communication Requirements for Normal Changes:
- Send a notification to the campus/appropriate stakeholders at least 3 days in advance.
- Resend a day before the change, then hours prior to the change occurring.
- Communication to be sent once the change has been completed will also be sent.
- Notify stakeholders as per ITSM practice and obtain authorization.
- Develop and execute communication plans with key stakeholders.
Communication Requirements for Emergency Changes:
- Send a notification to the campus/appropriate stakeholders once an incident has been identified and the need for immediate mitigation which may cause a disruption in normal operations.
- Communication to be sent once the change has been completed will also be sent.