Operational Change Management Standard

1. Purpose

This document specifies a standard regarding the management of changes to Virginia Tech’s critical and essential IT systems, applications, and infrastructure. This standard defines terms and enumerates requirements that must be satisfied by units engaged in IT operations, with the goals of minimizing risks, ensuring system stability, and aligning IT changes with university business objectives.

2. Scope

This standard applies to:

All Virginia Tech IT systems, applications, databases, hardware, networks, and related infrastructure managed by the Division of IT that either support business functions that are considered critical or essential to the university OR that are used to store, process, or transfer high risk data, AND
All employees, contractors, and third parties who initiate, review, approve, or implement IT changes to in-scope information technology components.

3. Standard

The Operational Change Management standard categorizes changes using the following designations.

Routine Change: A low-to-moderate risk change that is performed by carrying out an approved pre-defined procedure.
Normal Change: A non-emergency change that requires risk assessment, approval, and may include coordination activities such as communication and scheduling.
Emergency Change: A change that must be implemented immediately to resolve a critical issue or security vulnerability.

All operational change records MUST be assigned to one of these categories as appropriate, based on the category definitions given above.

Sections Section 3.1 through Section 3.3 address the change management requirements for each change category.

3.1. Routine Change

The Routine Change category may be used for any low-to-moderate risk change that is accomplished by applying a pre-defined procedure. Such a procedure may be given in terms of a step-by-step process to be carried out by a human actor, by various forms of automation, or some combination thereof.

The key distinguishing characteristics of a Routine Change from other change types are as follows.

The change is performed by means of a procedure that has little variation between applications, apart from changes in parameters.
The procedure is intended to be applied for all instances in which the change it performs is needed.
Any application of the procedure has minimal observable impact to dependent systems or end-users
The risk assessment for the procedure results in a low or moderate risk classification.

3.1.1. Procedure Documentation and Approval

The procedure used for any Routine Change MUST be carefully considered, documented, and approved before it is applied. In effect, the documentation and approval of the procedure serves to authorize the application of the procedure as needed, without a requirement for further assessment and approval.

3.1.1.1. Risk Assessment of Routine Change Procedures

The risk assessment questionnaire given in Section 3.4 MUST be completed for the procedure and used to determine the associated level of risk. The Routine Change classification is applicable only when the necessary procedure is deemed to be of low-to-moderate risk. A high-risk change MUST be managed as a Normal Change under this standard, as described in Section 3.2.

3.1.1.2. Testing and Validation of Routine Change Procedures

The effectiveness of the procedure used to apply a Routine Change SHOULD be thoroughly tested and validated to the extent feasible prior to approval.

3.1.1.3. Compliance Requirements for Routine Change Procedures

A procedure used to apply a Routine Change MUST comply with applicable security, regulatory, and business continuity requirements and enterprise architecture standards.

3.1.1.4. Authorization/Approval for Routine Change Procedures

Procedures that are used to apply Routine Change MUST be approved by the Change Owner for the system(s) subject to the procedure. Approval of the procedure confers authority to those roles and/or persons designated to perform a Routine Change using the procedure. Procedures assessed as having moderate risk SHOULD be submitted to the Change Manager for review and approval by the Change Advisory Board.

3.1.1.5. Post-Implementation Review for Routine Change Procedures

Effectiveness of a procedure used to apply Routine Change SHOULD be periodically reviewed and reassessed, especially with continuing evolution of the systems to which such procedures are applied.

3.1.1.6. Documentation of Routine Change Procedures

Documentation for a procedure used to apply a Routine Change SHOULD minimally include the following elements.

A brief description of the purpose, mechanism, and intent of the procedure.
Identification and/or description of roles or persons who are authorized to apply a Routine Change using the procedure.
A risk assessment for the procedure, leading to a classification of low or moderate risk. A high-risk change MUST be managed as a Normal Change under this standard, as described in Section 3.2.
A descriptive record of methods used to test and validate the actions used in the procedure, and any applicable results.
A dated record of approval for the procedure, and for revisions as applicable.

