ITPOL12 IT Change Management and Control Policy by Provide Community

IT Change Management and Control Policy

Version: V3

Ratified by: Finance & Investment Committee

Date ratified: 03/04/2024

Job Title of author:

Assistant Director – IT & Systems

Reviewed by Committee or Expert Group Technology Programme Group

Equality Impact Assessed by:

1. Introduction

The Technology Programme Board and Provide management teams recognise the importance of having robust change management and control processes to ensure that changes are made in a secure, safe and professional manner to mitigate the associated risks of change such as:

• Data being corrupted or lost

• Reduction in performance or loss of IT services

• Reputational risk

2. Purpose

The change management policy is designed to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes in IT systems. Its purpose is to minimise the impact of change-related incidents on service quality, and consequently to improve the day-to-day operations of the organisation. By managing changes systematically, the policy aims to reduce risks and errors, ensure that changes are recorded and evaluated, and maintain service stability while accommodating necessary updates and improvements.

3. Scope

This policy applies to all changes made by members of the Provide Technology Team, contractors or staff working on behalf of the Provide Technology Team and all changes being made to the Provide owned or managed infrastructure, regardless of who is making them. No employee is exempt from this policy.

For the purposes of this document and the associated change control processes, a change is defined as; ‘an action that adds to or modifies the operating environment or standard operating procedures in any way, this includes all Provide managed or hosted systems or services that have the potential to have an effect on the stability, availability or reliability of the Provide IT infrastructure or environment’.

Changes may be required or triggered for a variety of reasons which include:

• User requests

• Cyber essentials recommendations

• Changes in regulations

• Hardware or software failure

• Modifications to the Provide infrastructure

• Environmental changes

• Unforeseen events

• Planned maintenance

4. Duties

All aspects of the change control process will be clearly defined and formally documented, with all processes and policy being reviewed every 3 years. Both the processes and the policy will clearly define roles and responsibilities relating to change control.

In order to fulfil this policy, the following statements must be adhered to:

5. Procedures and Documents

A process document will be maintained for the different changes and clearly qualifies what each change category includes, the process for applying for a change and the required documentation required for each change.

Each change will require approval of a completed Request for Change (RFC) form before it can be implemented.

All RFC forms will be logged via the Change Management platform within FreshService. All details related to the change including the outcome will be kept within FreshService.

6. Types of Change

To enable changes to be responded to with the appropriate level of checks and controls, all changes will be categorised into one of the following categories:

• Minor (Normal) Change

• Major (Normal) Change

• Emergency Change

7. Definitions

Minor (Normal) Change

Changes that don’t have a major impact, which is less risky and undergo every stage in a change lifecycle including CAB approval are called minor changes. (e.g. updating background wallpaper GPO.)

Major (Normal) Change

Changes that can have medium to high impact on ongoing business operations and may have financial implications which require CAB approval, as well as management approval, are called major changes. (e.g. Migration from one data centre to another)

Emergency Change

Changes that need immediate fixes and Emergency CAB approval where the review is completed later to avoid potential risks are called emergency changes. (e.g. Critical Security Patch)

Testing

Where feasible, all changes should be tested in an isolated environment that is representative of the live environment to allow the impact of the change to be observed prior to implementation into the live environment.

Testing should include as a minimum, an assessment of the impact on relevant business processes, usability, security and performance with all significant findings being documented on the RFC.

Releasing changes to a small pilot group of devices should be considered where this is possible, especially where it is not possible to test the change prior to release. The pilot group should be representative of the users that could be impacted by the change, theses pilot users should be able to feedback and comment on the impact of the change prior to approval of the change.

9. Version Control

All software updates will be controlled with version control, where feasible and always when required by Information Governance (IG) policies, copies of previous versions should be retained.

10.Approval

All changes must be approved prior to implementation, this will require the full completion of a RFC and approval of the RFC by the relevant Change Advisory Board(s) (CAB) or Emergency Change advisory Board (ECAB). Results of testing the change and details of the fall-back plan should be assessed by the CAB or ECAB prior to any approval being made.

