PRO-3000.07H: Change and Release Management Procedure

Intended Audience: University personnel responsible for managing University computing and networking devices
Procedure Owner: Director of Information Security

1. Definitions

Change Advisory Board	A group of technical experts, management, and stakeholders that evaluate and approve information technology (IT) service changes.
Change Management	The process by which changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner. Change Management processes ensure that standardized methods are used for the efficient and prompt handling of all changes and that overall business risk is minimized.
Emergency Change	Changes that must be done quickly due to a serious threat or service interruption. Examples include zero-day vulnerability patches or enterprise system failure fixes.
Normal Change	Any changes that cannot be classified as an Emergency Change or Standard Change. Examples include application software upgrades or application configuration changes.
Release Management	The process of managing, planning, scheduling, and communicating a system or application change. Release Management occurs after changes are approved.
Standard (pre-authorized) Change	Changes done on a regular schedule and/or in a repetitive manner. Examples are the installation of monthly Microsoft operating system patches or a test database refresh. These changes do not require approval from the Change Advisory Board, but they must be documented. Customers must be notified if there is the potential for service interruptions.

2. Introduction

OCIO 141.10: 8.1

Changes to any information technology (IT) system should be done using formal, documented Change and Release Management procedures. Separate procedures are required for Standard, Normal, and Emergency changes, though they all may share some common steps.

3. Standard Changes

Standard Changes should follow the same process each time they are implemented for a particular change (e.g., Windows patches). Standard changes have the following eight steps:

3.1 Review of Release Notes

For commercial or open-source applications, functional and system analysts review release notes—together with database administrators, if applicable—to determine the dependencies between modules on other environments and on integrations with other Western systems.

3.2 Testing of Changes

Evaluate Standard Changes in a test environment or test population prior to full deployment in production.

3.3 Recovery/Rollback Planning

Document and test the procedures for backup and recovery of a system or rollback of a change prior to implementing a change. If no environment exists to test a change, a recovery/rollback plan can serve to mitigate risk from the change. Routine changes can utilize the same Recovery/Rollback plan each time they happen.

3.4 Change Requests

Log Standard Changes in the appropriate change management system [e.g., the Information Technology Services (ITS) ticketing system Jira].

3.5 Release Management Planning

Standard Changes may use the same Release Management plan each time the change happens. Include the following in the Release Management plan:

Personnel (title or name) performing the change.
Description of the release process.
Release schedule(s).
Any stakeholder communications required for the change.
Add the Release Management plan to the Change Request ticket.

3.6 Communications

Inform the users impacted by a change of the change and its impact, as detailed in the Release Management Plan.

3.7 Implementation

Make changes as per the Release Management plan.

3.8 Closure

After completion of a change, inform users, as appropriate to the magnitude of the change, and close the Change Request ticket.

4. Normal Changes

Normal Changes are typically used for application upgrades, hardware changes, and system configuration changes; however, they may include any type of non-Emergency or non-Routine Change. Normal Changes have the following nine steps:

4.1 Review of Release Notes

4.2 Testing of Changes

Evaluate Normal Changes in a test environment or test population, prior to full deployment in production.

4.3 Recovery/Rollback Planning

Document and test the procedures for backup and recovery of a system or roll backup of a change prior to implementing a change. If no environment exists to test a change, a recovery/rollback plan can serve to mitigate risk from the change.

4.4 Change Requests

Log all Standard Changes in the ITS ticketing system (Jira).

4.5 Change Approval

Send Normal Change Requests to the Change Management Advisory Board for approval a week before the actual change. Include in the Request a description of the change, along with any end-user impacts and risks that might result from the change.

4.6 Release Management Planning

After a change is approved, create a Release Management Plan, and add it to the Change Request ticket. The plan should include:

Personnel (title or name) performing the change
Description of the release process
Release schedule(s)
Any stakeholder communications required for the change.

4.7 Communications

Inform the users impacted by a change of the change and its impact, as detailed in the Release Management Plan.

4.8 Implementation

Make changes as per the Release Management plan.

4.9 Closure

After completion of a change, inform users, as appropriate to the magnitude of the change, and close the Change Request ticket.

5. Emergency Changes

Emergency Changes are typically used when there is a service failure or security threat. Emergency Changes have the following nine steps:

5.1 Review of Release Notes

For commercial or open-source applications, if release notes or other documentation are available, they should be reviewed by functional and system analysts—together with database administrators, if applicable—to determine the dependencies between modules on other environments and on integrations with other Western systems.

5.2 Testing of Changes

If possible, evaluate Emergency Changes in a test environment prior to deployment in production.

5.3 Backup and Recovery/Rollback Planning

Document and test the procedures for backup and recovery of a system or rollback of a change prior to implementing an Emergency Change. If possible, backup the systems prior to the change. If no environment exists to test the change, a recovery/rollback plan can serve to mitigate risk from the change.

5.4 Change Requests

Log all Emergency Changes in the ITS ticketing system Jira.

5.5 Change Approval

An ITS Director may approve Emergency Change Requests changes impacting departmental users or for a limited scope of users. The University’s Chief Information Officer must approve Emergency Changes for mission critical, enterprise, system of record, or high-use systems. For either case, approval may be via email or phone call. Note the approval in the Jira ticket.

5.6 Release Management Planning

After a change is approved, create a Release Management Plan and add it to the Change Request ticket. The plan should include:

Personnel (title or name) performing the change.
Description of the release process.
Release schedule(s).
Any stakeholder communications required for the change.

5.7 Communications

Inform the users impacted by a change of the change and its impact, as detailed in the Release Management Plan.

5.8 Implementation

Make changes per the Release Management plan.

5.9 Closure

After completion of a change, inform users and close the Change Request ticket.

6. References

1. Information Technology Services guideline GDL-3000.07H: Change and Release Management Guideline

Change Log

Revised	Version	Author	Approver	Change
06/18/2021	1.0	Beth Albertson	ITS Standards & Guidelines Committee	Original Version