The designated Change Management System MAY provide the means to document and reference the procedure used in applying a Routine Change. An implementation of this standard MUST either make use of such a facility OR produce and maintain external documentation for each procedure used for a Routine Change as specified herein.

3.1.2. Change Record for a Routine Change

A Routine Change carried out by an approved procedure MUST be accompanied by a distinct record in the designated Change Management System. See Section 3.5 for requirements that must be satisfied by the record for a Routine Change.

3.1.3. Risk Assessment for a Routine Change

There is NO REQUIREMENT for risk assessment when authorized personnel apply an approved Routine Change procedure for its intended and documented purpose.

3.1.4. Approval for a Routine Change

There is NO REQUIREMENT for explicit approval when authorized personnel apply an approved Routine Change procedure for its intended and documented purpose. Authorized personnel may apply an approved procedure for a Routine Change whenever appropriate, as needed. A Change Owner or line manager responsible for systems to which Routine Change procedures are applied MAY impose additional approval requirements for Routine changes as deemed necessary and appropriate.

3.1.5. Testing and Validation for a Routine Change

Testing and validation for a Routine Change SHOULD be a function of development, review, and approval of the underlying procedure used to apply the change. In most cases, the procedure SHOULD include mechanism(s) for validating the resulting outcome, either as a step to be performed by a human actor, or through some form of automation, or some combination thereof. The extent of post-application validation performed for an application of a Routine Change procedure SHOULD be commensurate with the risk classification of the procedure.

3.1.6. Change Coordination for a Routine Change

A Routine Change is defined in part by the characteristic that it is of low-to-moderate risk, and will have minimal observable impact to dependent systems or end-users. As such there is NO REQUIREMENT for coordinated scheduling or communication (e.g. through the Change Advisory Board) when a Routine Change procedure is applied to its intended, documented, and approved purpose, by authorized personnel. A Change Owner or line manager responsible for systems to which Routine Change procedures are applied MAY impose additional coordination requirements as deemed necessary and appropriate.

3.1.7. Post-Implementation Review for a Routine Change

There is NO REQUIREMENT for post-implementation review when a Routine Change procedure is applied to its intended, documented, and approved purpose AND results in a successful outcome. In the event that a Routine Change has an unanticipated impact or otherwise unsuccessful outcome, a post-implementation review is REQUIRED. Post-implementation review SHOULD include both a root cause analysis and a recommendation for revisions to the procedure and/or other actions as appropriate to ensure future successful outcomes using the procedure.

As noted in Section 3.1.1.5, a procedure used to apply a Routine Change SHOULD be periodically reassessed to validate continued effectiveness and successful outcomes.

3.2. Normal Change

The Normal Change category is used for non-emergency changes that require risk assessment, planning, approval, and may include coordination activities such as communication and scheduling. The level of process required for a Normal Change varies according to the assessed risk, with fewer formal requirements for changes that are deemed low risk as compared to those assessed as being of moderate or high risk.

3.2.1. Change Record for a Normal Change

A Normal Change MUST be accompanied by a distinct record in the designated Change Management System. See Section 3.5 for requirements to be satisfied by the record for a Normal Change.

3.2.2. Risk Assessment for a Normal Change

Every proposed Normal Change MUST be assessed for risk. The Risk Assessment Questionaire given in Section 3.4 MUST be completed for each Normal Change prior to requesting approval.

3.2.3. Approval for a Normal Change

Approval requirements for a Normal Change vary according to assessed risk, as given in the following subsections.

3.2.3.1. Low Risk Normal Change

A Normal Change assessed as having low risk SHOULD be approved by the Change Owner. In cases for which the Change Owner is also the Change Requestor or Change Assignee, approval SHOULD be obtained from a peer or effective supervisor of the Change Owner.

3.2.3.2. Moderate Risk Normal Change

A Normal Change assessed as having moderate risk MUST be approved by the Change Owner. In cases for which the Change Owner is also the Change Requestor or Change Assignee, approval SHOULD be obtained from a peer or effective supervisor of the Change Owner.

3.2.3.3. High Risk Normal Change

A Normal Change assessed as having high risk MUST be approved by the Change Owner AND by the Change Manager representing the consensus of the Change Advisory Board.

