Skip to Content

IT/PPS 01.05 - Information Technology - Change Management Policy

Information Technology - Change Management Policy

IT/PPS No. 01.05
Issue No. 01
Effective Date: 4/28/2020
Next Review Date: 3/01/2021 (EY)
Sr. Reviewer: Associate Vice President for Technology Resources

  1. POLICY STATEMENTS

    1. Information Technology (IT) change management is the process of planning, testing, coordinating, and implementing changes to the production environment. The goal of change management is to minimize the risks involved in introducing change to the production environment, thereby maximizing the availability of services to the customer.

    2. The purposes of the change management process are to reduce unplanned service outages, communicate system changes to IT departments, and provide a documented and efficient process for IT staff to follow.

  2. DEFINITIONS

    1. Change Advisory Board (CAB) – a group of IT staff who vote to approve or deny requests.

    2. Team CAB – assigned to each technical team and who will vote to approve or deny the team’s normal change requests before work in test.

    3. IT CAB – contains representatives from the IT organization to ensure a high level of visibility and who will vote to approve or deny release requests and master standards.

    4. Change – action to modify the state of a production application or environment.

    5. Change Request – a request made when a change is needed. This request is the starting point for all changes.

    6. Normal Change Request – the default change request type. These change requests must be approved by a team CAB before work can begin in a test environment.

    7. Standard Change Request – a change request referencing an approved master standard.

    8. Master Standard – a description of a routine, low-risk change carried out by a team. Once approved, these changes are available for selection in standard change requests.

    9. Expedited Change Requests – a request for a change that is time-sensitive and may have been carried out previously to prevent interruption of a service, corruption of data, or exposure of a critical bug.

    10. Change Management (CM) System – an application built to allow IT professionals to acquire approval to make changes, track the changes, and create an audit trail.

    11. Creator or Requestor – the individual who originates a request in the CM.

    12. Customer Request – a document (usually a PDF) representing the request made by the customer.

    13. Customer Signoff – a document (usually a PDF) representing the customers’ affirmation that they have tested the change in a test environment or otherwise assent that it meets the need expressed in the original request.

    14. Production Environment (PROD) – the setting where software and other products are put into operation for their intended uses by end-users.

    15. Release – the act of carrying out a change in a PROD.

    16. Release Request – a request to make a release into production.

    17. Test Environment (Test or Qual or Dev) – an environment used for testing before migration to production.

    18. Vote – an individual response by a CAB member to a request.

  3. PROCEDURES FOR NORMAL CHANGE

    1. The creator or requestor submits change request via the CM and attaches the customer request if the change involves a customer.

    2. Submitting the change request automatically triggers the change to the status of ‘review,’ where voting will take place by the team CAB.

    3. The creator or requestor is notified once all team CAB approvals are obtained.

    4. Once all team CAB approvals are obtained, the change will be moved to a status of ‘approved,’ then changes in the test environment can officially occur.

    5. Once testing is complete, the creator or requestor will create a release request for that specific change.

      1. If a customer is involved, customer sign-off must be attached to the release request.

      2. Multiple release requests may be created under one change request.

    6. Submitting the release request automatically triggers the release to the status of ‘review,’ where voting will take place by the IT CAB.

    7. Once all IT CAB approvals are obtained, the creator or requestor is notified and the change can be migrated to the PROD.

    8. Once the work has been migrated to the PROD, the release report will be completed.

    9. When the release is closed, the creator or requestor will have the option to close the change request or leave open for additional releases.

  4. PROCEDURES FOR STANDARD CHANGES

    1. Standard changes are created by selecting a preapproved master standard.

    2. Submitting a standard change request automatically triggers the change to the status of ‘approved.’

    3. Once testing is complete, the creator or requestor will create a release request for that specific change.

    4. Submitting the release request will automatically trigger the release to the status of ‘approved.’

    5. Once the work has been migrated to the PROD, the release report will be completed.

  5. PROCEDURES FOR EXPEDITED CHANGE

    In the event a required automatic control fails and a temporary mitigating control must be put in place, the Mitigating Control Procedure Checklist must be completed prior to expediting the change.

    1. The creator or requestor submits an expedited request via the CM.

      1. Expedited changes may be implemented in the PROD prior to submitting a change request

      2. Customer requests or sign-offs are still required for an expedited change request if a customer is involved.

    2. Submitting an expedited change request automatically triggers the change to the status of ‘approved.’

    3. Once testing is complete, the creator or requestor will submit a release request for that specific change.

    4. Submitting the release request automatically triggers the release to the status of ‘approved.’

    5. Once the work has been migrated to the PROD, the release report will be completed.

  6. PROCEDURES FOR PRODUCTION-ONLY CHANGE

    It is possible to have a production-only change for all change types (normal, standard, and expedited). If a normal change can only be made in a PROD, this will be notated on the change request, and the request will skip team CAB approvals and go straight to IT CAB approvals for the PROD.

    1. The creator or requestor submits a change request via the Change Management System and designates the change as PROD-only.

    2. Submitting a change request that is designated as PROD-only will automatically trigger the creator or requestor to create a release request for that specific change.

    3. Submitting the release request automatically triggers the release to the status of ‘review,’ where voting will take place by the IT CAB.

    4. The creator or requestor is notified once all IT CAB approvals are obtained.

    5. Once all IT CAB approvals are obtained, the release will automatically go to a status of ‘approved’ and can be migrated to the PROD.

    6. Once the work has been migrated to the PROD, the release report will be completed.

  7. CHANGE MANAGEMENT SYSTEM DATA LIFE CYCLE

    1. Data related to completed change requests, and their associated releases, will be retained for one year from the closure date of the change.
  8. REVIEWERS OF THIS PPS

    1. Reviewers of this PPS include the following:

      Position Date
      Associate Vice President for Technology Resources March 1 EY
      Chief Information Security Officer March 1 EY
      Vice President for Information Technology March 1 EY
  9. CERTIFICATION STATEMENT

    This PPS has been reviewed by the following individuals in their official capacities and represents Texas State Information Technology policy and procedure from the date of this document until superseded.

    Associate Vice President for Technology Resources, senior reviewer of this PPS

    Vice President for Information Technology