IT Policies and Procedures

Purpose

The purpose of this Guideline is to establish a framework for classifying institutional data based on its level of sensitivity, value and criticality to the University as required by the University’s Information Security Policy. Classification of data will aid in determining baseline security controls for the protection of data.

Applies To

This Policy applies to all faculty, staff and third-party Agents of the University as well as any other University affiliate who is authorized to access Institutional Data. In particular, this Guideline applies to those who are responsible for classifying and protecting Institutional Data.

Definitions

Confidential Data is a generalized term that typically represents data classified as Restricted, according to the data classification scheme defined in this Guideline. This term is often used interchangeably with sensitive data.

A Data Steward is a senior-level employee of the Seminary who oversees the lifecycle of one or more sets of Institutional Data.

Institutional Data is defined as all data owned or licensed by the University.

Non-public Information is defined as any information that is classified as Private or Restricted Information according to the data classification scheme defined in this Guideline.

Sensitive Data is a generalized term that typically represents data classified as Restricted, according to the data classification scheme defined in this Guideline. This term is often used interchangeably with confidential data.

Data Classification

Data classification, in the context of information security, is the classification of data based on its level of sensitivity and the impact to the Seminary should that data be disclosed, altered or destroyed without authorization. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data. All institutional data should be classified into one of three sensitivity levels, or classifications:

A.	Restricted Data
	Data should be classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a significant level of risk to the University or its affiliates. Examples of Restricted data include data protected by state or federal privacy regulations and data protected by confidentiality agreements. The highest level of security controls should be applied to Restricted data.
B.	Private Data
	Data should be classified as Private when the unauthorized disclosure, alteration or destruction of that data could result in a moderate level of risk to the University or its affiliates. By default, all Institutional Data that is not explicitly classified as Restricted or Public data should be treated as Private data.  A reasonable level of security controls should be applied to Private data.
C.	Public Data
	Data should be classified as Public when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to the University and its affiliates. Examples of Public data include press releases, course information and research publications. While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent unauthorized modification or destruction of Public data.

 

Classification of data should be performed by an appropriate Data Steward. Data Stewards are senior-level employees of the Seminary who oversee the lifecycle of one or more sets of Institutional Data. See Information Security Roles and Responsibilities for more information on the Data Steward role and associated responsibilities.

Data Collections

Data Stewards may wish to assign a single classification to a collection of data that is common in purpose or function. When classifying a collection of data, the most restrictive classification of any of the individual data elements should be used. For example, if a data collection consists of a student’s name, address and social security number, the data collection should be classified as Restricted even though the student’s name and address may be considered Public information.

Reclassification

On a periodic basis, it is important to reevaluate the classification of Institutional Data to ensure the assigned classification is still appropriate based on changes to legal and contractual obligations as well as changes in the use of the data or its value to the University. This evaluation should be conducted by the appropriate Data Steward. Conducting an evaluation on an annual basis is encouraged; however, the Data Steward should determine what frequency is most appropriate based on available resources. If a Data Steward determines that the classification of a certain data set has changed, an analysis of security controls should be performed to determine whether existing controls are consistent with the new classification. If gaps are found in existing security controls, they should be corrected in a timely manner, commensurate with the level of risk presented by the gaps.

Calculating Classification

The goal of information security is to protect the confidentiality, integrity and availability of Institutional Data. Data classification reflects the level of impact to the University if confidentiality, integrity or availability is compromised.

There is no perfect quantitative system for calculating the classification of a particular data element. In some situations, the appropriate classification may be more obvious, such as when federal laws require the University to protect certain types of data (e.g. personally identifiable information). If the appropriate classification is not inherently obvious, consider the security objective as it pertains to each data set.

Policy Statement

Computers and other information technology resources are essential tools in accomplishing the Union Theological Seminary’s mission. Information technology resources are valuable assets to be used and managed responsibly to ensure their integrity, confidentiality, and availability for appropriate research, education, outreach and administrative objectives of the institution. Community members are granted access to these resources in support of accomplishing the stated mission.

