ICT Change Control

Version 1.0 October 2016

ICT Change Control

Target Audience

Who Should Read This Policy

All Trust Staff

Third party vendors requesting a change to the ICT infrastructure

ICT Change Control Policy

Version 1.0 October 2016 2

Ref. Contents Page

1.0 Introduction 4

2.0 Purpose 4

3.0 Objectives 4

4.0 Process 4

4.1 Where the Policy Applies 5

4.2 CAB Membership 5

4.3 Service Stakeholders 5

4.5 Service Requests: Standard Changes 8

4.7 Non-Compliance 10

5.0 Procedures connected to this Policy 10

6.0 Links to Relevant Legislation 10

6.1 Links to Relevant National Standards 11

6.2 Links to other Key Policies 12

6.3 References 13

7.0 Roles and Responsibilities for this Policy 14

8.0 Training 15

9.0 Equality Impact Assessment 15

10.0 Data Protection and Freedom of Information 15

11.0 Monitoring this Policy is working in Practice 16



Explanation of terms used in this policy Information Communication Technology (ICT) - Used as a collective term to describe all

systems and services associated with computers and data networks

IT Infrastructure Library (ITIL) – A collection of internationally recognised best-practices for

delivering ICT Services, covering all aspects of service provision, quality assurance, and providing a

framework which allows customisation of internal processes

Change Management - One discipline within the ITIL process framework which has the aim of

ensuring appropriate controls are placed around changes to ICT Systems and Services to mitigate risks, ensure stability, provide responsiveness to changing organisational requirements and minimise

service disruption

Change Advisory Board (CAB) - This body has no governance role, but is tasked with advising the Change Manager and Service Owner of the perceived impact of a requested change. This body is

made up of a core group with representation from all major ICT systems and the core ICT Services

teams, and incorporates required stakeholders depending on the nature of the RFC being assessed

Emergency Change Advisory Board (ECAB) - When urgent major changes arise there may not be time to convene the full CAB. For these cases an Emergency Change Advisory Board (ECAB) should be

identified with the authority to make emergency decisions. Membership of the ECAB may vary,

depending upon the different criteria relating to changes. RFC: Request for Change – an electronic form which initiates the Change Management process

Procedural Documents - the collective term for policies, procedures or guidelines

Policy - sets out the aims and principles under which services, divisions, or units will operate. A policy outlines roles and responsibilities, defines the scope of the subject covered, and provides a high level

description of the controls that must be in place to ensure compliance



1.0 Introduction The Black Country Partnership NHS Foundation Trust relies increasingly upon eHealth systems, business systems and the ICT Infrastructure in order to deliver patient care. The interdependencies of these systems are complex, and the results of changes made to one system may have serious consequences for the others. The uncontrolled implementation of changes to the Trust eHealth systems, business systems and IT Infrastructure utilised to perform its core business functions would present a significant risk to the organisation. Changing system requirements, resolution of known issues, implementation of new services and routine maintenance all require appropriate Change Management. Change Management ensures the stability of systems by the identification and mitigation of associated implementation risks and the minimisation of disruption to Trust operations caused by system outages, and consequently improves upon the services and service levels provided to the organisation.

2.0 Purpose The purpose of this policy is to mitigate any risks associated with implementation of changes to the Trust eHealth systems.

3.0 Objectives The Trust has adopted a policy of Change Management following the industry best-practice standards of ITIL – the IT Infrastructure Library. The principle objectives are to:

Outline the Change Management process, including its roles and accountabilities

Ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the Trust. This is done through a formal process of recording, assessment, authorisation, scheduling and with comprehensive communications around all changes

Provide the ICT Service with the ability to rapidly adapt as Trust requirements change, and increase their ability to ensure a customer focused operation is maintained

4.0 Process This policy includes all ICT related systems upon which any department or service within the Trust relies in order to perform their normal duties. All changes:

Require approval in advance of implementation in to the live environment

Must meet an agreed business need

Must be tested in advance as thoroughly as possible

Must be assessed for impact, risk and priority

Must be documented with all supporting documentation updated to reflect the change (this includes end-user documentation as well as service support documentation)

Must be submitted for approval using the electronic templates (RFC, Test and Back out). Only in exceptional circumstances may urgent/emergency changes



be made without the normal process and in any event they must be fully recorded in retrospect

