IT CHANGE MANAGEMENT POLICY Effective Date May 19, 2016 Crss-Reference 1. IT Operatins and Maintenance Plicy 2. IT Security Incident Management Plicy Respnsibility Apprver Review Schedule 1. Plicy Statement Directr, Infrmatin Technlgy Executive Cuncil Every 5 years Appendices 1. IT Management Guidelines 2. Sample Request fr (RFC) 1.1 Grande Prairie Reginal Cllege ( GPRC r the Institutin ) frmally manages changes t its Infrmatin Technlgy ( IT ) resurces t prevent disruptins t the stability r integrity f Institutin IT systems, applicatins and data. 2. Backgrund 2.1 Uncntrlled changes t IT systems and applicatins culd ptentially result in significant system disruptin, data crruptin r lss. A frmalized IT change management prcess is designed t ensure that changes are authrized and perate as intended. 3. Plicy Objective 3.1 The bjective f this plicy is t define frmal requirements t manage changes t IT systems and applicatins, in rder t prevent unscheduled disruptin, data crruptin r lss. 4. Scpe 4.1 This plicy applies t: 5. Definitins 4.1.1 All IT systems r applicatins managed by GPRC that stre, prcess r transmit infrmatin, including netwrk and cmputer hardware, sftware and applicatins, mbile devices, and telecmmunicatin systems. 4.1.2 All change requests t IT systems and applicatins, including standard, minr, majr and emergency changes. 5.1 IT is a planned mdificatin t an IT system. 5.2 Emergency IT is an unplanned mdificatin t an IT system that requires immediate implementatin t crrect an imprtant issue, such as a disruptin r utage f service. 5.3 Advisry Bard (CAB) is a grup f peple that make decisins related t majr changes t IT systems. Members f the CAB include the IT Directr and IT Managers. IT Prject Managers and system wners affected by the change are included, where applicable. The chair f the CAB is the IT Directr. Page 1 f 12
5.4 Emergency Advisry Bard (ECAB) is a grup f peple that make decisins related t high-impact emergency changed t IT systems. Members f the ECAB include the IT Directr and IT Managers. IT Prject Managers and system wners affected by the change are included when time permits. The chair f the ECAB is the IT Directr. 5.5 Apprver is the IT Manager/Directr that is respnsible fr apprving a minr change, bringing a majr change t the CAB fr apprval, r an emergency change t the ECAB fr apprval. 5.6 Manager is the IT staff member that is respnsible fr ensuring that the dcumentatin, testing, and implementatin f a change is cmplete. 5.7 Requestr is the user that initiates the change request. 6. Guiding Principles 6.1 The IT Department will apply a frmal apprach t managing IT systems and applicatins changes. 6.2 s t IT systems and applicatins must be managed in accrdance with the IT Management Guidelines cntained in Appendix 1. 6.3 All change requests must be: 6.3.1 Classified befre being prcessed. The level f analysis, apprval and testing must be aligned with the change classificatin level in rder t address ptential risks. 6.3.2 Apprved prir t cmmencing the change r develpment, and prir t implementing the fully tested change int the live envirnment. 6.3.3 Dcumented befre, during and after implementatin. See Appendix 2 fr a sample f the type f infrmatin required fr a Request fr ( RFC ). 6.4 Business value, business risks, technical risks (including ptential impact t perfrmance and security risks), as well as csts must be frmally cnsidered befre authrizing changes. 7. Rles and Respnsibilities Stakehlder Respnsibilities Executive Cuncil Apprve and frmally supprt this Plicy. Vice-President Administratin IT Directr Review and frmally supprt this Plicy. Develp and maintain this Plicy. Take practive steps t reinfrce cmpliance f all stakehlders with this Plicy. Cmmunicate with the Institutin, directly r thrugh Institutin representatives, in infrmal r frmal instances, t understand the Institutin needs and expectatins, explain the capabilities f the existing technlgy in prductin, and facilitate the prcess t manage change requests. Reprt t the Vice-President Administratin, the President and CEO as well as the Bard f Gvernrs. Page 2 f 12
8. Exceptins t the Plicy 8.1 Exceptins t the guiding principles in this plicy must be dcumented and frmally apprved by the IT Directr, with evidence f supprt frm the apprpriate Vice-President. 8.2 Plicy exceptins must describe: 9. Inquiries 8.2.1 The nature f the exceptin 8.2.2 A reasnable explanatin fr why the plicy exceptin is required 8.2.3 Any risks created by the plicy exceptin 8.2.4 Evidence f apprval by the IT Directr 9.1 Inquiries regarding this plicy can be directed t the IT Directr. 10. Amendments (Revisin Histry) 10.1 Amendments t this plicy will be published frm time t time and circulated t the Institutin cmmunity. Page 3 f 12
Appendix 1 IT Management Guidelines All change requests must be managed accrding t the principles illustrated in this flwchart diagram: 1. Request fr a t IT Systems 1.1. Identificatin f the need fr a frmal change request 1.1.1. A new request fr change can be initiated by any user. 1.1.2. The need fr an IT change can be the result f an IT incident r prblem, a new system release, r a specific request, including, fr example: 1.1.2.1. Cmmissining r decmmissining an IT system r service. 1.1.2.2. Mdifying a system cnfiguratin that requires IT invlvement. 1.1.2.3. Develping, cding, scripting, r prgramming a system r applicatin. 1.1.2.4. Patching and updating system firmware, perating system r sftware. 1.1.2.5. Making bulk changes t systems and data in prductin, utside f standard business peratins r applicatin functinality prcesses. 1.1.2.6. Mdifying security grup, rles and privileges. 1.1.2.7. Mdifying the security cnfiguratin f IT systems, applicatins and netwrks. 1.1.3. IT change requests must be first prcessed by the Help Desk, a representative frm IT r the IT Directr, wh will cnfirm the need t submit a frmal request, r identify alternative ptins where apprpriate. 1.2. Dcumentatin f changes 1.2.1. The change request must be dcumented in the request tracking system (Matadr Calls/Wrk Lg), and the change management fields must be filled in. The requested change must: 1.2.1.1. Identify the change requestr, change reviewers, change resurces, change manager, and change apprvers. 1.2.1.2. Cntain sufficient details t facilitate a clear assessment f the risk and demnstrate sufficient planning. 1.2.1.3. Be cmmunicated t the apprpriate stakehlders fr validatin and assessment, and be apprved thrugh the tracking system befre implementatin. Page 4 f 12
1.2.2. The change manager is respnsible fr ensuring that: 1.2.2.1. The initial classificatin f the change request is accurate. 1.2.2.2. All required dcumentatin is recrded (as per sectin 2.1). 1.2.2.3. All required apprvals are in place (as per sectin 2.1) befre starting r implementing the change. 1.2.2.4. Status updates, such as apprval and cmpletin status, are maintained thrughut the life cycle f the change (frm creatin t cmpletin, r cancellatin). 2. Classificatin, Review and Apprval f new Requests 2.1. classificatin There are fur types f IT changes as fllws: Type Emergency Majr Criteria A change that requires immediate implementatin t crrect an imprtant issue, such as a disruptin r utage f service. Examples f emergency changes include: repairing an IT service issue that severely impacts the business, r a situatin that requires immediate actin t either restre a service r prevent an utage. An emergency change requires: Sufficient review and discussin with all impacted and invlved parties, including business users, the IT Manager f the team perfrming the change, and members f the ECAB. Apprval by the ECAB prir t implementatin. Testing may be reduced, r nt perfrmed altgether if necessary, and may be perfrmed after implementatin. Submissin f a frmally dcumented change request within ne business day after the issue has been reslved. Pst-implementatin review. Presentatin and discussin at the next CAB meeting. A change that is high risk and cmplex, with a significant ptential impact t prductin services, and limited backup/recvery in the event f an issue. A majr change requires: Frmal review and discussin with all impacted and invlved parties, including business users, the IT Manager f the team perfrming the change. Frmal testing. Frmal review and apprval by the CAB prir t implementatin. Frmal pst-implementatin review. Supprting Dcumentatin Dcumentatin can be prvided after the change has been implemented. Request ECAB apprval Pst-implementatin review Request Risk assessment Design/Slutin dcumentatin Implementatin plan Test plan Test results Back-ut plan Outage ntificatin CAB apprval Pst-implementatin review Page 5 f 12
Type Minr Standard Criteria A change that is lw risk and well understd, with a limited ptential impact t prductin services, is sufficiently tested prir t implementatin and is easy t back-ut in the event f an issue. A minr change requires review and apprval by the manager f the team perfrming the change. A change that is lw risk and relatively cmmn, where the implementatin fllws a simple dcumented prcedure r wrk instructin. Fr example, passwrd reset r prvisin f standard equipment t users. A standard change fllws a frmal prcedure r wrk instructin that has been authrized in advance. Supprting Dcumentatin Request Risk assessment Back-ut plan Remediatin plan r apprach Apprval by manager Standard Prcedure Authrizatin 2.2. review and analysis 2.2.1. Business value, business risk, technical risk, and cst must be assessed as part f a frmal review f new change requests, by stakehlders frm the Institutin and IT. 2.2.2. Business value and risk includes the fllwing: 2.2.2.1. Value t Institutin peratins and alignment with business bjectives and requirements. 2.2.2.2. Ptential impact and risk t Institutin peratins if the change is implemented. 2.2.2.3. Ptential impact and risk t Institutin peratins if the change is nt implemented. 2.2.2.4. Timing f the change t minimize impact t peratins. 2.2.2.5. Acceptance and adaptatin by affected parties and users. 2.2.2.6. Ptential security risks intrduced by the change. 2.2.3. Technical risk includes the fllwing: 2.2.3.1. Cmplexity f the change. 2.2.3.2. Cmplexity f the system r infrastructure affected by the change. 2.2.3.3. Interdependencies between different system cmpnents and IT services. 2.2.3.4. Impact n nrmal IT peratins, including: system usage, disaster recvery plans, back-up and strage, hardware and sftware, and change t peratinal prcedures. 2.2.3.5. Technical feasibility f the change and level f effrt fr IT and the Institutin. 2.2.3.6. Availability f resurces with required technical expertise. 2.2.4. Cst elements include the fllwing: 2.2.4.1. Csts assciated with nt implementing the change, such as penalties due t nn-cmpliance r lss fllwing a disruptin f the current systems r services. If pssible, ptential return n investment (ROI) shuld be estimated. 2.2.4.2. Ttal Cst f Ownership (TCO), including ne-time purchases (sftware, hardware and prfessinal services) and nging maintenance csts. 2.2.4.3. Peple csts (hurly rate, vertime, travel expenses, etc.) 2.2.4.4. External csts (cnsulting services, third party utsurced services). Page 6 f 12
2.2.4.5. Training csts. 2.2.4.6. Cmmunicatin csts. 2.2.5. Infrmatin Technlgy must ensure that that majr changes are cmmunicated t the apprpriate stakehlders t review the criteria listed abve. This includes, at minimum the: 2.2.5.1. Requestr s manager. 2.2.5.2. Impacted IT team, where applicable. 2.2.5.3. IT Manager f the team that will implement the change. 2.2.5.4. IT Directr r its representative. 2.2.6. The Requestr must prvide sufficient infrmatin t analyze the change request prir t submitting the change request fr apprval. When the Apprver reviews a change request, they either: 2.3. Apprval 2.2.6.1. Apprve r deny the prpsed change (standard / minr changes). 2.2.6.2. Bring change request frward t the CAB (majr changes) 2.2.6.3. Cnvene the ECAB t review the change request (emergency changes) 2.2.6.4. Request additinal infrmatin by sending the change request back t the Manager fr further investigatin and analysis. 2.3.1. Majr and Emergency change requests must be frmally apprved by the CAB r the ECAB, respectively. 2.3.2. Advisry Bard makes decisin abut Majr s and meets regularly, as required. 2.3.3. Emergency Advisry Bard makes decisins abut high-impact Emergency s and meets upn request by the IT Directr. 3. Implementatin and Status f Requests 3.1. Testing 3.1.1. All changes must be tested, when pssible, prir t implementatin in prductin. 3.1.2. Tests f changes must be perfrmed in a nn-prductin envirnment, where pssible. 3.1.3. A test plan must be frmally dcumented, where pssible, and apprved by IT and Institutin stakehlders: 3.1.3.1. The test plan must identify the specific test scenaris r scripts that are t be executed, what types f testing are required (unit testing, integratin testing, user acceptance testing, etc.) and the way in which success r failure will be determined fr each test. 3.1.3.2. At a minimum, the test plan must include testing activities t verify that the change has the desired impact and that there has been n adverse impact t service stability. Additinal testing may be apprpriate fr cmplex r risky changes. 3.1.4. Test results must be dcumented in the tracking system. Page 7 f 12
3.2. Implementatin 3.2.1. s must nly be released in prductin when: 3.2.1.1. Test results are accepted by Institutin and IT stakehlders. 3.2.1.2. All tests have sufficiently passed. Any failed tests must have a clearly established remediatin plan r represent an acceptable level f risk that has been accepted by the Apprver. 3.3. Pst-Implementatin Review 3.3.1. A pst-implementatin review must be perfrmed by stakehlders t cnfirm the change is cmplete r t identify remaining issues. 3.3.2. The status f the change must be updated based n the results f the pstimplementatin review. 3.4. Regular review f Request status 3.4.1. The status f incmplete change requests must be regularly reviewed in CAB meetings, until the change is either dismissed r fully implemented. 3.4.2. An annual review f pen change requests must be perfrmed by the IT Manager t identify and fllw-up n ld RFCs that have nt been clsed. 4. Rles and Respnsibilities Stakehlder Respnsibilities Advisry Bard (CAB) Emergency Advisry Bard (ECAB) Apprver Review change requests, including their ptential impacts and level f risk. Prvide frmal apprval t implement change requests. Review change prgress with respect t the apprved schedule, and participate in Pst Implementatin Reviews. Prvide recmmendatins regarding the implementatin f changes int prductin, priritize change requests, and make decisin if any cnflict ccurs. Prvide recmmendatins t imprve r update this Plicy. Meet upn the request f the IT Directr. Review urgent change requests and: Cnfirm the level f urgency; Evaluate the ptential impacts and risks; Frmally authrize the implementatin f emergency changes where apprpriate; Ask fr additinal infrmatin where needed; and Make any ther decisins t address issues and cncerns. Review new IT change requests when they are submitted. Review the status f existing change requests. Chair the CAB meetings, including presentatin f the status f all change requests (new, pending, issues, cmpleted) and frmal dcumentatin f CAB meeting minutes r decisins. Ensure change requests are; Fllwing the present Plicy; Page 8 f 12
Stakehlder Respnsibilities IT Directr Manager Requestr Fully dcumented with all necessary details; Cmmunicated t the apprpriate stakehlders (IT Directr, administratrs and Implementer) fr cmment, befre presented t the CAB fr apprval; Presented t the CAB fr apprval (r the emergency CAB where applicable); and Addressed in a timely manner by the Implementer after CAB apprval. Cmmunicate with the Requestr and the Business t cnfirm specific aspects f the requests, as well as scheduling. Participate in the remediatin f any prblem, issue, incident and cnflict resulting frm a change by escalating t the right stakehlder r CAB meeting. Prvide recmmendatins regarding the implementatin f changes int prductin, priritize change requests, and make decisin if any cnflict ccurs. Prvide recmmendatins t imprve r update this Plicy. Chair the CAB meetings, including presentatin f the status f all change requests (new, pending, issues, cmpleted) and frmal dcumentatin f CAB meeting minutes r decisins. Prvide recmmendatins t imprve r update this Plicy. Verify the apprpriate classificatin f the change and evaluatin f the risks. Prepare the implementatin f the change request, including sme elements f analysis, wrk scheduling, design, build, test, and rll-back / back-ut activities. Test changes and reprt any issue r negative impact. Implement successfully tested and apprved changes int prductin. Update system dcumentatin. Reprt t the Apprver n the status f all changes assigned t her/him. Cmmunicate with the Apprver, the Requestr and any related key stakehlders t better understand the request fr change, reprt errrs, issues, r delay in testing r implementing the change. Escalate prblems and incidents resulting frm deplying changes. Participate in pst-implementatin reviews as required by the Manager. Initiates a Request fr (RFC) with the required details. Answer all additinal infrmatin required by the Reviewer, the Manager, IT stakehlders, r the CAB. Cmmunicate with business stakehlders t ensure business requirements are met. Participate in acceptance testing and pst implementatin reviews as required. Reviewer Assist the Manager by perfrming an initial review f the prpsed change requests as required, based n the technical aspects f the change, befre the change is submitted fr Apprval. Page 9 f 12
Stakehlder Respnsibilities IT Help Desk Supervisrs r Institutin representatives Users Respnd t any user requesting an IT. Verify the nature f the request and cnfirm if a frmal change request is necessary. Identify the change classificatin and immediately infrm the Manager r Incident Manager where necessary. Enter detailed infrmatin in the tracking system, including the name f the Requestr and descriptin f the change. Update the status f the change as required. Review any prblem, issue r need frm users that wuld require a new change request. Apprve new change requests initiated frm users. Cmmunicate with the IT grup t submit a new change request. Cntact the Help Desk fr any questins r cncerns related t the technlgy. When a questin r cncern cannt be addressed by the Help Desk, cntact their supervisr r representative. Cntact their supervisr r manager fr any request t change the existing technlgy. Page 10 f 12
APPENDIX 2 Appendix 2 Sample Request fr (RFC) Please cmplete and send t: IT Help Desk 1 General Infrmatin Sectin 1 Requested By Apprved by Supervisr/ Manager Date & Time f RFC Submissin Request Number Third party Supplier Prblem/Incident Ticket Number Peer/Technical Review r Suggested Apprvers Implementer Team/Name Classificatin 2 Brief Descriptin f the Request 3 Cnfiguratin Items Affected: 4 Items t be prcured Hardware Sftware Prfessinal Services Page 11 f 12
APPENDIX 2 5 Risk and Impact f nt Implementing this 6 Ptential Risk and Impact related t the Implementatin Business Risk Technical Risk Security Risks Cst 7 Schedule Requested Implementatin Start Date & Time Requested Implementatin End Date & Time Business Hurs r Out f Business Hurs (explain) 8 Implementatin Plan What / Wh / When / Where / Hw 9 Test Plan 10 Detailed Back-ut Plan 11 Cmmunicatin Plan 12 Other / Cmments Page 12 f 12