All users of information technology resources, whether or not affiliated with the Seminary, are responsible for their appropriate use, and by their use, agree to comply with all applicable Seminary policies; federal, state and local laws; and contractual obligations. These include but are not limited to information security, data privacy, commercial use, and those that prohibit harassment, theft, copyright and licensing infringement, and unlawful intrusion and unethical conduct.

Union Theological Seminary accepts no responsibility or liability for any personal or unauthorized use of its resources by users.

Acceptable Use

Acceptable use includes, but is not limited to, respecting the rights of other users, avoiding actions that jeopardize the integrity and security of information technology resources, and complying with all pertinent licensing and legal requirements.  Users with access to Union Theological Seminary’s information technology resources must agree to and accept the following:

• Only use information technology resources they are authorized to use and only in the manner and to the extent authorized. Ability to access information technology resources does not, by itself, imply authorization to do so.
• Only use accounts, passwords, and/or authentication credentials that they have been authorized to use for their role at the Seminary.
• Protect their assigned accounts and authentication (e.g., password, and/or authentication credentials) from unauthorized use.
• Only share data with others as allowed by applicable policies and procedures, and dependent on their assigned role.
• Comply with the security controls on all information technology resources used for school business, including but not limited to mobile and computing devices, whether seminary or personally owned.
• Comply with licensing and contractual agreements related to information technology resources.
• Comply with intellectual property rights (e.g., as reflected in licenses and copyrights).
• Accept responsibility for the content of their personal communications and may be subject to any personal liability resulting from that use.

Unacceptable Use

Unacceptable use includes and is not limited to the following list.  Users are not permitted to

• Share authentication details or provide access to their seminary accounts with anyone else (e.g., sharing the password).
• Circumvent, attempt to circumvent, or assist another in circumventing the security controls in place to protect information technology resources and data.
• Knowingly download or install software onto seminary’s information technology resources, or use software applications, which do not meet University security requirement, or may interfere or disrupt service, or do not have a clear business or academic use.
• Engage in activities that interfere with or disrupt users, equipment or service; intentionally distribute viruses or other malicious code; or install software, applications, or hardware that permits unauthorized access to information technology resources.
• Access information technology resources for which authorization may be erroneous or inadvertent.
• Conduct unauthorized scanning of information technology resources.
• Engage in inappropriate use, including but not limited to:
  • Activities that violate state or federal laws, regulations, or University policies.
  • Harassment
  • Widespread dissemination of unsolicited and unauthorized electronic communications.
• Engage in excessive use of system information technology, including but not limited to network capacity. Excessive use means use that is disproportionate to that of other users, or is unrelated to academic or employment-related needs, or that interferes with other authorized uses. Units may require users to limit or refrain from certain activities in accordance with this provision.

Privacy and Security Measures

Users must not violate the privacy of other users. Technical ability to access others’ accounts does not, by itself, imply authorization to do so.

Users play an important role in the protection of their personal information. All faculty, staff and students are required to use all available user specific security controls provided by the Seminary as available (including multi-/two-factor authentication) and meet the user specific controls in Administrative Policy: to assist in the protection of assets and the protection of their personal information and assets. Failure on the part of faculty, staff or students to employ in good faith the available security controls and to secure their personal information appropriately will mean that the seminary will not reimburse the faculty, staff or student for the loss of misdirected salary, expense reimbursements, financial aid or any other assets.

Employees must understand that any records and communications they create related to seminary business, electronic or otherwise, on an assigned or personally owned device, may be subject to disclosure under New York State’s Data Practices laws.

The Seminary takes reasonable measures to protect the privacy of its information technology resources and accounts assigned to individuals. However, the University does not guarantee absolute security and privacy. Users should be aware that any activity on information technology resources may be monitored, logged and reviewed by Seminary-approved personnel or may be discovered in legal proceedings. The Seminary assigns responsibility for protecting its resources and data to technical staff, data owners, and data custodians, who treat the contents of individual assigned accounts and personal communications as private and do not examine or disclose the content except:

• as required for system maintenance including security measures;
• when there exists reason to believe an individual is violating the law or Seminary policy; and/or
• as permitted by applicable policy or law.

