Loyola University Chicago

- Navigation -

Loyola University Chicago

Information Technology Services

Change Management Policy


This policy applies to all technology changes which may be deployed or applied to production environment of the Loyola University Chicago technology network, server, storage, database or solutions architecture. 

All ITS staff members, consultants or agents of Loyola University Chicago and any parties who are contractually bound through ITS to build or supports its technology architecture are required to abide by this policy.

Out of scope items include operational or systems administrative duties as defined by the ITS service owner. Significant changes to development or QA environments are encouraged to be in scope but not required.


The purpose of this policy is to:


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 Application 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 environment 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.



Change Timing/Discussion

Non- Emergency

As defined by the ITS team requesting/owning the change (i.e. Group Leader, Project Manager, Manager, etc.)

Change occurs after consensus approval from the change meeting


Received from an ITS Director prior to the change being made

Change occurs prior to the change meeting discussion


None, ITS Director is communicated with after (or as) the change is being made

Change occurs prior to the change meeting discussion

* Changes affecting the high security environment require an ITS Director and Information Security approval regardless of the type of change indicated.

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.


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.

Non-Emergency Change - a change of regular priority where review of the change request is made during the change meeting and the approval is received prior to the change being made.

Urgent Change - a change of escalated priority where review and approval of the change is received from an ITS Director prior to the change being made and is subsequently reviewed, communicated and closed during the next scheduled change meeting.

Emergency Change - a change of immediate priority where ITS personnel is required to execute a change without any review or approval.  This is normally in a service outage, system down or in an urgent outage prevention situation.  The subsequent change is to be reviewed, communicated and closed during the next scheduled change meeting.

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.

Related Documents:

No related documents.


October 1, 2012: Initial Policy

September 4, 2014: Reviewed for PCI Compliance 


Listing of Cloud Services

This listing is meant to serve only as a partial list of cloud services.


Services Approved

for University Use

Services Not Approved

for University Use

Box – Using UVID only





Amazon Cloud Drive


Google Drive


Microsoft OneDrive

Individuals who use enterprise Box accounts for university work are responsible for ensuring that Loyola Sensitive information is not placed or stored in unapproved or inappropriate locations. When using Box for institutional information, use it only for institutional information classified as Loyola Public or Loyola Sensitive. Pay special attention to access levels when sharing files and folders with other collaborators to ensure that data is not inappropriately shared.  You should not use your enterprise Box account to collect, process, or store data covered by laws such as HIPAA, FERPA, FISMA, and GLBA.

Contractual Expectations

The University will seek and endorse vendors who deliver solutions that meet the following requirements.

Both the University and cloud-computing vendor must declare the type of data that they might transfer back and forth because of their relationship. A contract must have clear terms that define the data owned by each party. The parties also must clearly define data that must be protected.

The contract must specifically state what data the University owns. It must also classify the type of data shared in the contract according to the University’s classification schema: Public, Sensitive, or Protected. Departments must exercise caution when sharing University-classified sensitive or protected data within a cloud computing service.

The contract must specify how the cloud-computing vendor can use University data. Vendors cannot use University data in any way that violates the law or University policies.


This policy is a production of individual thought and a collaboration of multiple public works including portions of policies and guidelines from: Western Michigan University, EDUCAUSE, and Internet2 Consortium.

Questions about this policy:

If you have questions about this policy, please contact the University Information Security Office at DataSecurity@luc.edu.


August 31, 2012: Initial Policy Created
September 13, 2012: Policy Approved
July 7, 2013: Annual review for PCI Compliance
June 4, 2014: Annual review for PCI Compliance



Information Technology Services
1032 W. Sheridan Ave. · Chicago, IL 60660 · 773.508-4ITS


Notice of Non-discriminatory Policy