Communications to the business must ensure that the effect of a change is properly made available to those who are significantly affected or need to know.

4.1 Where the Policy Applies

All changes to the Trust ICT related Systems are required to follow the established “ICT Change Management Process”, to ensure the mitigation of associated risks and minimise disruption to business critical services.

4.2 CAB Membership

Currently the CAB Membership includes: Change Manager, Relevant IT staff (ICT Service Delivery Manager, ICT Technical Project Manager, ICT Support Team Leader, and ICT Network Manager), Key Customers/Users, and ICT Managers, Technical consultants (internal or external). To conduct and complete a CAB or Emergency Change Advisory Board (ECAB) meeting requires at least 3 members. When urgent major changes arise there may not be time to convene the full CAB. For these cases an ECAB should be identified with the authority to make emergency decisions. Membership of the ECAB may vary, depending upon the different criteria relating to changes.

4.3 Service Stakeholders

For each service within the scope of this process, the key stakeholders will have been identified. This allows those stakeholders the opportunity to provide an assessment of any risks or impact from their perspective, and ensures they are notified of any changes which may affect the services they provide.

4.4 ICT Services Change Control Procedure 4.4.1 Step 1: Prepare and Post the Change Request Change Requests need to be identified before they can be subsumed under Configuration Management. In most ICT environments, they will result from such situations as:

Software Trouble Reports

User requests for system changes: hardware and infrastructure

User requests for application changes

User requests for additional products: hardware and software

Maintenance requests

Support requests

Design reviews

Relocation of items

Transfer of items to new responsible person(s)

Upgrades initiated by developers

Upgrades initiated by suppliers

Changes in documentation In all the above cases, the person issuing the Change Request should define the data needed to post the request. This is grouped under the following headings: 1. Enter the particulars of the request: source, date, code, etc. 2. Classify the request according to its nature:



The source of the request should identify the type of change that is being requested. (Note that this is more specific than the sources of Change Requests defined above). The following are typical types for Change Requests:

New item

Removal of item

Change of Location

Change of Responsible

Change of Parent Item

Minor Bug

Major Bug or Error

Minor enhancement

Major change in software

Major Parameter changes

Upgrade of software (Release, version, etc.)

Software Patch 4.4.2 Document and justify the request: the problems it resolves, the

opportunities it creates, the policy it follows, etc. 4.4.3 Evaluate the impact consequences of change In most cases, changes to the Configuration do not really impact the overall Information System. Examples: moving a PC from one room to another, uninstalling a spreadsheet, etc. In other cases, the change being requested can have a major operational, administrative and/or financial impact. Observe the following:

Acquire new PC

Upgrade all PCs from Windows 7 to Windows 10

Develop a new report generator

Convert Database from one version of SQL to another It is critical for the Change Advisory Board to have such impacts properly analysed and assessed in order that it may have the proper grounds upon which to base its approval decision. 4.4.4 Estimate the time and cost needed to carry out the change 4.4.5 Define the party responsible to carry out the change 4.4.6 Step 2: Submit Request to Change Advisory Board

The posted request must now be submitted to the Change Advisory Board. The Service Request Form should be sent to the members of the Change Advisory Board via the ICT Services helpdesk for their review. A unique RFC number (or Incident number in the case of a request for information RFI) will be allocated to the form and data entered onto the ICT Services Helpdesk system. The Change Advisory Board (at weekly meeting) completes the assessment of the Request for Change /Request for Information and based on the submitted documentation. The outcome of the assessment will be one of the following options:

Request a Technical Review

Request further analysis of the Request



Approve the Approved Change Request

Reject the Change Request