The Seminary reserves the right to employ security measures. When it becomes aware of violations, either through routine system administration activities or from a complaint, it is the Seminary’s responsibility to investigate as needed or directed, and to take necessary actions to protect its resources and/or to provide information relevant to an investigation.

Enforcement

Individuals who use information technology resources that violate a Seminary policy, law(s), regulations, contractual agreement(s), or violate an individual’s rights, may be subject to limitation or termination of user privileges and appropriate disciplinary action, legal action, or both. Alleged violations will be referred to the appropriate office or law enforcement agency.

The Seminary may temporarily deny access to information technology resources if it appears necessary to protect the integrity, security, or continued operation of these resources or to protect itself from liability.

Individuals or units should report non-compliance with this policy to a member of the senior staff in the organization.

Exceptions

Departments within the Seminary may define additional conditions of use for information technology resources or facilities under their control. Such additional conditions must be consistent with or at least as restrictive as any governing Board or Administrative policy, and may contain additional details or guidelines.

November 2020

Union Theological Seminary is required by the Gramm-Leach-Bliley Act (“GLBA”) and its implementing regulations at 16 CFR Part 314, to implement and maintain a comprehensive written Information Security Program (“ISP”) and to appoint a coordinator for the program. The objectives of the ISP are to (1) insure the security and confidentiality of covered information; (2) protect against anticipated threats or hazards to the security and integrity of such information; and (3) protect against unauthorized access or use of such information that could result in substantial harm or inconvenience to customers.

Related Policies

This ISP is in addition to existing Union Theological Seminary policies and procedures that address various aspects of information privacy and security, including but not limited to, the Student Privacy Rights Policy (Family Educational Rights and Privacy Act Policy), the Information Security Policy, and the Computing Policy.

ISP Coordinator

Union Theological Seminary has designated the Director of Information Technology as its ISP Coordinator. The ISP Coordinator may designate other individuals to oversee and/or coordinate particular elements of the ISP.

Covered Information

“Covered information” means nonpublic personal information about a student or other third party who has a continuing relationship with UTS, where such information is obtained in connection with the provision of a financial service or product by UTS, and that is maintained by UTS or on UTS’s behalf. Nonpublic personal information includes students’ names, addresses and social security numbers as well as students’ and parents’ financial information. Covered information does not include records obtained in connection with single or isolated financial transactions such as ATM transactions or credit card purchases.

Elements of the ISP

1. Risk Identification and Assessment.UTS’s ISP identifies and assesses external and internal risks to the security, confidentiality, and integrity of covered information that could result in the unauthorized disclosure, misuse, alteration, destruction or other compromise of such information. The ISP Coordinator will provide guidance to appropriate personnel in the central administration, academic units, and other university units in evaluating their current practices and procedures and in assessing reasonably anticipated risks to covered information in their respective areas. The ISP Coordinator will work with appropriate personnel to establish procedures for identifying and assessing risks in the following areas:

• Employee Training and Management. The ISP Coordinator will coordinate with the appropriate personnel to evaluate the effectiveness of current employee training and management procedures relating to the access and use of covered information.
• Information Systems.The ISP Coordinator will coordinate with the appropriate personnel to assess the risks to covered information associated with the university’s information systems, including network and software design as well as information processing, storage, transmission and disposal.
• Detecting, Preventing and Responding to Attacksand System Failures The ISP Coordinator will coordinate with the appropriate personnel or consulting group to evaluate procedures for and methods of detecting, preventing and responding to attacks, intrusions or other system failures.

2. Designing and Implementing Safeguards.  The ISP Coordinator will coordinate with appropriate personnel to design and implement safeguards, as needed, to control the risks identified in assessments and will develop a plan to regularly test or otherwise monitor the effectiveness of such safeguards. Such testing and monitoring may be accomplished through existing network monitoring and problem escalation procedures.
3. Overseeing Service Providers. The ISP Coordinator, in conjunction with Vice President for Finance and Operations, and appropriate contractors, will assist in instituting methods for selecting and retaining service providers that are capable of maintaining appropriate safeguards for covered information. These standards will apply to all existing and future contracts entered into with service providers to the extent required under GLBA.
4. Adjustments to Program.The ISP Coordinator will evaluate and adjust the ISP as needed, based on the risk identification and assessment activities undertaken pursuant to the ISP, as well as any material changes to UTS’s operations or other circumstances that may have a material impact on the ISP.

 