3.2.3.4. Approval in the Context of IT Projects

An Enterprise or Standard IT project may specify approval roles for any Normal Change made to existing in-scope systems in the course of project execution. In this case, an Operational Change Management plan for the project MUST identify the approver roles and/or persons and alternates, appropriately aligning required approval roles with risk assessment.

3.2.3.5. Alternate Approver Roles or Personnel

Any role specified as an approver (e.g. Change Owner, Change Manager, Supervisor, Director, etc) may be replaced with a designee either temporarily or permanently. Such substitutions SHOULD be documented and approved by the effective supervisor for the subject role.

An implementation of this standard MAY specify different roles responsible for approvals based on and risk assessment (Low, Moderate, or High), with the approval of the VP for Information Technology (or designee).

3.2.4. Testing and Back-Out Planning for a Normal Change

A Normal Change SHOULD be tested in a representative non-production environment whenever feasible. Testing SHOULD be performed prior to seeking Change Advisory Board approval when such is required. Results of such testing or a statement explaining why such testing is infeasible SHOULD be noted in the Change Record.

When planning a proposed change, plans for reverting the change SHOULD be developed if feasible. Back out plans and/or a statement explaining why back out is infeasible SHOULD be noted in the Change Record.

3.2.5. Change Advisory Board Approval

Change Advisory Board review and approval is REQUIRED if any of the following conditions are true.

Change risk assessment designates the change as high risk.
The change requires the involvement of multiple IT units.
There are significant potential impacts if the change has an unexpected outcome.

The purpose of review by the Change Advisory Board is to ensure that communication and scheduling considerations are duly addressed by the planned change. See Section 3.6.

3.2.6. Post-Implementation Review for a Normal Change

Any Normal Change MAY include a post-implementation review. A post-implementation review SHOULD be conducted for any Normal Change that has an unexpected outcome.

Post-implementation review MUST be conducted for a Normal Change satisfying any of the criteria given in Section 3.6.2, and therefore requiring additional coordination. The Change Manager MUST be included in the post-implementation review process for any Normal Change that was reviewed by the Change Advisory Board prior to implementation.

The review process SHOULD produce a document that identifies any unexpected outcomes and lessons learned. Whenever possible, a root cause analysis SHOULD be performed and documented for unexpected outcomes. The review document SHOULD include recommended changes in planning or execution practices for similar changes in the future. The review document MUST be either attached or referenced by the Change Record.

3.3. Emergency Change

An Emergency Change refers to a change that must be implemented immediately to resolve a critical service-impacting issue or security vulnerability. Such situations admit relatively little time for planning and associated process prior to implementation of the necessary change.

3.3.1. Scope of an Emergency Change

In an Emergency Change operation, technical staff and responsible managers SHOULD limit the scope of change to that which is necessary and effective to address the emergent situation at hand. Use the Normal Change process to address additional considerations after the emergent situation has been contained.

3.3.2. Authorization for an Emergency Change

Authorization to perform an Emergency Change when necessary SHOULD be included in position descriptions for technical administration roles directly responsible for systems in scope for this standard. Whenever feasible, responsible Change Owners, service owners, and more senior management roles SHOULD be engaged in decision-making during an Emergency Change operation.

3.3.3. Communication During an Emergency Change

Communication to units not directly involved in the Emergency Change (for the purpose of situational awareness) SHOULD be considered whenever feasible, without unduly diverting resources from resolution of the situation itself. Notifications SHOULD be directed through established communication channels used for major incidents.

3.3.4. Documentation for an Emergency Change

After an Emergency Change operation, a Change Record SHOULD be created in the Change Management System to briefly describe the motivation and the specifics of the change itself. The responsible Change Owner or designee SHOULD approve the Change Record after validating that relevant details have been included in the record.

The creation and approval of the Change Record is separate from any after-action process or reporting for an incident that may have given cause for the Emergency Change.

See Section 3.5 for requirements to be satisfied by the record for an Emergency Change.

3.4. Risk Assessment Questionnaire