Suspend the Request Each of these steps is clarified in the following sections. 4.4.7 Step 3: Request a Technical Review The Change Request needs to be submitted with all required technical information. However, the CAB may decide to have further review on some technical issues. It routes the Request to this step and after the results of the Technical Review are completed by the concerned parties, the Change Request is rerouted back to Step 4.9.6 4.4.8 Step 4: Request Further Analysis and Information The Change Request will need to be submitted with all required information. However, the CAB may decide to have further review on some other issues such as different options, additional costing analysis, impacts, etc. It routes the Request to this step and after the additional analysis is completed by the concerned parties, the Change Request is rerouted to Step 4.9.6. 4.4.9 Step 5: Approve the Request for Action The CAB will issue an approval for the Request and route it to step 4.9.10 where the action will be completed. At this stage, the Helpdesk system is updated and any CAB notes added. This is then passed over to the applicable manager to allocate the work required to the appropriate party who will complete the change as per the next step. 4.4.10 Step 6: Implement the Change The request has been approved; the related party will complete the change as requested in the Change Order form. 4.4.11 Step 7: Verify the Change As per Quality Management principles, since clearly documented changes would have been stated, it should be possible to verify that such changes have actually been carried out. Steps 4.9.10 and 4.9.11 are a cycle. The Change Control mechanism expects the Change to be properly completed. If not, the cycle reverts back to Step 4.9.9 and so on. 4.4.12 Step 8: Update the Configuration Database On completion of step 4.9.11, the Configuration Data records need to be updated. Updating includes such information as relevant dates, costs, work done, etc. This will be of use should similar changes be required in the future. This step is also reached when a Request is rejected (See Step 4.9.14) to document the rejection and its reasons. 4.4.13 Step 9: Close the Request On completing the change and updating the database records, the Change Request status should be changed to “Closed”. 4.4.14 Step 10: Reject the Change Request The CAB may select to reject the Request for a variety of reasons. It will inform the source of the request and proceed to Step 8 to update the database by entering such data as reason for rejection, date of rejection, etc.



4.4.15 Step 11: Suspending the Request The CAB may also select to suspend the Request. This may happen in situations when it has no clear path to take. The request may be too early or too costly, etc. However, it is not to be rejected. This is a step that also leads to Step 8 where the database will be updated by changing the status of the Request to “Suspended”, entering the reasons for such suspension. The source of the request is then informed of the decision. CAB Process

4.5 Service Requests: Standard Changes

4.5.1 Defining Service Requests, Standard Changes The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the ICT Department by the users. Many of these are actually small changes – low risk, frequently occurring, low cost, etc. (e.g. a request to change a password, a request to install additional software application onto a particular workstation, a request to relocate some items of desktop equipment) or maybe just a question requesting information – but their scale and frequent, low-risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes. 4.5.2 What are its goals and objectives? Request Fulfilment is the processes of dealing with Service Requests from the users. The objectives of the Request Fulfilment process include:

Pre-Approved Standard Changes which cost the organisation

Pre-Approved Standard Changes with no direct cost

Information point for existing services, RFI (Request for Information) 4.5.3 Pre-Approved Standard changes which cost the organisation A service request is given a category for the call and processed based on the request and type, such as an External Move, (a request to move PCs to another building) based on the solution costs may be occurred in provision of networking when moving of the PCs to the new building, the ongoing costs for the line etc. Or another example could be – Changing Owner (a request to change the owner of a Blackberry) due to the recurring costs to the organisation for the BlackBerry, does the budget code need to change also (see finance and funding)?



Stage 0 – Categorise call and process based on request This would be done primarily at Service desk level. Following discussion with the end user regarding what is required the Service desk would categorise as above and log the call accordingly. Where it is not clear what category is appropriate, this should be passed to ICT Service Delivery Manager for clarification. It may be that what is being asked has not previously been pre-approved and would therefore need to go through Normal Change Advisory Board process for approval, and a subsequent change template created. Stage 1 – Relevant standard Change Template completion Each service request category has a change template which has been pre-approved by the Change Advisory Board. This is to ensure that services and solutions offered are compliant with relevant standards i.e. ISO 27001, 27002, 27005 and 27006. All information requested needs to be supplied to ensure compliance with CAB Template; sometimes this will be filled in by the Service desk with input from the user other times this will be submitted by the user. Stage 2 – Evaluate Cost, Risk This stage is primarily focused on cost effectiveness, i.e. should we replace a full computer if there is only an issue with 1 component which costs 1/10th of the cost of a full system. What about the failure rate of that component, is there a strong likelihood that the component will fail again in the near future? Is the PC in high demand? Is the person able to use another machine? Stage 3 – Seek Financial approval (if required) Any replacement equipment required or the change itself may attract additional funding and therefore appropriate approval to purchase the equipment or service (if required). If this is the case, then the normal organisation procurement process is to be adhered to. 4.6 Emergency Change Control Procedure Overview of Change Process – Emergency/Crisis Change: A crisis occurs when SLA‟s, patient care or business functions cannot be maintained within the time limits as agreed upon in the document. A Crisis Manager (CM) is appointed and placed in charge of resolving the situation. CM is given the responsibility and granted resources necessary to resolve the issues during the emergency. It is important to note that all activities are required to be logged throughout the duration of the crisis. 4.6.1 The Helpdesk or Information owner submits a critical incident. (An information

owner is defined as the person responsible for an application)