Any suspected or confirmed breach or compromise of Sensitive Data must be reported to the departments set forth in Section D below in a timely manner in order to mitigate the risk to Information Resources and protect the University’s operations.

Upon receipt of such report, the Chief Information Officer, the Chief Operating Officer, Senior Staff and the General Counsel or his or her delegate will convene to determine response message and mitigation strategy.

The following lists the general responsibilities of this group:

• The Information Technology Office will be responsible for serving as Incident Lead for any actual or suspected compromise of Sensitive Data (other than PHI).
• The assigned Data Stewards will be responsible for serving as Incident Lead for any actual or suspected compromise of PHI.
• The General Counsel is responsible for all legal issues associated with an actual or suspected compromise of Sensitive Data.
• The Director of Security is responsible for all contacts with law enforcement and for non-technical aspects of any investigation.
• The Communications Office is responsible for all internal and external communications and media relations.
• Human Resources will advise on personnel issues and communications to University staff.

The affected Seminary department(s) will provide the support required to investigate and respond to the actual or suspected compromise of Sensitive Data.

Each Department will establish detailed internal procedures for compliance, external and internal communications, oversight of the investigation and technical support associated with a suspected or actual breach of Sensitive Data.

The specific incident response procedures are set forth in the applicable Information Security and Privacy Incident Procedure and Checklist.

The general steps in a response include the following:

1. Incident Categorization
   Incidents will be categorized based on the applicable UTS Information Technology Office’s internal procedures. Based on the severity of the incident, an appropriate response action will be taken.
2. Response and Recovery
   The assigned incident response team may call upon any necessary additional offices and resources required to carry out the investigation and remediation of any breach. This expanded team will be responsible for the investigation of the incident and any technical support required. Incident team members will include representatives of affected Data Owners and any other units responsible for the Information Resources involved.
   Any individual responsible for an Information Resource containing Sensitive Data that may have been compromised must take immediate steps to secure that system and preserve it without change.
3. Lessons Learned
   After an incident has been resolved, an incident report will be created and distributed to the Seminary’s Senior Staff. The Chief Information Officer will then convene to discuss the security controls that failed and establish the steps necessary to prevent or limit the risk of the incident recurring.

To report a possible breach of PHI or to report a possible breach of Sensitive Data at UTS:

UTS Information Technology Office
Email: helpdesk@utsnyc.edu
Telephone: 212-280-1460

Each Department Manager is required to perform a Business Risk Assessment and Business Impact Analysis for each Key Business System that is used in his/her area of responsibility. The assessment should identify and define the criticality of Key Business Systems and the repositories that contain the relevant and necessary Seminary Data for the Department. The assessment should also define and document the Disaster Contingency and Recovery Plan (the “Contingency Plan”) for his/her area of responsibility. Such Plan shall include the following:

• Key business processes;
• Applicable risk to availability;
• Prioritization of recovery;
• Recovery Time Objectives; and
• Recovery Point Objectives.

For purposes of this Policy, a “Recovery Time Objective” is the duration of time and a service level within which a business process must be restored after a disaster or disruption in order to avoid unacceptable consequences associated with a break in business continuity and a “Recovery Point Objective” is the maximum tolerable period during which Data might be lost from an Information Resource.

Each Key Business System must have a Contingency Plan documented for when hardware, software or Networks become critically dysfunctional or cease to function (short term and long term outages). This Plan should include an explanation of the magnitude of information or System unavailability in the event of an outage and the process that would be implemented to continue operations during the outage. In addition, the feasibility of utilizing alternative off-site computer operations should be addressed.

Specifically, the Contingency Plan must include:

1. An Emergency Mode Operations Plan for continuing operations in the event of temporary hardware, software or Network outage. This Plan should contain information relating to the end user process for continuing operations.
2. A Recovery Plan for returning functions and services to normal on-site operations when a disaster is over.
3. A procedure for periodic testing, review and revision of the Contingency Plan for all affected Systems, as a group and individually as needed.