A Normal Change, as well as any procedure used to apply a Routine Change must be assessed for risk, in consideration of impact, criticality, coordinated effort, and confidence. Consider each question carefully and with a reasonably broad interpretation to account for unique circumstances inherent to various delivered services and supporting infrastructure. Overall risk is determined by the highest score assigned to any question. All questions MUST be answered.

As specified in Section 3.1.3, risk assessment for a procedure that will be used for a Routine Change MUST NOT result in an assessment of High risk.

	Question	Low Risk (1)	Moderate Risk (2)	High Risk (3)
1	How many users are impacted?	The change will not affect any user’s ability to perform core business functions.	The change will affect core business functions for a significant number of users.	The change will affect many users throughout a college, administrative unit, or campus.
2	What is the impact of the change if it is unsuccessful?	Users can continue to perform core business functions.	Users cannot perform core business functions.	There is a direct impact on revenue, brand, compliance, research, or teaching, OR could result in fines levied against the university.
3	How many distinct IT teams are involved with implementation?	Implementation activities are limited to a single IT team.	Multiple teams within the same IT unit or at least two IT teams in two different units need to coordinate activities.	More than two teams in different IT units need to coordinate activities.
4	Can the change be tested and/or backed out if necessary?	The change will be tested in a representative test environment AND can be backed out easily if necessary.	The change either cannot be tested in a representative test environment OR cannot be backed out easily.	The change cannot be tested in a representative test environment AND cannot be backed out easily.
5	When will the proposed change occur?	The change will occur during a standard maintenance window.	The change will occur outside a standard maintenance window, but the risk of significant service outage is considered to be low.	The change will occur outside a standard maintenance window and may involve a significant service outage, OR the change will occur during a maintenance-restricted period.
6	Does the planned schedule overlap with previously scheduled changes OR with a Maintenance-Restricted time interval?	No other changes are scheduled at the same time as the proposed change and the planned schedule is not within a Maintenance-Restricted interval.	There is some overlap with other scheduled changes, but there is no known dependency between the proposed change and any of the other scheduled changes, and the schedule does not overlap with a Maintenance-Restricted interval.	The proposed change overlaps with other scheduled changes that affect shared systems, infrastructure, or user populations, creating potential for conflict or compounded impact, OR the schedule overlaps with a Maintenance-Restricted interval.

Question

Low Risk (1)

Moderate Risk (2)

High Risk (3)

How many users are impacted?

The change will not affect any user’s ability to perform core business functions.

The change will affect core business functions for a significant number of users.

The change will affect many users throughout a college, administrative unit, or campus.

What is the impact of the change if it is unsuccessful?

Users can continue to perform core business functions.

Users cannot perform core business functions.

There is a direct impact on revenue, brand, compliance, research, or teaching, OR could result in fines levied against the university.

How many distinct IT teams are involved with implementation?

Implementation activities are limited to a single IT team.

Multiple teams within the same IT unit or at least two IT teams in two different units need to coordinate activities.

More than two teams in different IT units need to coordinate activities.

Can the change be tested and/or backed out if necessary?

The change will be tested in a representative test environment AND can be backed out easily if necessary.

The change either cannot be tested in a representative test environment OR cannot be backed out easily.

The change cannot be tested in a representative test environment AND cannot be backed out easily.

When will the proposed change occur?

The change will occur during a standard maintenance window.

The change will occur outside a standard maintenance window, but the risk of significant service outage is considered to be low.

The change will occur outside a standard maintenance window and may involve a significant service outage, OR the change will occur during a maintenance-restricted period.

Does the planned schedule overlap with previously scheduled changes OR with a Maintenance-Restricted time interval?

No other changes are scheduled at the same time as the proposed change and the planned schedule is not within a Maintenance-Restricted interval.

There is some overlap with other scheduled changes, but there is no known dependency between the proposed change and any of the other scheduled changes, and the schedule does not overlap with a Maintenance-Restricted interval.

The proposed change overlaps with other scheduled changes that affect shared systems, infrastructure, or user populations, creating potential for conflict or compounded impact, OR the schedule overlaps with a Maintenance-Restricted interval.

3.5. Change Management System Requirements