4.6.2 To track the request the Help desk creates a ticket on the helpdesk system, and notifies ICT management. The Crisis Manager retains control of the Ticket through to resolution of the incident and is responsible for organising all resources necessary to solve the crisis.

4.6.3 The Crisis Manager performs: i. A limited risk assessment and a priority level (1.Catastrophic, 2.Urgent,

3.High, 4.Medium, 5.Low) which is based on: urgency – the number of affected users II. Severity – importance of a service for business Processes.



ii. Inventory – register all facts and activities that have led up to the crisis. iii. List all potential causes that could have created the crisis. iv. Crisis Manager initiates communication with appropriate affected

managers. v. ICT team tests, evaluates and documents the required change. vi. ICT team implements change. vii. ICT team reviews and monitors the change. If problems still exist continue

back to step V. viii. ICT documents all changes. ix. Post Change report to include:

a. Full review and analysis of escalation is published. The report covers history, approach, activities, causes, solutions and recommendations

b. Evaluation of all actions performed during the crisis c. Document actions required for a permanent solution.5.0 Non-

Compliance

4.7 Non-Compliance

Failure to comply with this policy may cause major delays to the implementation of new systems or changes to existing systems being completed. 4.7.1 Reporting an Incident All incidents or suspected incidents involving unauthorised access to resources and/or the mismanagement of information, databases, networks, etc. should be reported on DATIX the Trust’s electronic Incident Reporting System, which is accessible through remote access networks.

5.0 Procedures connected to this Policy

ICT Change Control - SOP 01- Risk Assessment and Disaster Recovery

ICT Change Control - SOP 02 - Backup Process

ICT Change Control - SOP 03 – Procurement and Asset Management 6.0 Links to Relevant Legislation

The Data Protection Act 1998 The Act came into force in 1984 and was updated in 1998. The Act sets out rules for people who use or store data about living people and gives rights to those people whose data has been collected. The law applies to data held on computers or any sort of storage system, even paper records. The law covers personal data such as your address, telephone number, e-mail address, job history etc. The main principles of the Act are: - If you collect data about people for one reason, you must not use it for a

different reason; - You must not give people's data to other people or organisations unless they

agree; - People have the right to look at data that any organisations store about them; - You must not keep the data for longer than you need to and it must be kept up

to date; - You must not send the data to places outside of the European Economic Area

unless adequate levels of protection exist;

https://simple.wikipedia.org/wiki/Information

https://simple.wiktionary.org/wiki/right

https://simple.wikipedia.org/wiki/Computer

https://simple.wiktionary.org/wiki/principles

https://simple.wiktionary.org/wiki/organization

https://simple.wikipedia.org/w/index.php?title=European_Economic_Area&action=edit&redlink=1



- Organisations that store data about people must register with the Information Commissioner’s Office;

- If you store data about people you must make sure that it is secure and well protected;

- If an organisation has data about you that is wrong, then you have a right to ask them to change it

The Computer Misuse Act 2000 The Act is a law first introduced in 1990 to try to fight the growing threat of hackers and hacking. The law has three parts, it is a crime to: - Access a computer without permission

there must be intent to access a program or data stored on a computer, and the person must know that this access is not authorised. This is why login screens often carry a message saying that access is limited to authorised persons: this may not prevent a determined and ingenious hacker getting access to the system, but they will not be able to claim ignorance of committing an offence

- Access a computer without permission, with intent to commit a further offence there must be intent to access a program or data stored on a computer, and the person must know that this access is not authorised. This is why login screens often carry a message saying that access is limited to authorised persons: this may not prevent a determined and ingenious hacker getting access to the system, but they will not be able to claim ignorance of committing an offence

- Change, break or copy files without permission Altering data as in the case of a nurse who observed a doctor entering his password and used it to alter patients' drug dosages and treatment records Removing data for instance to cover up evidence of wrongdoing Adding to the contents of a computer for instance it has been held that sending an email under a false name results in unauthorised modifications to the content of the mail server