The CAB or ECAB should assess the impact of each change on other related documents, such as:

• Business Continuity Plans

• Disaster Recovery Plan

• Disaster Recovery Procedure

• IT Software Management Policy

• IT Hardware Asset Management Policy

11.Communications

All users that could be significantly affected by a change should be notified of the change and the potential impacts. Communications should be planned in advance of the change whenever this is possible and use the organisations existing communication channels that users will be familiar with. Communication plan should be reviewed within the RFC.

12.Contracts

The impact of change on existing contracts should be considered when planning a change, where there is likely to be a change that will affect the organisations contractual obligations (including the delivery of KPI’s), the Contract Team and Associate Director for the affected area(s) should be consulted prior to approval of the change

13.Roll Back

A plan for recovering form unsuccessful changes should be included as part of the RFC, where a change is assessed as being of high risk, a separate document may be required to document the fall-back plan dependant on the point or time of failure.

14.Monitoring

The change process will not be considered as complete at the point that the change is released, there will first need to be a period of monitoring to ensure that the change has been fully implemented as expected. To support this, staff making the changes should not have any planned leave immediately after the change.

Any issues or deviations from the outcome described in the RFC form will be escalated to the change sponsor and should be resolved prior to formal closure of the change log.

15.Roles and Responsibilities

To enable IT hardware management to work effectively, staff at all levels within Provide will need to play their part, some of the key responsibilities are listed below:

Executive Directors

• Responsible for ensuring procedures are in place within their directorates that ensure staff are aware of their responsibilities contained within this policy and that these responsibilities are adhered to.

Assistant Director of IT & Systems

• Implementation and regular review of this policy.

• Regular review of change management and control standards, with the input of relevant stakeholders.

• Leading investigations into reported breaches of this policy.

• Communication of the requirements to other directorates

Technology Operations Manager

• Responsible for ensuring details of all applicable IT assets are kept up to date on the CMDB and IT Asset Register.

• Implement, maintain and update the change control processes and related documentation.

• Ensuring that this policy is fully understood by all staff that are involved in the change management process.

• Facilitate and coordinate the necessary change management and control initiatives in conjunction with the Information Governance and Projects Manager.

• Coordinate the implementation of new or additional security controls for change management in conjunction with the Information Governance and Projects Manager.

• Ensure compliance of this policy and report deviations to the Assistant Director of IT & Systems.

• Provide expert technical advice and support to the change management and control process.

Information Governance and Projects Manager

• Facilitate and coordinate the necessary change management and control initiatives in conjunction with the IT Operations Manager.

• Coordinate the implementation of new or additional security controls for change management in conjunction with the IT Operations Manager.

• Ensure that the change management and control process is compliant with all Information Governance requirements and best practice.

End Users and Services

• Submissions of requests through the appropriate systems.

• Participating in testing, both pre and post deployment.

• Timely sign-off of the change where this is required.

EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 1: ‘Screening’

Name of project/policy/strategy (hereafter referred to as “initiative”):

IT Change Management and Control Policy

Provide a brief summary (bullet points) of the aims of the initiative and main activities:

To ensure updates to Provide computers take place in a controlled and well managed way, ensuring devices are kept up to date with minimal disruption to end users.

Project/Policy Manager: AD – IT & Systems

Date: 30/11/2023

This stage establishes whether a proposed initiative will have an impact from an equality perspective on any particular group of people or community – i.e. on the grounds of race (incl. religion/faith), gender (incl. sexual orientation), age, disability, or whether it is “equality neutral” (i.e. have no effect either positive or negative). In the case of gender, consider whether men and women are affected differently.

Q1. Who will benefit from this initiative? Is there likely to be a positive impact on specific groups/communities (whether or not they are the intended beneficiaries), and if so, how? Or is it clear at this stage that it will be equality “neutral”? i.e. will have no particular effect on any group.

All staff will benefit equally