Every system that is in scope for this standard MUST be assigned to an approved Change Management System which serves as the system of record for all change requests, associated documentation, and required approvals. The VP for Information Technology (or designee) is the approval authority for a Change Management System to be assigned to any system in the scope of this standard.

A Change Management System may consist of a combination of change management application software, as well as supporting procedures and supplementary documentation. The intent of the standard is not to state requirements that must be fully satisfied by any change management application software. Rather, these are requirements to be satisfied by the Change Management System as a whole. In the event that the selected change management application software does not satisfy all stated requirements, the overall system MUST be designed (through supporting procedures and associated documentation) to fully satisfy all stated requirements.

3.5.1. Change Record Requirements

A Change Record MUST be represented as a distinct record, minimally consisting of the following fields of information. For each field, the table indicates whether the field is REQUIRED for each change category.

Name	Description	Routine Change	Normal Change	Emergency Change
Change Record ID	A unique identifier for the record within the scope of the subject Change Management System. This identifier may be used to refer to the Change Record in documentation and communications related to the change	Y	Y	Y
Change Category	Indicates whether the record identifies a Routine Change, Normal Change, Emergency Change	Y	Y	Y
Creation Timestamp	Date and time representing the instant at which the record was created	Y	Y	Y
Last Modification Timestamp	Date and time representing the instant at which the record was last modified	Y	Y	Y
Creator ID	An identifier for a distinct record in the university’s enterprise directory representing the person who created the Change Record	Y	Y	Y
Change Requestor ID	An identifier for a distinct record in the university’s enterprise directory representing the person in the Change Requestor role for the requested change. In many cases, this identifier will be the same as that given for the Creator ID, but will differ when a Change Record is submitted by someone other than the Change Requestor	N	Y	N
Change Owner ID	An identifier for a distinct record in the university’s enterprise directory representing the person in the Change Owner role for the requested change. This field may initially be blank, but MUST be specified before the Change Record is submitted for any required approval(s).	N	Y	Y
Change Title	A summary description of the requested change. For a Routine Change this may contain a display name for the procedure used to perform the change.	Y	Y	Y
Change Description	A detailed description of the requested change. This field may additionally contain planning notes, review notes and other information relevant to the Change Owner and reviewers. In the case of an Emergency Change this field SHOULD include the motivation for the change (as an emergency) and relevant details of the change that was performed.	N	Y	Y
Risk Assessment Outcome	A field that specifies whether the change is deemed low risk, moderate risk, or high risk. This field MUST be specified before the record is submitted for any required approval(s).	N	Y	N
Primary Approver ID	An identifier for a distinct record in the university’s enterprise directory representing the first level approval for the change, when required. Note that for an Emergency Change, this field signifies a posthoc acknowledgment of the change, not an approval.	N	Y	Y
Primary Approval Timestamp	Date and time representing the instant at which the primary approval was completed (if approval was required). Note that for an Emergency Change, this field specifies the timestamp of posthoc acknowledgment of the change, not of approval.	N	Y	N
Secondary Approver ID	Identifier for a distinct record in the university’s enterprise directory representing the second level approval for the change, when required. This identifies the acting Change Manager for a Normal Change that requires Change Advisory Board review and approval.	N	Y	N
Secondary Approval Timestamp	Date and time representing the instant at which the secondary approval was completed.	N	Y	N
Change Status	A field that indicates (typically using an enumeration of possible values) the lifecycle status of the requested change; e.g. New, In Planning, In Review, Approved, Completed, Abandoned). Routine Change and Emergency Change records MAY use a small subset of the possible values.	Y	Y	Y
Closure Timestamp	Date and time representing the instant at which the record was closed; i.e. after the change process associated with the record was completed or abandoned.	Y	Y	Y
Routine Procedure ID	A Change Record representing a Routine Change MUST identify the corresponding procedure. This may be a well known name for the procedure, a link to a procedure document, or some other identifier for the procedure. The requirement is simply that the Change Requestor, Change Owner, and/or reviewers can easily identify the corresponding procedure and locate relevant documentation as needed.	Y	N	N

Name

Description

Routine Change

Normal Change

Emergency Change