The intent need not be directed at any particular computer, program or data, so this provision covers damage caused by computer viruses - even though the virus author need not have known or intended that any particular system would be affected.

6.1 Links to Relevant National Standards NHS Connecting For Health Good Practice Guidelines The Good Practice Guidelines are a series of informational documents which provide good practice advice in technology-specific areas of Information Security and Information Governance. Each Good Practice Guideline is intended to support Department of Health Policy and Information Governance requirements for NHS organisations and suppliers. Information Security Management: NHS Code of Practice (April 2007) The Code of Practice is a guide to the methods and required standards of practice in the management of information security, for those who work within or under contract to, or in business partnership with NHS organisations in England. It is based on current legal requirements, relevant standards and professional best practice. It is part of an evolving information security management framework because risk factors, standards and practice covered by the Code will change over time. The guidelines contained within the Code of Practice apply to NHS information assets of all types.

https://simple.wikipedia.org/wiki/Hacker

https://simple.wikipedia.org/wiki/Hacking

https://simple.wiktionary.org/wiki/crime

https://simple.wiktionary.org/wiki/permission



NHS Confidentiality Code of Practice (November 2010) The Code sets out the required standards of practice concerning confidentiality and patients' consent to use their health records. It is a guide for those who work within or under contract to NHS organisations and is based on legal requirements and best practice. The Caldicott Guidelines The Caldicott Report (December 1997) was a review commissioned by the Chief Medical Officer to make recommendations to improve the way the National Health Service handles and protects patient information. The Caldicott Committee was set up to review the confidentiality and flows of data throughout the NHS for purposes other than direct care, medical research or where there is a statutory requirement for information. The report identified 6 principles, similar in many respects to the principles outlined in The Data Protection Act. 1. Justify the purpose(s) for using patient data 2. Don't use patient-identifiable information unless it is absolutely necessary 3. Use the minimum necessary patient-identifiable information 4. Access to patient-identifiable information should be on a strict need to know

basis. 5. Everyone should be aware of their responsibilities to maintain confidentiality. 6. Understand and comply with the law, in particular the Data Protection Act. 6.2 Links to other Key Policies ICT E-mail and Internet Acceptable Use Policy The purpose of this policy is to clearly define the acceptable usage and standards that apply to all Trust and NHS e-mail and internet Systems by employees and all other sponsored/ authorised individuals. ICT Remote Access Policy The aim of this policy is to set out the security measures, practices and restrictions in place to minimise the risks for connecting to Black Country Partnership NHS Foundation Trust’s internal network from external hosts via remote access technology, and/or for utilising the Internet for business purposes via third-party Internet service providers.

ICT Portable Devices and Portable Media Security Policy The aim of this policy is to ensure the security of the Black Country Partnership NHS Foundation Trust portable data devices. ICT Telecommunications Policy The purpose of this policy is to set out the key principles regarding the use of Telecommunications equipment within the Trust. ICT Priority 1 Incident Handling Policy The purpose of this policy is to define the actions, communications and escalation steps that are to be used to manage a Priority 1 incident for all staff within ICT Services.



ICT Security Policy The purpose of this policy is to provide management direction, support and outline how information security is managed throughout the Trust. The approach adopted conforms to ISO standard 27000, specifically relating to Information Security Management Systems (ISMS). The policy also aims to develop a positive culture of information security throughout the Trust.

6.3 References

The Caldicott Guidelines

ISO 27001 The Code of Practice for Information Security Management

Ensuring Security and Confidentiality in NHS Organisations (E5498)



7.0 Roles and Responsibilities for this Policy

Title Role Key Responsibilities

Change Manager Operational

- Accountable for the overall process operation - Monitor the process to identify and rectify issues and remove bottlenecks

- Chair the weekly Change Advisory Board (CAB) meetings - Perform the tasks related to updating the Request for Change (RFC) records, categorisation and reporting of change

metrics

System Manager / IT Technical Lead

Operational

- For each system within the scope of this process, the System Manager/Technical Lead is the person identified as having

accountability for continued system operation - Take part in the assessment of all RFCs affecting their service

- Accountable for authorisation of those RFCs, where required

CAB Operational - Review all requested changes and provide a rigorous assessment of the expected business and technical risks associated

with the RFC