Each System Owner and IT Custodian will implement a Data Backup Plan or document the decision to forgo a Plan with a risk-based analysis. Such Plan should define the following:

1. Who is responsible for taking reasonable steps to ensure the backup of University Data, particularly Sensitive Data and Confidential Data;
2. A backup schedule;
3. The Key Business Systems that are to be backed up;
4. Where backup media is to be stored and workforce members who may access the stored backup media;
5. Where backup media is to be kept secure before it is moved to storage, if applicable;
6. Who may remove the backup media and transfer it to storage;
7. Restoration procedures to restore Key Business System Data from backup media to the appropriate System;
8. Test restoration procedures and frequency of testing to confirm the effectiveness of the Plan;
9. The retention period for backup media; and
10. A method for restoring encrypted backup media, including encryption key management.

The following Systems must be registered with the Union Theological Seminary’s Information Technology Department. If there are access control ramifications connected to the technology then the Security Office must be informed.

• Any System that processes, transmits and/or stores PHI, regardless of location;
• Any System that processes, transmits and/or stores Seminary Data whose Data Owner or any related Executive Manager, Security Manager, System Owner, IT Custodian or IT Group
• Any System physically located in the Union Theological Seminary Data Center.

Registration will be carried out in accordance with the procedures established by each such Office.

Each System is subject to risk assessment by the Seminary’s Information Technology Office, remediation, if necessary by the System Owner and certification by such IT Office in accordance with procedures established by the Seminary. Each certified System shall be recertified on a periodic basis, as determined by the level of risk, by the applicable Information Security Office.

1. Each System Owner will ensure that the following protections, at a minimum, are implemented for each System:
   An IT Custodian has been appointed for the System by the Chief Information Officer of the organization, as applicable.
2. The facility that houses the System’s Servers, including primary and backup equipment, is environmentally controlled and physically secured from unauthorized access.
3. Each Server is physically identifiable.
4. All Seminary Data files on a Server are backed up and adhere to all Disaster Recovery and Business Continuity standards agreed to by Union Theological Seminary Chief Operation Officer and Senior Staff
5. Each of the System’s production Servers has a UPS that can provide emergency power and shut the Server down in case of a power outage.
6. Standard configurations, as defined by the Chief Information Officer. Access to the System’s Servers and the Seminary Data residing on the System is restricted and is maintained in accordance with agreed upon access control standards.
7. The System’s Servers are not used for general desktop functions, such as web browsing, conducting personal email or other Union business or non-business functions.
8. The System’s Servers are running vendor-supported operating systems and have up-to- date security patches installed.
9. The System’s Servers are accessible only for the services provided and only to as much of the Network as is required to provide such services, and firewalls or equivalent protections prevent unauthorized access. To the extent practicable, anti-virus, anti-spyware and System monitoring programs are installed to protect and/or prohibit unauthorized access.
10. Any Peer-to-Peer Program is used only for Seminary purposes, is configured properly as directed by the applicable Information Security Office and does not permit general purpose file sharing over the Internet.
11. Only required services that run on the System’s Servers are enabled. Unneeded services are disabled.

Each System Owner shall ensure that, in addition to the protections described in Section C above, the following protections are implemented for each System that processes, transmits and/or stores Sensitive Data:

1. A record is kept of what type of Sensitive Data are stored on the System’s Servers and of all changes to the configuration of the Server, and such documentation is kept in a secure, locked location away from the Server.
2. In web-based Systems that are exposed to the Internet, protection mechanisms are implemented to prevent common web-based attacks. Examples of protection elements include web-based firewalls and/or source code security reviews. All such Systems are protected according to the security standards set by the organization.
3. Sensitive Data are encrypted while in transit.
4. Removable Media containing Sensitive Data are encrypted.
5. In Relational Database Management Systems, Sensitive Data are encrypted in a way that permits database administrators to perform their management functions without access to such Data in a readable format.
6. The System’s Servers are maintained in appropriate Data centers, Server closets or Data closets that meet or exceed the following physical requirements:
   1. Video camera surveillance;
   2. Badge reader (rather than key) access;
   3. Use of a visitor log to document all visitors who accompany an authorized User, which is posted by the main ingress/egress point of the secure facility;
   4. Alarms on the door that alert University Public Safety if (x) the door is left ajar, (y) the door is forced open or (z) the security lock malfunctions; and
   5. An emergency power shut off button that can cut off power to all circuits in the case of a fire or other physical threat.