Change Record ID

A unique identifier for the record within the scope of the subject Change Management System. This identifier may be used to refer to the Change Record in documentation and communications related to the change

Change Category

Indicates whether the record identifies a Routine Change, Normal Change, Emergency Change

Creation Timestamp

Date and time representing the instant at which the record was created

Last Modification Timestamp

Date and time representing the instant at which the record was last modified

Creator ID

An identifier for a distinct record in the university’s enterprise directory representing the person who created the Change Record

Change Requestor ID

An identifier for a distinct record in the university’s enterprise directory representing the person in the Change Requestor role for the requested change. In many cases, this identifier will be the same as that given for the Creator ID, but will differ when a Change Record is submitted by someone other than the Change Requestor

Change Owner ID

An identifier for a distinct record in the university’s enterprise directory representing the person in the Change Owner role for the requested change. This field may initially be blank, but MUST be specified before the Change Record is submitted for any required approval(s).

Change Title

A summary description of the requested change. For a Routine Change this may contain a display name for the procedure used to perform the change.

Change Description

A detailed description of the requested change. This field may additionally contain planning notes, review notes and other information relevant to the Change Owner and reviewers. In the case of an Emergency Change this field SHOULD include the motivation for the change (as an emergency) and relevant details of the change that was performed.

Risk Assessment Outcome

A field that specifies whether the change is deemed low risk, moderate risk, or high risk. This field MUST be specified before the record is submitted for any required approval(s).

Primary Approver ID

An identifier for a distinct record in the university’s enterprise directory representing the first level approval for the change, when required. Note that for an Emergency Change, this field signifies a posthoc acknowledgment of the change, not an approval.

Primary Approval Timestamp

Date and time representing the instant at which the primary approval was completed (if approval was required). Note that for an Emergency Change, this field specifies the timestamp of posthoc acknowledgment of the change, not of approval.

Secondary Approver ID

Identifier for a distinct record in the university’s enterprise directory representing the second level approval for the change, when required. This identifies the acting Change Manager for a Normal Change that requires Change Advisory Board review and approval.

Secondary Approval Timestamp

Date and time representing the instant at which the secondary approval was completed.

Change Status

A field that indicates (typically using an enumeration of possible values) the lifecycle status of the requested change; e.g. New, In Planning, In Review, Approved, Completed, Abandoned). Routine Change and Emergency Change records MAY use a small subset of the possible values.

Closure Timestamp

Date and time representing the instant at which the record was closed; i.e. after the change process associated with the record was completed or abandoned.

Routine Procedure ID

A Change Record representing a Routine Change MUST identify the corresponding procedure. This may be a well known name for the procedure, a link to a procedure document, or some other identifier for the procedure. The requirement is simply that the Change Requestor, Change Owner, and/or reviewers can easily identify the corresponding procedure and locate relevant documentation as needed.

3.5.2. Additional Requirements

A Change Record MAY be accompanied by other information that is necessary or useful in managing and executing a request. This MAY include document attachments or references to documents in the form of links to document storage repositories. All documentation associated with a Change Record MUST be attached or referenced within the request.
When supplementary documentation is stored external to the Change Record itself, the design of the Change Management System application and/or associated processes SHOULD ensure that external documents are retained with the same duration as the Change Record record itself.
The completed Risk Assessment Questionaire may be represented as either an attached or linked document or embedded within the Change Record record itself, and MUST accompany all change categories and risk levels that require it.
Testing and validation documentation may be represented as either an attached or linked document or embedded within the Change Record record itself, and MUST accompany all change categories and risk levels that require it.
Post-Implementation Review documentation may be represented as either an attached or linked document or embedded within the Change Record record itself, and MUST accompany all change types and risk levels that require it.
A conformant Change Management System is not required to store all the required information in a single record-like structure. However, all information required for a Change Record MUST be readily producible upon request.
A conformant Change Management System MUST provide a means to create a detailed report of one or more Change Record objects which includes the information required under Section 3.5.1. A Change Management System application SHOULD provide a means of exporting this information into a common form for use within other applications; e.g. using comma-separated values (CSV), JSON, XML, or other textual representation.
Change Record objects and associated documentation MUST be retained in compliance with applicable records retention policy.

