Information Technology Services

ITS Change Window Policy

1.0 OBJECTIVE

The objective of Brandeis University (“University”) Information Technology Services (“ITS”) in the development and implementation of this policy is to create effective administrative controls and safeguards for the protection of production IT services during the scheduling of change events.

2.0. PURPOSE

The purpose of the Change Window Policy is to ensure proper notification and coordination between ITS and the Brandeis Community in the scheduling and execution of changes to production IT services.

3.0. SCOPE

This Policy applies to all Brandeis University ITS employees, whether full- or part-time, including administrative staff, union staff, contract and temporary workers, hired consultants, interns, and student employees executing changes to production ITS services or other Brandeis University services where ITS assistance is required.

4.0 DEFINITIONS

Production Services: A controlled environment containing live configuration items used to deliver IT services to customers.

Change Window: A predetermined period of time during which ITS can reasonably perform proactive maintenance and improvements to the IT environment or under certain circumstances, must perform emergency maintenance to production services.

Emergency Change Window: Any change window request, where an affected production service must go into maintenance due to the potential, imminent or active impact to customers or adjacent production services during Peak Business Hours.

Peak Business Hours: Monday-Friday between 8am and 5pm.

Major Changes: Any change window request, including Emergency Change Windows, which will have the potential or immediate impact to customers or Production Services and coincides with scope and severity of impact as defined in the ITS Major Incident Management Policy list of Major Incident Criteria.

5.0 POLICY

5.1 SCHEDULING OF CHANGES

Scheduling Requests must be submitted through the ITS Ticketing System. 

Non-emergency changes to production services shall,

• Scheduling Timeline All non-emergency maintenance window requests must be submitted at a minimum of fourteen (14) days prior to the proposed maintenance window. Recurring maintenance windows must be submitted prior to the start of each semester or launch of new service.

• Be scheduled at times considered to be non-peak business hours (ex. maintenance ends before 8am or starts after 5pm);
• Be scheduled on Tuesday, Wednesday, or Thursday, to allow ITS staff sufficient time during the week to monitor and respond to issues; 
• Be scheduled to not overlap at any level with other changes at the same time.

Non-emergency requests may be approved by the requestor or an administrator. 

Exceptions to day/time may be made in specific cases where there is no potential impact to the community or production services.

Example: If a live service can be updated, without causing any impact and with no historical basis to assume a potential impact may occur, the change window may occur during peak business hours as long as the Director of the responsible department or their designee in their absence approves the day/time.

Emergency Maintenance Requests, which may be required during peak business hours, must be approved by the requestor’s Department Manager or by a Director of ITS . 

Major Incident Change Requests, which may be required due to an emergency maintenance event, must be managed by the Major Incident Management Team and approved by those with Major Incident Declaration Authority as described in the ITS Major Incident Management Policy.

5.2 LENGTH OF CHANGES

Any change window shall have sufficient time to support:

• Notification of impacted staff immediately prior to the change implementation.
• Implementation of the proposed changes.
• Post-implementation testing of the proposed changes
• Implementation of the rollback plan if the change fails or does not pass the testing criteria.
• Notification of impacted staff immediately after end of the proposed change outlining the current state of the modified services.

5.3 NOTIFICATIONS

ITS adheres to the University's Broadcast Email Procedures on minimizing the number of announcements that are sent to the entire Brandeis Community. Therefore, scheduled change notifications should be sent to change stakeholders (including users of a particular system, the Help Desk, and/or other supporting parties as appropriate, etc.) through targeted emails; and through the Brandeis University Status Page. In instances where the entire Brandeis Community will be affected, or if impacted services meet thresholds of defined ITS Major Incident Management criteria, the University's Broadcast Email Procedures should be followed accordingly. 

Internal Notifications upon request for Emergency Maintenance

• The Change Management Office (CMO), Help Desk and Major Incident Management Team are notified of any change window requests as TDX tickets are made.
• Any requests that are for emergency maintenance, following the creation of the request in the ITS Ticketing System, the requestor will link to the requested Ticketing System ticket in the ITS #statuspage-incidents channel on Slack to ensure monitoring by the Major Incident Management Team and to enable reporting or requests through the Ticketing System.

Notifications prior to change windows consists of:

• Sending an email notification to impacted users and the Help Desk; and publishing an update to the Brandeis University Status Page (status.brandeis.edu) (1) one week prior to the scheduled event window containing the scheduling details of the event and what services will be impacted.
• Sending an email notification to impacted users and the Help Desk; and publishing an update to the Brandeis University Status Page (status.brandeis.edu)  (1) one day prior to the scheduled event window containing the scheduling details of the event and what services will be impacted.

Notifications immediately prior to start of change:

• Sending an email notification to the impacted users and the Help Desk; and publishing an update to the Brandeis University Status Page (status.brandeis.edu) (1) one hour prior to the scheduled event window containing the scheduling details of the event and what services will be impacted.

Notifications after change windows consists of:

• Sending an email notification to the impacted users and the Help Desk; and publishing an update to the Brandeis University Status Page (status.brandeis.edu) immediately following the change window current state of the service.
• Informing the CMO and Help Desk of the finalizing of the changes via the existing TDX ticket.

Notifications relating to public safety services:

• If the scheduled change, in any way, impacts public safety services, Public Safety Dispatch (x65000) should be contacted on the following schedule:
  • Once the change window has been established
  • Immediately prior to the start of the change event
  • Immediately following the change event. 
• Public safety services include, but not limited to, telephone services, access control, video surveillance, etc.

Notifications relating to “Major Changes”:

• If the scheduled change, in any way, fits criteria of defined Major Changes, an InBrief article request should be made within the appropriate time-frame prior to the change window.

6.0 EMERGENCY CHANGES

In the event that an emergency change is required to a production service during peak business hours, portions of the Change Window Policy may be circumvented with the approval from one of the following individuals. 

James La Creta, Chief Information Officer

Anne Marando, Deputy CIO

David Albrecht, Chief Information Security Officer

If the emergency event meets criteria set forth in the ITS Major Incident Management plan, consult the Major Incident Management Team prior to acquiring approval from the aforementioned individuals.

7.0 REVISION HISTORY

Version	Published	Author	Description
1.0	01/13/2025	Steve Knowles, Director for Strategic Outreach & Engagement Valerie Pirri, Program Director, Workday & IT Change Management Ex Officio, David Albrecht, CISO	Policy was approved by James La Creta, CIO on 12/15/2024