This website uses cookies so that we can provide you with the best user experience. By using this website, you consent to the use of cookies. Learn more about our use of your data by reading our Privacy Policy.

Accept Privacy Policy
Apply Visit Campus Request Info Give
Students, Faculty, and Staff Search Menu

ITS Policies & Procedures

ITS / Policies / Change Management Policy

Change Management Policy

Policy #: LFC.ITS.6
Date: 10/23/2024
Author: LFC ITS
Version: 2.1
Status: Revised, pending review

OVERVIEW

This policy outlines the change management procedures for making modifications to Lake Forest College's IT infrastructure and other critical e-resources, such as enterprise applications, servers, network infrastructure, and related systems. By adhering to this policy, we reduce the risk of disruptions and maintain the consistency of operations and reporting. Without such a structured approach, the likelihood of potential incidents increases, and a lack of proper documentation for IT changes follows. Change Management is key to minimizing potential risks when introducing updates to the IT system. The objective is achieved through consistent methods to accurately document, communicate, and implement changes.

1. PURPOSE

The objective of this policy is to ensure that changes to critical Lake Forest College IT Systems are tracked to promote the continuity of IT services, and to minimize the number of negative incidents which might impact College services and user, and explicitly outline change management policies for systems handling Covered Data in compliance with the Gramm-Leach-Bliley Act (GLBA). This policy is designed to uphold regulatory obligations for safeguarding customer information as defined by GLBA.

2. SCOPE

While all users of College e-resources may benefit from awareness of this policy, the policy applies primarily to the College’s Information Technology Services (ITS) staff, student workers or interns, and contractors who perform development or system administration work on any College IT systems, digital infrastructure, or services that receive, process, transmit, store, and/or otherwise handle GLBA “Covered Data” or Protected Information (henceforth referred to as “PI”.) All such systems, whether managed by ITS, another department, or a contracted vendor, fall within the scope of this policy. Systems not managed by Lake Forest College ITS – such as Software as a Service (SaaS) platforms – are included if they receive, process, transmit, store, or handle PI. In cases where such systems are not directly managed by Lake Forest College Information Technology Services, ITS will ensure that appropriate change management practices compliant with GLBA requirements are coordinated with the responsible teams or vendors.

3. ENTERPRISE APPLICATIONS CHANGE MANAGEMENT TERMS

3.1 Change Management is a structured approach for introducing alterations within the IT infrastructure, most notably within enterprise applications. This process involves initiating a Change Request and culminates in the successful deployment of the proposed change.
3.2 A Change Request is a request for a modification, such as the addition of a new feature or capability.

4. ENTERPRISE APPLICATIONS CHANGE MANAGEMENT PROCESS

4.1 Requesting a Change: All changes to enterprise applications must be initiated through a formal change request. This request should be made by the entity desiring the change and should be aided by a member of the ITS Enterprise Applications team.
4.2 Analyzing and Justifying Change: Once initiated, both the requester and the ITS team will:
  • Ascertain the need and justification for the change.
  • Determine the feasibility of the change, especially concerning proprietary code or system access.
  • Identify, assess, and document potential technical and business risks which might be introduced by changes, ensuring alignment with GLBA requirements.
  • Evaluate the potential impact on the infrastructure, business operations, budget, and cybersecurity posture.
  • Establish technical prerequisites.
  • Develop and review the implementation methodology.
  • Formulate a functional test plan to ensure the change meets its intended outcome.
4.3 Change Approval and Scheduling: The oversight of this phase will be managed by the Director of Enterprise Systems, who will direct a change management team comprised of ITS staff with expertise in various areas such as network management, server administration, security, database management, and desktop support. Additionally, relevant stakeholders from the user community will be incorporated when appropriate. The magnitude and implications of the change will determine the level of authorization needed, including up to authorization and approval by the Vice President for Information Technology and Chief Information Officer (CIO.)
4.4 Change Execution and Review: Upon approval, the Director of Enterprise Systems will delegate specific tasks to ITS members and identify relevant stakeholders to ensure a seamless transition. Any changes to systems handling PI subject to GLBA-mandated safeguards must be thoroughly documented, including the steps taken during implementation and any security or compliance checks performed. If any issues arise post-change, the Director of Enterprise Systems will assess whether to revert to the previous stable state, and a detailed review of the change process will be conducted. This documentation must be retained for audit purposes to demonstrate compliance with GLBA change management requirements.

5. INFRASTRUCTURE CHANGE CLASSIFICATION

5.1 Standard Changes are pre-approved and low-impact, well-known, and documented. Standard changes require a risk assessment and authorization when implemented for the first time, but subsequent implementations can be done without these precautions as long as the change has not been modified. Examples include swapping failed equipment in a like-for-like exchange, changing the tagging of a port on a network switch, replacing failed components in a server, or other normal day-to-day maintenance and administrative tasks.
5.2 Significant Changes need to follow the change control procedure; they should be scheduled, have their risk assessed, and be authorized in advance. Significant changes have an impact and urgency of medium or higher. All changes that are not standard or emergency should be treated as normal changes and adhere to the change control procedure. The following activities should be considered significant at a minimum:
  • Hardware: activities such as installations, alterations of solution design, or equipment relocations
  • Database: updates, modifications, or significant maintenance tasks which will result in brief interruptions to service or measurably degrade performance for a period of time exceeding 15 minutes.
  • Schedule Alterations: Changes related to job schedules, backup schedules, or other routine tasks overseen by ITS staff.
  • Outages: Any application or network downtime event expected to exceed 30 minutes will necessitate a thorough review.
