Change Management Policy
Process Definition
Change Management seeks to minimize the risk associated with Changes. Preferred practices define a Change as "the addition, modification or removal of anything that could have an effect on University IT services". This includes modification to IT infrastructure, applications, systems, processes, documentation, supplier interfaces, etc.
Scope
Change requests are to be submitted via the ITS Change Management module within Ivanti Service Manager (ISM) by the owner of the change. The change should not be completed until reviewed and approved according to procedures defined within this policy. All sections of the change request should be completed in a thorough manner. The documentation must identify the scope of the change, areas affected, back-out process, testing completed, communication plan and planned date of deployment. This to be done at a level to ensure the scope as described can be accomplished and to provide assurance that the change will have the desired result. Once a change request is submitted it will be known as a change item and is assigned a change number.
Any change item affecting the high security (PCI-DSS) environment should be noted as such with any additional fields/requirements completed appropriately.
Any change item with an impact on PII (Personally Identifiable Information) should be noted as such with any additional fields/requirements completed appropriately.
Purpose of this Policy
- manage changes to the IT infrastructure to enable ITS staff members and clients to plan accordingly
- to reduce the impact of changes on other tasks/projects
- promote communication and collaboration regarding change items
- to share knowledge with the University Help Desk regarding infrastructure modifications
- enable a smooth beginning for each start of semester
- minimize the likelihood of outages
- maintain compliance to applicable regulations
Policy
The following outlines the process for submitting, reviewing, approving, deferring and closing technology change items.
Submittal of a Change Request
Change requests are to be submitted via the ITS Change Management module within Ivanti Service Manager (ISM) by the owner of the change. The change should not be completed until reviewed and approved according to procedures defined within this policy. All sections of the change request should be completed in a thorough manner. The documentation must identify the scope of the change, areas affected, back-out process, testing completed, communication plan and planned date of deployment. This to be done at a level to ensure the scope as described can be accomplished and to provide assurance that the change will have the desired result. Once a change request is submitted it will be known as a change item and is assigned a change number.
Any change item affecting the high security (PCI-DSS) environment should be noted as such with any additional fields/requirements completed appropriately.
Any change item with an impact on PII (Personally Identifiable Information) should be noted as such with any additional fields/requirements completed appropriately.
Review of New Change Items
New change items are reviewed during the change meeting. The leader of the change meeting is to review each pending change item with the group to ensure all attending understand the change and its dependencies. Items that are understood and agreed to by all are motioned for approval. Any incomplete requests will be held or deferred as decided on during the change meeting.
Approval & Deferral of Change Items
Authorization of a change item occurs after the change is reviewed and depends on the priority of the item as described in the table below.
| Type | Authorization | Change Timing / Discussion | Notes |
|---|---|---|---|
| Standard | his type of change is performed on a regular basis and is considered routine. Standard changes are typically created through one of the various change templates available. A user cannot create a standard change in the same fashion as other changes. | These changes bypass the approval process. Chance Manager team manager always has an option of classifying some standard changes as major or emergency, forcing through the approval process | Considered SOP (standard operating procedures) |
| Emergency | This type of change is usually a response to a failure or error that needs an urgent fix. Emergency changes must be made quickly and is usually recorded after the change has already been made. | Approval Required | Emergency |
| Major | This type of change requires a lot of items or dependencies and may require other associated change requests. | Approval Required | Non-Emergency. Similar to Significant but the impact is less |
| Minor | Small changes or changes that have a small or minor affect are classified this way. | Approval Required | Non-Emergency |
| Significan | These changes have a large impact on the organization. Similar to major except that significant changes might need to be divided into several partial subsequent changes that together would constitute a large significant change, depending on the policies and requirements of your organization. | Approval Required | Non-Emergency |
Items that are not approved according to the table above should not be implemented until the review and approval process is followed. Unapproved change items should only remain so for a short period of time (1 or 2 change meetings only). Items that cannot be approved and/or will not be deployed in a reasonable timeframe should be moved to deferred status and reactivated when the change is ready for deployment.
Closing a Change Request
Change items that are previously approved and subsequently deployed are reviewed for closure during the change meeting. The owner of the change (or an informed representative) should be available at the change meeting to discuss the implementation. The review should note the status of the change item execution and any service or infrastructure impacts. If the change has performed as desired it may be closed. In the event a change does not perform as expected or causes issues to one or more areas of the production environment, the attendees of the change meeting will determine if the change should be removed and the production environment returned to its prior stable state. Appropriate action should be noted within the change application and successfully acted upon prior to marking the item closed.
Change Meeting Attendance
To ensure successful review, approval, implementation and closure of change items, each core ITS service area should be represented during the change meeting.
Definitions
Change Management - the process of requesting, developing, approving, and implementing a planned or unplanned change within the ITS infrastructure.
Change Item (or Change Request) - a documented request to modify the ITS infrastructure. This to be completed via the ITS Change Management Application.
ITS Infrastructure - the network, server, storage, database and solutions technologies managed by the Information Technology Services department.
Emergency - Any interruption of in scope systems or services including down systems, service outages and unplanned system restarts. Emergency items must be approved by a Director.
Urgent - Any change that had to be deployed prior to a scheduled change meeting in order to continue University operations and ITS services. Urgent items must be approved by a Director.
Normal - Any requested and scheduled change to in scope systems and services. To be submitted but not implemented prior to change management meetings.
Major & Minor - See definition above. Level determined by components of risk and impact questions in the ticket creation.
The level of authority required to authorize a change is determined by the type of change.
- Emergency
- Urgent
- Normal Major
- Normal Minor
Compliance with Legal and Regulatory Requirements
The University has many federal laws and regulations that it must follow, these include the Family Educational Rights and Privacy Act of 1974 (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA) and the Payment Card Industry (PCI) Data Security Standard (DSS). The process of change management should support these and other applicable University policies found on the Information Technology Services policies website.
Policy Adherence
Failure to follow this policy can result in disciplinary action as provided in the Staff Handbook, Student Worker Employment Guide, and Faculty Handbook. Disciplinary action for not following this policy may include termination, as provided in the applicable handbook or employment guide.
Exceptions
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
Review
This policy, and all policies, standards, handbooks, and supporting materials contained within, will be reviewed by the ISO on an annual basis.
Emergencies
In emergency cases, actions may be taken by the Incident Response Team in accordance with the procedures in the ITS Incident Response Handbook. These actions may include rendering systems inaccessible.
Related Documents
Process documents relating to the meeting execution include Chg Mgmt Process, Chg Mgmt Meeting Chair Duties, Chg Mgmt Meeting Host and Chg Mgmt Meeting Participant.
History
- October 1, 2012: Initial Policy
- September 4, 2014: Reviewed for PCI Compliance
- May 14, 2015: PCI-DSS Review, Added related documents, corrected grammatical errors.
- April 15, 2015: Annual Review for PCI Compliance
- June 5, 2017: Annual Review for PCI Compliance
- June 13, 2018: Added Exceptions, Review and Emergencies, and Annual Review for PCI Compliance
- July 16, 2019: Annual Review for PCI Compliance
- June 29, 2020: Annual Review for PCI Compliance
- June 2021: Annual Review for Audit
- June 2022: Annual Review for PCI Compliance
- June 2023: Annual Review for PCI Compliance
Process Definition
Change Management seeks to minimize the risk associated with Changes. Preferred practices define a Change as "the addition, modification or removal of anything that could have an effect on University IT services". This includes modification to IT infrastructure, applications, systems, processes, documentation, supplier interfaces, etc.
Scope
Change requests are to be submitted via the ITS Change Management module within Ivanti Service Manager (ISM) by the owner of the change. The change should not be completed until reviewed and approved according to procedures defined within this policy. All sections of the change request should be completed in a thorough manner. The documentation must identify the scope of the change, areas affected, back-out process, testing completed, communication plan and planned date of deployment. This to be done at a level to ensure the scope as described can be accomplished and to provide assurance that the change will have the desired result. Once a change request is submitted it will be known as a change item and is assigned a change number.
Any change item affecting the high security (PCI-DSS) environment should be noted as such with any additional fields/requirements completed appropriately.
Any change item with an impact on PII (Personally Identifiable Information) should be noted as such with any additional fields/requirements completed appropriately.
Purpose of this Policy
- manage changes to the IT infrastructure to enable ITS staff members and clients to plan accordingly
- to reduce the impact of changes on other tasks/projects
- promote communication and collaboration regarding change items
- to share knowledge with the University Help Desk regarding infrastructure modifications
- enable a smooth beginning for each start of semester
- minimize the likelihood of outages
- maintain compliance to applicable regulations
Policy
The following outlines the process for submitting, reviewing, approving, deferring and closing technology change items.
Submittal of a Change Request
Change requests are to be submitted via the ITS Change Management module within Ivanti Service Manager (ISM) by the owner of the change. The change should not be completed until reviewed and approved according to procedures defined within this policy. All sections of the change request should be completed in a thorough manner. The documentation must identify the scope of the change, areas affected, back-out process, testing completed, communication plan and planned date of deployment. This to be done at a level to ensure the scope as described can be accomplished and to provide assurance that the change will have the desired result. Once a change request is submitted it will be known as a change item and is assigned a change number.
Any change item affecting the high security (PCI-DSS) environment should be noted as such with any additional fields/requirements completed appropriately.
Any change item with an impact on PII (Personally Identifiable Information) should be noted as such with any additional fields/requirements completed appropriately.
Review of New Change Items
New change items are reviewed during the change meeting. The leader of the change meeting is to review each pending change item with the group to ensure all attending understand the change and its dependencies. Items that are understood and agreed to by all are motioned for approval. Any incomplete requests will be held or deferred as decided on during the change meeting.
Approval & Deferral of Change Items
Authorization of a change item occurs after the change is reviewed and depends on the priority of the item as described in the table below.
| Type | Authorization | Change Timing / Discussion | Notes |
|---|---|---|---|
| Standard | his type of change is performed on a regular basis and is considered routine. Standard changes are typically created through one of the various change templates available. A user cannot create a standard change in the same fashion as other changes. | These changes bypass the approval process. Chance Manager team manager always has an option of classifying some standard changes as major or emergency, forcing through the approval process | Considered SOP (standard operating procedures) |
| Emergency | This type of change is usually a response to a failure or error that needs an urgent fix. Emergency changes must be made quickly and is usually recorded after the change has already been made. | Approval Required | Emergency |
| Major | This type of change requires a lot of items or dependencies and may require other associated change requests. | Approval Required | Non-Emergency. Similar to Significant but the impact is less |
| Minor | Small changes or changes that have a small or minor affect are classified this way. | Approval Required | Non-Emergency |
| Significan | These changes have a large impact on the organization. Similar to major except that significant changes might need to be divided into several partial subsequent changes that together would constitute a large significant change, depending on the policies and requirements of your organization. | Approval Required | Non-Emergency |
Items that are not approved according to the table above should not be implemented until the review and approval process is followed. Unapproved change items should only remain so for a short period of time (1 or 2 change meetings only). Items that cannot be approved and/or will not be deployed in a reasonable timeframe should be moved to deferred status and reactivated when the change is ready for deployment.
Closing a Change Request
Change items that are previously approved and subsequently deployed are reviewed for closure during the change meeting. The owner of the change (or an informed representative) should be available at the change meeting to discuss the implementation. The review should note the status of the change item execution and any service or infrastructure impacts. If the change has performed as desired it may be closed. In the event a change does not perform as expected or causes issues to one or more areas of the production environment, the attendees of the change meeting will determine if the change should be removed and the production environment returned to its prior stable state. Appropriate action should be noted within the change application and successfully acted upon prior to marking the item closed.
Change Meeting Attendance
To ensure successful review, approval, implementation and closure of change items, each core ITS service area should be represented during the change meeting.
Definitions
Change Management - the process of requesting, developing, approving, and implementing a planned or unplanned change within the ITS infrastructure.
Change Item (or Change Request) - a documented request to modify the ITS infrastructure. This to be completed via the ITS Change Management Application.
ITS Infrastructure - the network, server, storage, database and solutions technologies managed by the Information Technology Services department.
Emergency - Any interruption of in scope systems or services including down systems, service outages and unplanned system restarts. Emergency items must be approved by a Director.
Urgent - Any change that had to be deployed prior to a scheduled change meeting in order to continue University operations and ITS services. Urgent items must be approved by a Director.
Normal - Any requested and scheduled change to in scope systems and services. To be submitted but not implemented prior to change management meetings.
Major & Minor - See definition above. Level determined by components of risk and impact questions in the ticket creation.
The level of authority required to authorize a change is determined by the type of change.
- Emergency
- Urgent
- Normal Major
- Normal Minor
Compliance with Legal and Regulatory Requirements
The University has many federal laws and regulations that it must follow, these include the Family Educational Rights and Privacy Act of 1974 (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA) and the Payment Card Industry (PCI) Data Security Standard (DSS). The process of change management should support these and other applicable University policies found on the Information Technology Services policies website.
Policy Adherence
Failure to follow this policy can result in disciplinary action as provided in the Staff Handbook, Student Worker Employment Guide, and Faculty Handbook. Disciplinary action for not following this policy may include termination, as provided in the applicable handbook or employment guide.
Exceptions
Exceptions to this policy will be handled in accordance with the ITS Security Policy.
Review
This policy, and all policies, standards, handbooks, and supporting materials contained within, will be reviewed by the ISO on an annual basis.
Emergencies
In emergency cases, actions may be taken by the Incident Response Team in accordance with the procedures in the ITS Incident Response Handbook. These actions may include rendering systems inaccessible.
Related Documents
Process documents relating to the meeting execution include Chg Mgmt Process, Chg Mgmt Meeting Chair Duties, Chg Mgmt Meeting Host and Chg Mgmt Meeting Participant.
History
- October 1, 2012: Initial Policy
- September 4, 2014: Reviewed for PCI Compliance
- May 14, 2015: PCI-DSS Review, Added related documents, corrected grammatical errors.
- April 15, 2015: Annual Review for PCI Compliance
- June 5, 2017: Annual Review for PCI Compliance
- June 13, 2018: Added Exceptions, Review and Emergencies, and Annual Review for PCI Compliance
- July 16, 2019: Annual Review for PCI Compliance
- June 29, 2020: Annual Review for PCI Compliance
- June 2021: Annual Review for Audit
- June 2022: Annual Review for PCI Compliance
- June 2023: Annual Review for PCI Compliance