3.6. Change Advisory Board

The role of the Change Advisory Board is the collective review, coordination, and scheduling of approved change requests. The purpose of board review is generally not to consider the need for the requested change or the manner by which the requested change will address the stated need. Rather, board review serves to ensure that changes are coordinated and communicated among all relevant stakeholders.

3.6.1. Prior Approval Requirement

Normal Change requests submitted for board review MUST first be approved according to the requirements given in Section 3.2.3. Board members may therefore assume that the Change Owner and associated approver(s) have acted with due diligence in considering the requested change and its implementation plan.

3.6.2. Changes Subject to Board Review

Any change request that is likely to have an impact on other dependent in-scope systems SHOULD be submitted for board review. A change that will or could impact a significant number of end users MUST be submitted for board review. The Change Owner is responsible for ensuring that relevant change requests are submitted for board review as required. A change request submitted for board review MUST NOT be performed until the board has completed its review and a schedule for the change has been finalized and communicated.

3.6.3. Board Approval for Changes Needed by IT Projects

Changes to in-scope systems needed in the execution of Enterprise or Standard IT projects MAY have project-specific change approvals as noted in Section 3.2.3.4. Project-related change requests MUST be submitted for board approval using the same criteria used for any other Normal Change request. The Change Owner SHOULD advise the board (via the Change Record) of any project-specific scheduling or communications requirements, or other considerations unique to the project.

3.6.4. Board Membership and Procedures

An implementation of this standard MUST define membership and procedures for the Change Advisory Board satisfying the following requirements.

Specify a collective representation of IT staff, Managers, Supervisors, and/or Directors responsible for in-scope systems who will serve as Change Advisory Board members. The implementation SHOULD identify the criteria for membership and the mechanism(s) by which board members and a Change Manager will be appointed.
Specify the mechanism by which a Change Manager will submit approved Normal Change requests for review by the board.
Specify the schedule and/or conditions under which the board will be convened to conduct review, scheduling, and communication processes.
Specify a communications plan for scheduled changes that accounts for the level of impact to dependent systems and end users. Communications and scheduling for broad impact changes MUST account for the time and effort necessary for preparation, review, and approval of public communications (typically via Division-level communicators).
Prepare and maintain a global calendar of board-reviewed and scheduled Normal Change requests which may be accessed by authorized university employees.

4. Compliance and Enforcement

It is the responsibility of University IT service providers to ensure that the controls described in this document are implemented. University departments undergo periodic audits. These audits sometimes include an analysis of the processes and controls used by departments to secure and manage end user devices, servers, and applications. The department is responsible for remediation of any findings of noncompliance with this standard within the time frame agreed to with the auditors.

5. Definitions

Change: any addition, modification, or removal of IT systems, applications, hardware, processes, or configuration that may affect in-scope IT services and/or applications.
Change Record: a record in a designated Change Management System that specifies the details of the requested change and justification. The change record is updated during planning for the change to include all relevant documentation and approvals for the requested change.
Change Management System: the designated system of record for all changes applied to a system that is in the scope of this standard
Change Requestor: submits a change request
Change Assignee: soordinates risk assessment, planning, testing, and implementation of the change.
Change Owner: the supervisor or manager directly responsible for the system(s) subject to a proposed change
Change Manager: a role assigned for the purpose of organizing and managing the activities of the Change Advisory Board
Change Advisory Board: responsible for coordination, communication, and scheduling for changes that have broad impact to dependent in-scope systems and/or end users.
Maintenance-Restricted: a period of time during which maintenance activities such as Normal Change actions are generally prohibited to ensure system stability during critical university business activities such as final semester exams, commencement, etc.

6. References

ITIL 4 Change Management Guidelines
NIST 2.0 ID.RA-07
ISO 27001:2022 Annex A Control 8.32

7. Maintenance

The Information Technology Governance, Policy, and Strategy (IT-GPS) office is responsible for development and maintenance of the standard.

8. Revision History

Version 1.0: 22 June 2026
Initial Draft: November 2025