5.3 Emergency Changes are typically unplanned, high impact, and require expedited assessment, approval, and implementation to restore normal functionality as quickly as possible. Modifications to components that affect business operations, and therefore cause downtime, are treated as emergency changes. Emergency changes often occur as a result of equipment or service failures. For systems that handle PI subject to GLBA-mandated safeguards, any emergency changes must undergo a post-change compliance review to ensure that all regulatory requirements have been maintained during the expedited process

6. INFRASTRUCTURE CHANGE MANAGEMENT POLICY

6.1 Standard changes to College IT systems need only be tracked by ITS staff as necessary to restore previous service states or equipment programming as needed.
6.2 Significant changes to College IT systems must follow the Change Control Procedure identified by the CIO to ensure appropriate approval, planning and execution.
6.3 Change requests are not required for non-production environments unless there is a significant upgrade or impact.
6.4 Production change requests must note that the change has been successfully applied, tested, and verified in a non-production environment when a suitable environment exists.
6.5 Changes to production environments undergo impact examination before submitting the change request per the change control procedure. This information will be used to determine the impact of the change by considering:
  • The impact the proposed change will have on business operations, if it is expected to cause a widespread outage, a loss of connectivity or functionality to a specific group or groups;
  • The effect of the change on the security of GLBA-regulated data and whether safeguards remain in place to protect customer information, as required by federal regulations.
  • The risk involved in not making the change;
  • The risk if the change does not go as planned; and
  • Predictability of the success of the change.
6.6 Any significant changes to IT systems – especially Internet-facing systems or services – must be reviewed for security implications by the Information Security Manager. Any significant changes to IT systems – especially Internet-facing systems or services – must be reviewed for security implications by the Information Security Manager. For systems that handle PI subject to GLBA-mandated protections, the review must ensure compliance with the relevant security requirements to safeguard customer information and ensure that no regulatory requirements are overlooked during the change process.
6.7 Significant user experience changes must be conveyed to ITS leadership and communicated to the affected audience and ITS User Services.
6.8 An after-action review will occur in the event of an incident during a change request, or whenever an undocumented change leads to an incident. For incidents affecting systems that handle PI regulated by GLBA, the review must include an evaluation of whether GLBA compliance was maintained throughout the change process. Detailed notes of the review, including any corrective actions and lessons learned, must be documented and shared with ITS leadership. This documentation should be retained for future audits and compliance reporting, ensuring transparency and accountability.
6.9 In emergency cases, actions may be taken outside of change control procedure if approved by the CIO or their designee(s). All changes should be documented and reviewed upon the conclusion of emergency.

7. INTERNAL SYSTEM MAINTENANCE

On rare occasions, ITS staff may need to apply emergency security patches and software and/or firmware updates to IT systems to protect Lake Forest College's IT environment. Although every effort is made to minimize the impact of such maintenance on users, ITS staff may require vendor support during maintenance cycles. Not all vendors provide 24/7 support, and for those that do, 24/7 support contracts are typically prohibitively expensive. Whenever possible, ITS will schedule unplanned infrastructure outages requiring vendor support in a reserved 5-7pm “maintenance window” on Wednesdays. ITS infrastructure work which will create a service outage and does not require vendor availability shall be performed before College business hours, typically between 5-7am and will be communicated to campus a week in advance when possible. More predictable maintenance work will adhere to the Information Security Policy, Section 7.5 “Required Software Updates”.

8. EXTERNALLY HOSTED SYSTEMS

Applications, systems, and services hosted externally by third-party vendors are typically not under the direct control of ITS staff for maintenance windows or upgrades. However, when these externally hosted systems receive, process, transmit, store, or otherwise handle PI subject to GLBA-mandated administrative and technical safeguards, vendors are required to follow change management practices that comply with GLBA regulations. ITS staff will coordinate with vendors to ensure that appropriate safeguards are in place and that the vendor’s change management processes maintain compliance with GLBA and other relevant regulatory requirements. Staff should continue to monitor emailed notices regarding third-party maintenance windows and adapt their work as necessary.

RELATED POLICIES:

Document Control:

Entry#: Date Version Notes
1 2014 1.0 Original policy, approved by LITS Advisory Committee
2 10/25/2023 2.0 Revised, submitted for review
3 12/07/2023 2.0 Revised policy, reviewed by LITS Advisory Committee
4 01/18/2024 2.0 Reviewed and approved by the Senior Leadership Team
5 10/23/2024 2.1 Revised policy, submitted for review

Information Technology Services