IT CHANGE MANAGEMENT POLICY PURPOSE The purpose of the IT Change Management Policy is to manage changes in a planned and predictable manner in order to assign resources, assess risk and minimize any potential negative impact to services at the University. SCOPE This Policy applies to all ITS staff at Brock University. POLICY STATEMENT All changes (including urgent / emergency changes) to IT resources, services and / or systems must follow a standard process to ensure appropriate planning, resourcing and execution. The Change Manager along with the Change Advisory Board (CAB) are the stewards of this process. All changes must be presented to the CAB for approval in order to coordinate timelines, avoid conflict and maintain a complete and controlled view of change at the University. The CAB will in turn maintain a record and schedule of all changes and communicate the changes to the Brock community. DEFINITIONS Refer to the Change Management Procedure. COMPLIANCE AND REPORTING ITS enforces this Policy and the related Standards at all times. Anyone who has reason to suspect a deliberate and / or significant violation of this Policy is encouraged to promptly report it to the Information Technology Services ( ITS ) Help Desk. Policy violations that come to the attention of the ITS Help Desk will be escalated to the Director, Client Services. Policy violations will be assessed and action taken to remediate the Page 1 of 2
violation, including consequences where appropriate, subject to collective agreements and / or other contractual conditions. Where Policy violations are considered severe and / or cannot be easily remediated, the incident will be escalated to the AVP, ITS for further action. Periodically, the AVP, ITS will provide to SAC a summary of all policy violations. Policy owner: Associate Vice-President, Information Technology Services Authorized by: Board of Trustees, Capital Infrastructure Committee Accepted by: Senior Administrative Council Effective date: March 2016 Next review: March 2017 Revision history: New Related documents: IT Change Management Standards Change Management Procedure IT Change Management Policy Page 2 of 2
IT CHANGE MANAGEMENT STANDARDS PURPOSE A standard includes specific low level mandatory controls that help enforce and support a policy. The purpose of this document is to support and outline in detail the requirements of the IT Change Management Policy. These requirements are mandatory and must be adhered. STANDARDS All changes to an IT resource / service must be submitted to, reviewed and approved by the Change Advisory Board (CAB) The CAB is chaired by the Change Manager and includes ITS representatives from Client Services, Infrastructure, and Application Development The purpose of the CAB is to understand, authorize and schedule proposed changes to Brock University s production IT environment IT Stakeholders from outside of ITS (e.g. Library, FAHS, GSB, COSC etc.) are welcome to attend CAB meetings and have view access to the CITS-Activity Calendar The CAB has the authority to re-schedule, deny or request further detail regarding any Change Request The CAB must maintain, track and communicate all Change Requests using, but not limited to: o Footprints Ticket o Footprints Projects o ITS CITS-Activity Calendar o Brock Portal Bulletins o Mailing Lists (ITSFYI, CSL-L) The CAB is responsible for governance, not execution activities The Change Owner, not the CAB, is responsible for the Page 1 of 2
success of their respective change All changes to an IT resource, service or system must be performed in compliance with the Change Management Procedure. These include, but are not limited to: o Firewall rule changes (additions, changes, deletions) o Changes to production network infrastructure (hardware and/or configuration) o Changes to production server infrastructure (hardware and/or configuration) o Enterprise applications (code releases, updates and maintenance) The CAB will meet weekly to review Change Requests in accordance with the timelines outlined in the Change Management Procedure Urgent/Emergency change requests to prevent an imminent failure or to repair a service outage in the production environment may be expedited through the Emergency CAB (ECAB) process outlined in the Change Management Procedure Changes that do not comply with the IT Change Management Policy, or that are implemented without the knowledge of the CAB are unauthorized o IT Resources will not be made available for unauthorized changes o ITS has the authority to reverse any unauthorized changes that cause, are suspected as causing or have the potential to cause disruption to other users of the services. Page 2 of 2
Information Technology Services Change Management Procedures Brock University ITS Client Services Document Version 1.0 December 12, 2014 1
Introduction All changes to an IT resource, system or service must follow the standard procedure outlined below to ensure appropriate resourcing, planning and execution. Change Classifications and Definitions Changes Categories Routine Standard Enterprise Emergency A routine change is a scheduled change that is done routinely to maintain or tune a resource, service or system, e.g., performing Windows updates on a server, installing a security patch on an appliance. Routine changes have a Minor Client Impact Rating and a Low Technology Risk (see Technology Risk Rating and Client Impact Rating below) A standard change is a scheduled change that has a Moderate Client Impact Rating. Standard changes have the potential to impact a larger portion of the user community, e.g., a network switch upgrade in a building that may impact multiple departments An enterprise change is a scheduled change that has a Moderate to Major Client Impact Rating and has the potential to impact University operations, e.g., taking the my.brocku.ca portal offline for upgrades or maintenance An emergency change is an unscheduled change that has a Moderate to Major Client Impact Rating but must be performed quickly to address a service outage, prevent an outage, or fix a critical problem, e.g., deploying a critical security patch to all Windows servers, restarting the entire wireless network in order to address a performance issue. Technology Risk Ratings Low Significant High A technology change with little or no interactions with other resources, services or systems, e.g., Bomgar, KACE, stand-alone Windows servers A technology change with increased interactions with other resources, services or systems, e.g., Radius Authentication (affects wired and wireless services), e-mail A technology change with many interactions with other resources, services or systems, e.g., network core routing, netapp enterprise storage. 2
Client Impact Ratings Minor Moderate Major A change that has the potential to disrupt a group of 1-25 users A change that has the potential to disrupt a group of 26-100 users A change that has the potential to disrupt a significant group of over 100 users Change Classification Matrix Change Category Technology Risk Client Impact Student/Faculty/Staff Change Approval Required Routine Low Minor No* Standard Enterprise Change Low Moderate Yes Significant Moderate Yes Significant Major Yes High Moderate / Major Yes Emergency High Major Yes *While Routine changes are still documented and scheduled, after initial approval, subsequent approvals for the same change are not required, e.g., weekly Windows server patching which occur during a regularly scheduled maintenance period. Maintenance Windows ITS maintains specific scheduled times in which work on resources / services / systems is preferred in order to minimize disruptions. The times listed below are listed as maintenance times on specific pages (e.g. Webmail, Portal, Sakai) in order to notify our users that work may be performed during these times and therefore the resource / service / system may be unavailable. Work may be performed outside of these scheduled maintenance windows but must be communicated (see Communications below). 3
Scheduled ITS Maintenance Windows Change Category Change Window Notice required Routine No predefined window Not Applicable Standard Enterprise Emergency Monday Friday 6:00 AM 8:00 AM Saturday 12:00 AM 10:00 AM Determined by Change Manager and/or ITS Director 5 Business Days 10 Business Days Determined by Change Manager and/or ITS Director Maintenance Freeze Periods Annual times for maintenance freeze 4 th week of August to 3 rd week of September The week-and-a-half before the Christmas Break (Payroll) Change Category Allowed Routine and Emergency Routine and Emergency Roles and Responsibilities Change Manager The Change Manager is responsible for managing Change Management for ITS. This individual focuses on the change process as a whole rather than the specifics of the work within each individual change. The Change Manager s responsibilities include: Ensuring that Change Requests are formatted and submitted to the CITS-Activity Calendar from Change Initiators Maintaining the CITS-Activity Calendar and its membership Facilitating CAB meetings Reviewing Technology Risk and Client Impact Ratings for all submitted Change Requests Publishing Change Notifications to the community Documenting, publishing and assessing compliance with the Change Management process Reviewing, evaluating and maturing the change process. Change Initiator All members of ITS are permitted to submit change requests as Change Initiators. Change Initiators are responsible for: 4
Initiating change requests by completing the Change Request Template and submitting it to the CITS-Activity Calendar Assuring that all change requests are documented and linked to either a Footprints Ticket or Footprints Project Number Assisting the CAB when further information is required about pending change requests. Change Advisory Board (CAB) The Change Advisory Board is a group of individuals that formally meet to review change requests. The CAB is comprised of departmentally-appointed individuals to act as contributors and is chaired by the Change Manager. The CAB Meets every Tuesday morning, at 9:30 to review and schedule change requests (see Change Request Process ) The CAB as a whole Approves, Denies or Recycles proposed change requests and documents the change of status in the CITS-Activity Calendar. At the conclusion of the CAB meeting, members pass along Change Management related information to the Change Initiators/Staff in their respective departments, e.g., if a change request was moved due to a scheduling conflict, or more information is required for a particular change request. Emergency Change Advisory Board (ECAB) The Emergency Change Advisory Board is a group of individuals that must meet in extraordinary circumstances in order to approve an Emergency Change Request. Emergency change requests requiring an ECAB are un-planned and require the approval from one of the following prior to change implementation: AVP, Information Technology Services Director, Application Development Director, Client Services Director, IT Infrastructure. Emergency change requests still need to be recorded in the CITS-Activity Calendar (using the Change Template) but are expedited in order to recover from a critical resources, service or system outage. Communication Plan In order to keep the University community informed of changes and planned maintenance of IT resources, services and systems, the Change Manager must: Keep the CITS-Activity Calendar up-to-date with all change requests, important dates and maintenance freezes 5
Ensure that web systems such as Webmail, LMS and the portal have the maintenance schedule identified on their log-on pages Post approved change requests to the my.brocku.ca portal identifying the work being performed, who it may affect, the scheduled date and duration Additional e-mails may be sent to individuals/groups at the discretion of the Change Manager Change Management Workflow Change requests must reference a Footprints ticket or project number. The Footprints system is where all of the information regarding the specifics of the Change Request are to be kept. The detailed information in the ticket must include, but is not limited to: Work required Required resources (people/teams) Resources / services / systems affected Users / groups affected Work plan Back out plan Change Request Statuses All Change Requests are submitted to the CITS-Activity Calendar with the starting status of Proposed. Statuses explained: Proposed Approved Recycled Rejected A proposed change awaiting CAB review A CAB reviewed change that is approved to proceed A CAB reviewed change that requires more information or needs to be rescheduled based on resource availability A CAB reviewed change that is not approved to proceed due to insufficient planning, resources or not referencing a Footprints ticket or project number Procedure for Routine, Standard or Enterprise Change Requests (CAB Changes) 1. The Change Initiator creates Footprints ticket/project 2. The Change Initiator submits change request (using Change Template ) to the CITS-Activity Calendar as a proposed change 3. The CAB reviews the change request in the CITS-Activity Calendar and as a group Approves, Recycles or Rejects the individual change request 4. The CAB Contributors notify their individual department/change initiators of changes that are allowed to proceed 6
5. Using the Communication Plan, the Change Manager communicates the upcoming approved changes 6. Work on the Approved Changes is performed and tracked in Footprints. Procedure for Emergency Changes (ECAB Changes) 1. A service outage, vulnerability or proactive event is identified and recorded in Footprints by anyone 2. The Footprints ticket is immediately escalated to a supervisor/manager/director 3. Any available CAB members and/or an ITS Director (as the ECAB) meets with ITS Staff knowledgeable with the situation to discuss course of action, and approve the Emergency Change 4. The community is notified of the emergency work being performed 5. The Emergency Change Request is posted to the CITS-Activity Calendar 6. Footprints ticket(s) are updated throughout the work. 7
Appendix A Change Template Changes are to be tracked using the CITS-Activity Calendar in Exchange (accessed through Microsoft Outlook). The following template must be included the in body of each Proposed Change Request (as a calendar event): SUBJECT: Insert BRIEF Title along with Footprints Ticket or Project Number here. STATUS: PROPOSED PROPOSED CHANGE SUMMARY: Provide a quick summary of the proposed Change Request. OTHER INFORMATION: Place to provide any other information regarding this Change Request. PROPOSED CHANGE TIMELINE: Provide information regarding the proposed date and time for the actual work to be performed. CHANGE CATEGORY: (The Change Initiator selects the appropriate Change Category). Routine Standard Enterprise Emergency TECHNOLOGY RISK: (The Change Initiator selects the appropriate Technology Risk from the Technology Risk Rating assessment). Low Significant High CLIENT IMPACT: (The Change Initiator select the appropriate Client Impact choice based on the Client Impact Rating). Minor Moderate Major RESOURCES: (The Change Initiator indicates the individuals/teams required as a quickreference to perform the work for this change). 8