It is recommended, but not required, that Confidential Data be protected with a password while in transit or in storage.

Each System must follow the specific procedures relating to Systems in accordance with the Seminary’s policies.

Each email System Owner shall ensure that, in addition to the protections described in Section C and, if applicable, Sections D and E above, the following protections are implemented for such System:

1. Virus, spam and phishing protection for inbound and outbound messages is implemented through the use of mail filtering software that includes features such as content analysis and real time blacklists.
2. SMTP relay is performed only for authenticated Users or Systems.
3. Monitoring to detect compromised email accounts is implemented and such accounts are disabled on a timely basis.
4. Data loss prevention is implemented to ensure that unencrypted Sensitive Data is not released.
5. Detection or prevention mechanisms are implemented to monitor the use of automatic forwarding, redirection or other automated delivery of email as required by the Seminary’s policies.

Each System Owner shall ensure that, in addition to the protections described in Sections C and, if applicable, D, E and F above, the following protections are implemented for such System:

1. All local IT support groups comply with the requirements of the Merchant Security Review Form referred to in the Credit Card Policy prior to the implementation of or changes to any credit card related services in the merchant environment.
2. All merchant environments are approved by Union’s technical team and security vendors.

Any System Owner may request that a System that contains Sensitive Data, but cannot use encryption because of technology or business limitations be granted a waiver of the provisions of this Policy by the applicable Information Security Office. Such a waiver may only be granted if such Office determines that there are compensating controls in place to address all major information security risks.

The requirements lists set forth in this Policy are not comprehensive and supplemental controls may be required by the Seminary to enhance security as necessary.

This Procedure established measures that must be taken by the Senior Staff and Chief Operation Office as response to a possible breach or compromise of Sensitive Data in order to comply with all applicable federal and state laws and regulations.

The Chief Operating Officers is responsible for initiating the Electronic Data Security Breach Procedure. The Union Theological Seminary IT Department is responsible for determining the extent of a confirmed breach.

The following procedures will be followed when a breach of Sensitive Data is suspected or known to occur:

1. Report
   Any suspected or confirmed compromise of Sensitive Data must be reported to Union Theological Seminary Information Technology Department helpdesk@utsnyc.edu> as soon as possible – include the keyword “[Data Security Breach]” in the subject of the email. This will automatically open a ticket with the support team that will be used to document and track the response to the incident.
2. Breach Confirmed – Report to Chief Operating Officer & Security Office
   If a breach is confirmed, UTS IT Department will report the breach to the Chief Operating Officer, who will report the breach to the appropriate Senior Staff, Legal Counsel, and Vendors to mitigate the risk to the Seminary’s Information Resources and protect the operations.
3. Isolate System
   The compromised system must be isolated from the UTS network as soon as possible and preserved in its current state. Systems affected by potential ransomware attacks should also isolate their backup systems and secure any uncompromised backups available.
   4. Secure Logs
   Administrator for the system should attempt to secure logs whenever possible to aid in the investigation.
4. Incident Categorization
   The incident will be categorized based on the duration of the breach, the type of data that was affected and the potential to breach other systems in the UTS network and external networks. Categories include:
   1. Vulnerability on a system with Sensitive Data detected
   2. Inadequate security for Sensitive Data detected
   3. Unauthorized access to Sensitive Data detected internal to UTS network
   4. Unauthorized access to Sensitive Data detected external toUTS network
   5. Breached system used to breach other systems on UTS network
   6. Breached system used to breach other systems external to UTS network
5. Damage Assessment
   Union Theological Seminary’s IT Department will determine the extent of any data security breach. UTS IT may contact any additional offices and resources required to classify the incident and determine the extent of the breach.
