The Change Control Policy is written inline with the IT Services Management (ITSM) Practices at the University of Suffolk. The policy is used to manage risk of changes made to corporate systems in production at the University.

1. Objectives
2. Scope of Change Control
2.1 Work In Scope
2.2 Out-of-Scope and Pre Approved Changes
2.3 Out of Scope
2.3. Pre-Approval Process
3. Exceptions to normal Change Control Procedures
4. Notice Periods for decisions
5. Change Approvers
5.1 Standard Workflow
5.2 Significant Changes
5.3 Change Approval Delegation
6. Information to include in a Change Request
6.1 Outage/Service Impact
6.2 Communication Plan
6.3 UAT
6.8 Fallback/Regression Plan
7. Schedule 1 – Change Approvers
8. Schedule 2 – Pre-approved Change Processes

Configuration and Change Management are a set of related processes that assist to achieve the following objectives:

  1. Maintain a detailed record of each system’s configuration; including software, hardware modules, components and subsystems.
  2. Control changes to systems. This includes a formal process for change requests, assessment, approval, implementation, test and release.
  3. Ensure an audit trail. This includes change requests, approvals, test results, installation/deployment dates, and post installation quality assurance tests.
  4. Facilitate life cycle management and operational consistency. This is verified by auditing installed systems against CMDB and CI configuration details.
  5. Provide oversight to ensure risk is appropriately managed and subjective risk is minimised, and changes are delivered in a manner that is well coordinated and protects the business.

This document describes the Change Control Policy as a subset of IT Services Management (ITSM) Practices at University of Suffolk.


Work in Scope

Change Control, broadly applies to non-routine work carried out on, or impacting, information systems or IT Services. It also applies to work that is routine in nature but carries a high degree of risk and therefore should be subject to change control. Whilst the topic and scope is too broad for an exhaustive prescribed list, examples include:-

  • Routine BaU work involving major patch releases (security and minor patches are not typically subject to Change Control);
  • Changing the implementation state of a system (e.g. new->implementation->production->decommissioned->obsolete);
  • Changes requiring downtime to a system, or carrying a risk of service disruption/downtime;
  • Changes expanding or contracting the use-case/scope of a system or service;
  • Changes significantly altering the configuration of a system or service;
  • Changes carrying an operational, health & safety, security or financial risk;
  • Changes otherwise impacting a production service in a way that is noticeable to end-users.


Out of Scope

Example ‘Business as Usual’ operational processes that are typically outside the scope of change control include:-

  • Password resets
  • Computer adds/moves/changes
  • Rebooting servers within an agreed downtime window, when there is no change to the system configuration
  • Data backup and restore operations (where the data is being manipulated on behalf of the original owner)


Pre Approval Process

Standard Changes (changes that are relatively low risk, follow a set process and are performed frequently) follow a pre-approval process, whereby approval is granted (tracked in iTop and Schedule 2 listed below) for a given period during which time the change may be carried out on repeat occasions without further change request approval being sought.

Whilst Standard Changes, once approved are not tracked through the iTop Change Request ticketing system, other documentation (such as user requests and incident tickets) should record subsequent Standard Change events.

IT Enterprise Services Staff operate under an IT Directive permitting deviation from normal change control procedures in circumstances where:-

  1. The organisation is affected by a Disaster (Fire/Flood/Other significant event impacting the organisation), or;
  2. The organisation is instructed to perform an action under the instruction of a statutory authority (Fire Brigade, Constabulary etc.) rendering information systems at risk, or;
  3. In the event a member of the team otherwise knows or has cause to believe Corporate Data, assets or information systems are at risk, or production services are unavailable or offline;

  4. Either the urgency of the situation requires immediate action rendering obtaining authorisation impractical, or staff have made reasonable endeavours to contact a member of the IT Management Team or the University Executive Team to obtain authorisation, but have been unsuccessful;

  5. The risk of not taking action, in the professional opinion of the actor outweighs the risk of taking action:-

Under these circumstances, IT staff are authorised to take such initial action they believe is necessary to resolve, mitigate or prevent a risk occurring, within scope of their expertise/competence and to the extent necessary to address the risk or restore service. Any action carried out in good faith under these circumstances will be supported by the IT Management Team as if change approval had been granted.

Minor Changes

