Brock Oy PURPOSE SCOPE POLICY STATEMENT DEFINITIONS COMPLIANCE. IT CHANGE MANAGEMENT POLICY 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. This Policy applies to all ITS staff at Brock University. 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. Refer to the Change Management Procedure. ITS enforces this Policy and the related Standards at all times. AND REPORTING 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Brock Onn 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: Footprints Ticket © Footprints Projects ITS CITS-Activity Calendar ©. Brock Portal Bulletins 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: © Firewall rule changes (additions, changes, deletions) © Changes to production network infrastructure (hardware and/or configuration) © Changes to production server infrastructure (hardware and/or configuration) 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 © IT Resources will not be made available for unauthorized changes 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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 A routine change is a scheduled change that is done routinely to maintain or tune a resource, service or system, ¢.8,, performing Windows updates on a server, installing @ 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) Standard standard change is a scheduled change that has @ “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 Enterprise 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 Emergency An emergency change is an unscheduled change that has @ “Moderate” to “Major” Client Impact Rating but must be performed quickly to address a service outage, prevent ‘an outage, or fix 8 critical problem, e.g., deploying a critical security patch to all Windows servers, restarting the entire wireless network in order to address @ performance issue. Technology Risk Ratings Low A technology change with little or no interactions with other resources, services or systems, e.g., Bomgar, KACE, stand-alone Windows servers Significant A technology change with increased interactions with other resources, services or systems, e.g,, “Radius Authentication” (affects wired and wireless services), e-mail High ‘Atechnology change with many interactions with other resource: services or systems, ‘@g., network core routing, netApp enterprise storage.Client impact Ratings Minor Achange that has the potential to disrupt @ group of 1-25 users Moderate Achange that has the potential to disrupt a group of 26-100 users Major A change that has the potential to disrupt a significant group of over 100 users Change Classification Matrix “While “Routine” changes are still documented and scheduled, after initial approval, subsequent approvals for the samme change are not required, eg., 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).Scheduled ITS Maintenance Windows No predefined window Not Applicable “| Monday-Friday jusiness Days d | 6:00 AM-8:00 AM Saturday 110 Business Days 12:00 AM~ 10:00 AM. Determined by Change Manager | Determined by Change Manager and/or ITS Director and/or ITS Director Maintenance Freeze Periods 4® week of August to 3" week of September The week-and-a-half before the Routine and Emergency Christmas Break (Payroll) Routine and Emergency Roles and Respon: Change Manager ‘The Change Manager is responsible for managing Change Management for ITS. This individual focuses on the change process as @ whole rather than the specifies 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:‘© _ 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. ‘+ Atthe conclusion of the CAB meeting, members pass along Change Management related information to the Change Initiators/Staff in their respective departments, e.., ifa 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 @ 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‘© 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 © Workplan © 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 A proposed change awaiting CAB review Approved CAB reviewed change that is approved to proceed Recycled CAB reviewed change that requires more information or needs to be rescheduled based on resource availability Rejected 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5. Using the Communication Plan, the Change Manager communicates the upcoming approve changes, 6. Work on the Approved Changes is performed and tracked in Footprints. Procedure for Emergency Changes (ECAB Changes) 1. Aservice 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 usdated throughout the work.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 quick- reference to perform the work for this change).