6. Recovery
   The affected system will be repaired / reconfigured / cleaned as necessary by the Administrator responsible for the system.

An incident report will be generated, highlighting how the existing security systems failed and suggest ways to prevent similar breaches in the future.

Incident Report Details

• What systems were affected?
• System name
• IP address
• Which Data was compromised?
• Identify from the Data Asset Inventory
• When and how was the breach performed?
• Software involved (include version numbers)
• Hardware if relevant (include firmware version)
• When and how was breach detected?
• How can a similar breach be prevented in the future?

Change Management helps to assure that system and data integrity controls are appropriate for systems which process Sensitive Data, including network administration, research system configuration control, research system software, proprietary (application) software and research data.

The Project Owner is responsible for reporting any changes to system configurations, installed software, etc. The Chief Operation Officer is responsible for categorizing the change requests and approving, denying or modifying the changes.

The Union Theological Seminary’s Chief Operation Officer will work in conjunction with the Chief Information Officer to maintain and review these procedures.

This procedure is required whenever a change is planned for the following aspects of the Union Theological Seminary network and hosted platforms that process, store or access Sensitive Data:

• System configurations
• System software
• Application software
• Proprietary software
• Procedures
• Processes
• Infrastructure

Changes are classified into three different priorities, based on the potential impact that would occur in the wider UTS network:

Priority 1  |  Crosses organizational boundaries, serving the business functionality of many units. Is critical to the ability of UTS to meet its business and regulatory obligations, support the delivery of education, or administer research.

Priority 2  |  The system is a feeder to Priority 1 systems; or is a system that does not cross organizational boundaries, but is still critical to the ability of UTS to meets its business and regulatory obligations

Priority 3  |  Any outside hosted system that supports the internal operations of the Seminary or departmental function and does not cross organizational boundaries.

Changes will be classified into four categories:

Classification	Description	Change Request Required	Approval Required	User Notification Required
Routine	A Routine change is one that has relatively low risk with well-understood outcomes that is regularly made during normal business. A routine change follows predetermined processes and can be performed with zero impact on users.	Notification of change for record keeping only	No	No
Minor	A Minor change is one that has low to medium risk for critical services, involves less understood risk, has less predictable outcomes, and / or is a change that not regularly made during normal business. Because of the ability to affect downstream or upstream services, changes must be reviewed and approved before implementation.	Yes – submit Change Request before the change	Yes	Yes, unless the impact is transparent to users
Major	A Major change is one that has medium to high risk for critical services, involves unknown risks, and involves downtime which impacts a large percentage of users across Union Theological Seminary.	Yes, at least two days before the change	Yes	Yes
Emergency	An Emergency change is one that involves services which are already impaired and requires the utmost urgency to resolve. The approach here is to fix the problem first and document the change afterwards. Root-cause analysis must be performed to determine if the issue can be prevented in the future	Notification of change for record keeping only	N/A	N/A

1. Request for Change
   Open a ticket at helpdesk@utsnyc.edu with the heading of “Change Item” and answers the following questions, at a minimum:
   1. Change Classification (Routine, Minor, etc.)
   2. When is the requested date to perform the change?
   3. What are the proposed technical changes?
   4. What systems are impacted?
   5. Why is the change necessary?
2. Union Theological Seminary – IT Response
   1. Approval – the change will be scheduled and communications will be sent to the appropriate group or groups.
   2. Denied – the request will be closed OR modifications will be requested.
3. Implementation
   1. After proper approval notification, the change is released / performed on the date and time communicated.
4. Testing
   1. Test the change thoroughly to verify success.
5. Review
   1. If the change is successful, communicate that to the relevant users and peers, update the ticket to indicate the change was successful.
   2. If the change failed, communicate that to the relevant users and peers, attempt to restore the previous state of the system and update the ticket with all relevant information as to what went wrong and possible solutions to the issue.
   3. Update the project’s Information Asset Inventory to reflect the new state of the system.

See the IT Policy Section here: https://uniontheo.wpengine.com/about/institutional-info