• All changes within the current scope must go through the Change Management process and must have a completed request for change (RFC) with appropriate approvals.
  • Campus/University scope and very high or high risk changes require CAB and AVP or CIO review and approval.
  • Campus/University scope and moderate or low risk changes require CAB review and approval.
  • Significant scope and very high or high risk changes require CAB review and approval.
  • Risk assessment and scope are used to determine the lead time and level of IS&T approval required for all changes. Whenever possible, RFCs will be requested for approval with no less than the defined minimum lead times for their risk and scope profiles.
  • A risk assessment must be provided for each change by answering the required questions within the RFC. Requirements for Client and Information Security approval should be identified in advance and noted in the appropriate section of the RFC.
  • Change windows will be pre-defined and published.
  • All changes will be entered on the IS&T calendar.
  • If a change needs to be scheduled outside of a change window, the change’s implementation date/time needs approval from the appropriate parties (CAB, ECAB, Change Manager, the business, etc.).
  • If the date changes for a normal change, approvers (Change Sponsor, Change Manager, and CAB) are notified, but additional approvals are not required. If the date changes for an urgent change, the ECAB is notified and existing approvals are subject to revision.
  • If required, approvals from the business or service owner should be obtained and attached to the RFC when created and before the Change Management ‘Request for Approval’ process is initiated.
  • All IS&T data center power-related changes must be assigned a scope of University/Campus-wide.
  • A Planned Start Date/Time, Back-out Date/Time, and Planned End Date/Time shall be provided for each change.
  • All changes must contain the following plans: implementation plan, back-out plan, test plan, and communication plan. These plans can be entered directly into the appropriate sections or can be provided via an attached document.
  • All changes will be visible to the Service Desk.
  • All Campus/University or multiple group changes that are service-impacting require communication to a broader client audience (e.g., email to Techstatus list, posted on TechWeb, etc.).
  • Proof that controls (initiation, testing, and approval) have been followed for all auditable changes shall be stored with the ability to be reproduced.
  • Each change shall be initiated through a standardized and approved process (service request, incident management, problem management, or PRIME)
  • Each change should be well tested and verified prior to implementation.
  • All implementation work on the change should be completed by the Planned End Date/Time.
  • The back‐out steps must be completed within the requested change window itself; the planned end time of the change should account not only for the implementation work, but also for the back‐out steps.
  • Validation that the change has been completed successfully should be confirmed through post‐change testing.
  • At the conclusion of a change, the Post Implementation Review (PIR) section of the RFC should be completed;  the PIR is mandatory for the following situations:
    • University/Campus-wide—all risk levels
    • Significant—moderate, high, and very high
    • Department—high and very high
    • Minor—very high
    • Failed Changes
    • Changes that result in a Priority One incident
    • Emergency changes to resolve an incident
    • Urgent changes associated with an incident