GEM CSU - IT Services Change Control Policy

Transcription

1 Please note, once downloaded or printed, the document will be deemed as uncontrolled and its validity should be checked prior to use. This document is due for review by the date shown below. After this date, policy and procedure documents may be invalid and may pose a security risk. Please contact the department below immediately. GEM CSU - IT Services Change Control Policy Document Control Sheet Document name GEM CSU IT Services Change Control Document Reference DP-SM-IG-3 Subject Area Assurance and Compliance Category Information Governance Status Final Locality GEM Wide Version v 2.1 Author Neil Ford Approved by Andrew Wall Department Information Governance Target Audience Date December 2014 Further copies from Greater East Midlands Commissioning Unit Quality Assurance by: Information Governance Steering Group Review Date: Oct 2015 Page 1 of 9

2 Document History Document Location The source of the document will be found in the locations below: Electronic Copy Policies and Procedures SharePoint Site Revision History Revision Revisio n Date V V Date of next revision: Summary Of Changes Change Author Changes Marked Minor changes to reflect organisational change Additional information added to Section 4.1 Minor changes to numbering of sections Teresa Jennison Neil Ford No No V Changes post IG review Andrew Wall No Approvals This document requires the following approvals. Name Signature Job Title A Wall Associate Director of IT Service Delivery Date of Issue Version Distribution This document has been distributed to: Name GEM Job Title Date of Issue Version Clients Page 2 of 9

3 Table of Contents Document History Scope of Policy Responsibilities / Deliverables Change Advisory Board Change Requestor Change Owner Change Approval Change Database Maintenance Windows Risk Analysis / Classification Change Control Accountable Matrix Change Classifications Risk Actions Process / Procedure Linked Activities / Processes Equality Impact Assessment Freedom of Information Appendix 1 - Change Control Process... 9 Page 3 of 9

4 1. Scope of Policy This policy is restricted to systems and services managed by GEM CSU IT Services. National Systems covered under the remit of nationally procured and managed programmes are subject to their own change control mechanisms and are therefore outside the scope of this policy. This change control policy covers modifications and enhancements to infrastructure systems and services. It is vital to the smooth operation of the services that these modifications are handled in a controlled manner using a standardised process. It must be noted that change control is used to asses risks and take steps to minimise them. It cannot prevent failures occasionally occurring during a change. 2. Responsibilities / Deliverables 2.1 Change Advisory Board The GEM CSU IT Services Change Advisory Board (CAB) will determine and approve the processes to be adhered to in respect of change. The current process for change is documented at Appendix 1. The GEM CSU IT Services Change Advisory Board will be responsible for the overall approval and monitoring of change to the environments in scope for this policy. The change advisory board will meet on a regular basis to approve and monitor change. 2.2 Change Requestor Anyone who has a perceived need to modify a component of the live system/service infrastructure is a potential requester, i.e., all system owners and all users of the trust s computer network and information systems. A change requester is responsible for consulting with the system owner or governing body to consider a potential change request, and being available for the change owner to consult with during the change process. 2.3 Change Owner A change owner is the person tasked with completing a Request for Change form in conjunction with the requester. The change owner must complete the form after consultation with any stakeholders or parties affected by the change or required in order to make the change. The change owner is then responsible for managing and controlling the implementation of the change. The change owner must also ensure that all testing and documentation associated with the change is complete before the change request can be signed off by the change approver, and closed. Page 4 of 9

5 2.4 Change Approval Approval for change will vary dependant on the resultant risk/classification of change. See Section 4 for roles that can act as change approval. A change approver can be external to GEM CSU (a system owner), but must comply with the terms laid out in this policy. The change approver or change advisory board may: 1) Accept and approve a change request 2) Pass it back to the requester for amendments 3) Reject it 2.5 Change Database A database of all changes, approved and rejected shall be maintained and linked to the GEM CSU service desk. The Change Advisory Board has responsibility for the design, functionality and content recorded in the GEM CSU Service Desk. All documentation relating to changes proposed, undertaken or rejected will be stored in the change database. 3. Maintenance Windows Wherever possible; changes that require an interruption to the service must be implemented within defined maintenance windows. 4. Risk Analysis / Classification The GEM CSU risk analysis process should be followed for each new change. The severity of adverse effects of the proposed change need to be weighed against the probability of that adverse effect from taking place. This determines who is required to sign-off the request for change. The risk and classification of the change must be recorded in the request for change. As each change will probably have several risks associated with it, each risk will need analysing. The highest risk within that change determines that overall risk for the whole change. Page 5 of 9