Minor Changes should allow a minimum of 1.5 working days (12 business hours) from submission to approval.

Major Changes

Major Changes should allow a minimum of 1 working week (5 days), but depending on the nature of the change more notice may be required, particularly if the change needs to be referred to a Change Advisory Board (C.A.B.). If in doubt, discuss the Change with the Enterprise Services Manager before formal submission.

Emergency Changes

Wherever possible, expedited Change Decisions will be agreed verbally with the requestor, subject to retrospective written change requests being subsequently submitted covering the work verbally agreed.

External factors affecting notice periods

In all cases, impact to the business is the overriding concern for any change approval. Notice periods described above represent the minimum, and will need to be adjusted depending on the specific nature of the change, it’s impact on the business and any external lead times, dependencies or notice periods that the business requires.

Standard Workflow

Changes are normally approved by a member of the IT Services Management Team (listed in Schedule 1).


Significant Changes

In the case of significant changes, either in scope of impact or risk, Change Approval may be deferred to a Change Advisory Board, at the discretion of the Change Manager. A Change Advisory Board will typically comprise the Enterprise Services Manager, Head of IT and Director of IT, as well as any other business stakeholders determined necessary by those parties to ensure due diligence in any decision making process. In these circumstances, a change approval meeting will be held with the submitter to discuss the proposed change request, and determine an approval decision.


Change Approval Delegation

In the case of changes carried out in the context of a formal project management process, a restricted change approval mandate may be delegated to members of the Project Team, for changes falling within the scope of that project, and identified in advance. In these circumstances, a Change Request will be submitted and approved at the start of the project describing the scope of changes that have been delegated to the Project Team. Any subsequent approvals made under that authorisation will need to be recorded in the project documentation.

The following information should be considered and documented in any change request. Whilst the change request should demonstrate consideration of the areas described below, the level of detail required for a change request would be expected to be proportionate to the expected size, scale, impact and risk of the change. For example, complex or high-risk changes will be subject to a higher degree of scrutiny and oversight, and therefore usually require greater detail than simple or low-risk changes.

All Change Request workflow is controlled through the IT Services Management Information System, iTop.


Outage/Service Impact

Frequency, Duration and services affected by any planned outages should be explained. Outage Window needs to demonstrate consideration of business needs, in terms of timing, frequency and duration. In particular, the outage window timing needs to allow sufficient time where possible for affected users to be informed and have opportunity to plan around the outage.


The Communication Plan

The Change Request should identify impacted parties and any communications plans. Communications plan should cover:-

  • Target audience
  • Method(s) of communication (e.g. telephone, e-mail, face-to-face, my.ucs notice)
  • Timing
  • Summary of message to be communicated
  • Any response/feedback or approvals required (for example, H&S Permit to Work or LGA Planning Approval)


User Acceptance Testing (UAT) 

User Acceptance Testing should be described in the change request, in sufficient detail to demonstrate that adequate plans are in place to determine the outcome of a change. Depending on the complexity of the change request, this may be as simple as a single paragraph or as complex as as an attached schedule covering multiple checklist items. UAT Detail should pay particular attention to quantifying success in relation to any key risks identified.


Fallback/Regresion Plan

Fallback/regression plans should cover the steps that will be undertaken either to back-out changes, or to mitigate the effects of a change should the desired outcome not be achieved. The Change Manager will need to be satisfied that back-out plans demonstrate (a) a procedure that is practical and likely to succeed and (b) deliver a result sufficient to mitigate or reverse the effect of the change to the business.

In the event that a back-out plan includes restoring from backup or using DR facilities, the requestor will be expected to document that these facilities will be validated prior to approving the plan (e.g. checking there is a current/consistent replication snapshot or backup).

This schedule lists IT Management Team members with authority to approve change requests on behalf of the University of Suffolk



Karl Bayes

ICT Enterprise Services Manager

John Herd

Head of IT

Peter O’Rourke

Director of IT


In the event any Change Approver listed above is unavailable, or in an emergency, any current member of the Executive Team has authority to approve a Change Request.

IT Services mantains a list of pre-approved Change Control Processes.

Pre-approved Changes Processes will include a review date. Any Change Processes listed in the schedule of pre-approved changes that have an expired review date, should be considered revoked/cancelled and must not be carried out without a new Change Request Approval being granted beforehand.