- Provide feedback as to the requested implementation schedule, ensuring minimisation of undesired interactions of changes

ICT Service Delivery

Manager Operational - Deal with requests for approval for urgent changes in the event that the core CAB is unable to meet

Line Managers

Implementation

- Consider all applications for change management

- Complete the change control form

ICT Manager

Implementation

Lead

- Ensure a robust framework is in place so the Trust complies with national legislation and guidance relating to ICT security

- Ensure that Groups are fully informed of their role in maintaining the required standards of practice relating to change

control - Policy lead/author of this policy

Information

Governance Steering Group

Scrutiny and Performance

- Oversee the governance of information management across the Trust - Receive incidents, breaches and specific issues in relation to the delivery, development and monitoring of ICT information

management systems

- Review all policies, guidelines and procedures relating to information and ICT

Director of Strategy, Estates and ICT

Executive Lead

- Lead responsibility for the implementation of this policy

- Allocate resources to support the implementation of this policy

- Chair of the Trust’s Information Governance Steering Group - Ensure any serious concerns regarding the implementation of this policy are brought to the attention of the Board of

Directors



8.0 Training

What aspect(s)

of this policy will require staff

training?

Which staff groups require this

training?

Is this training covered in the Trust’s Mandatory and Risk

Management Training Needs Analysis document?

If no, how will the training be delivered?

Who will deliver the training?

How often will staff require

training

Who will ensure and monitor that staff have

this training?

n/a n/a n/a n/a n/a n/a n/a

9.0 Equality Impact Assessment

Black Country Partnership NHS Foundation Trust is committed to ensuring that the way we provide services and the way we recruit and treat staff reflects individual needs, promotes equality and does not discriminate unfairly against any particular individual or group. The Equality Impact Assessment for this policy has been completed and is readily available on the Intranet. If you require this in a different format e.g. larger print, Braille, different languages or audio tape, please contact the Equality & Diversity Team on Ext. 8067 or email [email protected]

10.0 Data Protection and Freedom of Information

This statement reflects legal requirements incorporated within the Data Protection Act and Freedom of Information Act that apply to staff who work within the public sector. All staff have a responsibility to ensure that they do not disclose information about the Trust’s activities in respect of service users in its care to unauthorised individuals. This responsibility applies whether you are currently employed or after your employment ends and in certain aspects of your personal life e.g. use of social networking sites etc. The Trust seeks to ensure a high level of transparency in all its business activities but reserves the right not to disclose information where relevant legislation applies.



11.0 Monitoring this Policy is working in Practice

What key elements will be monitored?

(measurable policy objectives)

Where described in

policy?

How will they be monitored?

(method + sample size)

Who will undertake this

monitoring?

How Frequently?

Group/Committee that will receive and

review results

Group/Committee to ensure actions

are completed

Evidence this has

happened

Application Process for

change control is working effectively

Throughout

the document

Application requests

submitted to ICT department

ICT Department

Annually

Information


Information


Reports and

Minutes of Meetings

All incidents relating to non-compliance and / or

breaches in security arising from remote access

Throughout

the document

DATIX, the Trust’s electronic incident

reporting system

ICT Department

Annually

Information Governance Steering

Group

Information Governance

Steering Group

Reports and Minutes of

Meetings



Policy Details

* For more information on the consultation process, implementation plan, equality impact assessment,

Or archiving arrangements, please contact Corporate Governance

Review and Amendment History

Version Date Details of Change

1.0 Oct 2016 New Policy for BCPFT

Title of Policy ICT Change Control Policy

Unique Identifier for this policy BCPFT-ICT-POL-01

State if policy is New or Revised New

Previous Policy Title where applicable n/a

Policy Category Clinical, HR, H&S, Infection Control etc.

ICT

Executive Director whose portfolio this policy comes under

Director of Strategy, Estates and ICT

Policy Lead/Author Job titles only

ICT Manager

Committee/Group responsible for the approval of this policy

Information Governance Steering Group

Month/year consultation process completed *

August 2015

Month/year policy approved February 2016

Month/year policy ratified and issued October 2016

Next review date October 2019

Implementation Plan completed * Yes

Equality Impact Assessment completed *

Yes

Previous version(s) archived * Yes

Disclosure status ‘B’ can be disclosed to patients and the public

Key Words for this policy ICT, ISO, Change, CAB