6 4.1 Change Control Accountable Matrix All changes will be signed off by the appropriate service teams. Minor Senior Officer Section leader and the responsible Operational Manager. Moderate Senior Officer and section leader (or higher) Section leader and the responsible Operational Manager. CAB Major CAB Severity Low Medium High Probability Minor if an adverse effect of the proposed change occurs, it will not inconvenience any service users. Consider the change effects on other systems and potential cascade changes. Examples Small number of devices, cosmetic changes to appearance of a system. Take into account any cascade effects of this change. Moderate - if an adverse effect of the proposed change occurs, it could inconvenience users of the system being changed. Examples - Changes affecting a small number of users of a small system, changes to a PC build image. Take into account any cascade effects of this change. Major - if an adverse effect of the proposed change occurs, it could affect multiple systems or inconvenience many users. Examples Network or policy changes affecting many or all users, business critical systems such as clinical or major financial systems. The priority assigned to a change will influence the activities performed in implementing the change, the level of controls applied to the change and the timing and approval for the change. 4.2 Change Classifications A change is an event that results in a new status to any live system or configuration item. Page 6 of 9

7 Change may be classified in the following ways: Standard Change Requires a minimum of seven days notice of any outage Emergency Change May have little notice of an outage For practical purposes high volumes of small changes (e.g. user permissions, system access, and database field additions) would be time consuming to process through change control and will be formally listed as exceptions in the change control process document. Deployment and Support technicians installing software on individual PCs is also covered under the software installation policy and therefore have already been authorised through change control. Development systems/ proof of concepts/testing will be exempt from the change control policy, unless they interact directly with a live system. Change control will be applied at the point of making the development live. 5. Risk Actions Once a risk has been identified, it is up to GEM CSU to make the change as risk free as possible. Management of the risks should include one or more of the following actions:- * Decide not to take the risk this could mean not implementing the change at all as the possible impact of adverse effects are too severe. * Find an alternative this should mean revisiting the proposed change and modifying it so as not to include the high risk element. * Create a contingency If a risk cannot be worked around, then a plan must be put in place to deal with the consequences, including a back out plan. The above analysis and management of each risk will be made and documented in the service desk prior to the change control being authorised. It is the responsibility of the change authoriser to review all identified risks, the contingency/ mitigation of said risks and identify any additional risks. 6. Process / Procedure This policy covers all aspects of change including initiation, documentation, decision and implementation. The overall change control process is outlined at Appendix 1 Change Control Process. 7. Linked Activities / Processes All changes should be made in accordance with GEM CSU release management and configuration management policies and procedures. Page 7 of 9

8 8. Equality Impact Assessment We welcome feedback on this Policy and the way it operates. We are interested to know of any possible or actual adverse impact that this Policy may have on any groups in respect of gender or marital status, race, disability, sexual orientation, religion or belief, age, deprivation or other characteristics. 9. Freedom of Information This policy is regarded as potentially exempt under Section 43 (commercial interests) of the Freedom of Information Act (FOI). Should any organisation receive an FOI request linked to this policy IT Services should be contacted to discuss whether release is appropriate. Page 8 of 9

9 10. Appendix 1 - Change Control Process Change Control Process Reason of Request for a Change Is the change actually require? Yes Design the change Test the change Prepare rollback plan or Contingencies Record Request for Change on GEM CSU Service Desk No Risk Asses Change Is it 1, 2 or 3? Aborted because of risks Update GEM CSU Service Desk with lessons learnt Evaluated by accountable team Rejected Update change on GEM CSU Service Desk with reasons for rejection Approved Notification IM&T Leads & Users (Via CST) Implement Change Rollback plan or Contingency Invoked No Sucess Yes Update GEM CSU Service Desk with lessons learnt End Page 9 of 9