Q2. Is there likely to be an adverse impact on one or more minority/under-represented or community groups as a result of this initiative? If so, who may be affected and why? Or is it clear at this stage that it will be equality “neutral”?

Neutral

Q3. Is the impact of the initiative – whether positive or negative - significant enough to warrant a more detailed assessment (Stage 2 – see guidance)? If not, will there be monitoring and review to assess the impact over a period time? Briefly (bullet points) give reasons for your answer and any steps you are taking to address particular issues, including any consultation with staff or external groups/agencies.

N/A

Guidelines: Things to consider

Equality impact assessments at Provide take account of relevant equality legislation and include age, (i.e. young and old,); race and ethnicity, gender, disability, religion and faith, and sexual orientation.

The initiative may have a positive, negative or neutral impact, i.e. have no particular effect on the group/community.

Where a negative (i.e. adverse) impact is identified, it may be appropriate to make a more detailed EIA (see Stage 2), or, as important, take early action to redress this – e.g. by abandoning or modifying the initiative. NB: If the initiative contravenes equality legislation, it must be abandoned or modified.

Where an initiative has a positive impact on groups/community relations, the EIA should make this explicit, to enable the outcomes to be monitored over its lifespan.

Where there is a positive impact on particular groups does this mean there could be an adverse impact on others, and if so can this be justified? - e.g. are there other existing or planned initiatives which redress this?

It may not be possible to provide detailed answers to some of these questions at the start of the initiative. The EIA may identify a lack of relevant data, and that data-gathering is a specific action required to inform the initiative as it develops, and also to form part of a continuing evaluation and review process.

It is envisaged that it will be relatively rare for full impact assessments to be carried out at Provide. Usually, where there are particular problems identified in the screening stage, it is envisaged that the approach will be amended at this stage, and/or setting up a monitoring/evaluation system to review a policy’s impact over time.

EQUALITY IMPACT ASSESSMENT TEMPLATE: Stage 2:

(To be used where the ‘screening phase has identified a substantial problem/concern)

This stage examines the initiative in more detail in order to obtain further information where required about its potential adverse or positive impact from an equality perspective. It will help inform whether any action needs to be taken and may form part of a continuing assessment framework as the initiative develops.

Q1. What data/information is there on the target beneficiary groups/communities? Are any of these groups under- or over-represented? Do they have access to the same resources? What are your sources of data and are there any gaps?

Q2. Is there a potential for this initiative to have a positive impact, such as tackling discrimination, promoting equality of opportunity and good community relations? If yes, how? Which are the main groups it will have an impact on?

Q3. Will the initiative have an adverse impact on any particular group or community/community relations? If yes, in what way? Will the impact be different for different groups – e.g. men and women?

Q4. Has there been consultation/is consultation planned with stakeholders/ beneficiaries/ staff who will be affected by the initiative? Summarise (bullet points) any important issues arising from the consultation.

Q5. Given your answers to the previous questions, how will your plans be revised to reduce/eliminate negative impact or enhance positive impact? Are there specific factors which need to be taken into account?

Q6. How will the initiative continue to be monitored and evaluated, including its impact on particular groups/ improving community relations? Where appropriate, identify any additional data that will be required.

Guidelines: Things to consider

An initiative may have a positive impact on some sectors of the community but leave others excluded or feeling they are excluded. Consideration should be given to how this can be tackled or minimised.

It is important to ensure that relevant groups/communities are identified who should be consulted. This may require taking positive action to engage with those groups who are traditionally less likely to respond to consultations, and could form a specific part of the initiative.

The consultation process should form a meaningful part of the initiative as it develops, and help inform any future action.

If the EIA shows an adverse impact, is this because it contravenes any equality legislation? If so, the initiative must be modified or abandoned. There may be another way to meet the objective(s) of the initiative.

Further information:

Useful Websites www.equalityhumanrights.com Website for new Equality agency www.employers-forum.co.uk – Employers forum on disability www.efa.org.uk – Employers forum on age