Document Classification: Internal

Information Security Management System

Standard Operating Procedure

Business ISMS Author Information Security & Compliance

Process Change Management Process Owner Manager
Information Security Management
Document No. ISMS-SOP-No.2 Approved By
Forum
Revision No 1 2 3
25/10/18 22/01/19 02/10/19

To ensure that the security, reliability and availability of Wilson James’s IT networks and
systems are maintained through controlled change so we can achieve the aim of our
Information Security Policy.
Purpose
Failure to comply with the requirements set out in this procedure may result in disciplinary
action being taken against you, or, in the case of third parties, might be seen as a breach of
contract.

This procedure addresses all changes to Wilson James’s IT networks and systems. This includes
changes to hardware, software (including patches and fixes), and associated documentation
(e.g. technical specifications, operational manuals, and user guides). Software changes include
changes to third party software packages and internally developed software and also addresses
Scope
changes to operational (live) data that are made outside of the software application that is
associated with the data, e.g. direct SQL changes.
This policy does not address the reporting and fixing of IT faults. However, an IT fault could lead
to a hardware or software change, in which case, this policy applies.

It is the responsibility of the Process Owner to:

- Regularly review content to ensure document is current and up-to-date with current legal
and best practice requirements
- Carry out a formal annual review of content to ensure compliance and suitability.
Responsibility The Security & Compliance Manager shall ensure that this policy is up-to-date and relevant.
Wilson James IT shall ensure that this policy is followed for all changes to Wilson James’s IT
networks and systems.
All Wilson James managers, employees, contractors and third parties shall ensure that this
policy is applied for IT changes undertaken in their area of control.

Printed copies are uncontrolled

Document
It is the responsibility of the user to ensure that they are using the latest issue of this document
Control
and all referenced forms which are available in the WJ-IMS (Intranet).

IMS-SOP-No.2 Record Control identifies record keeping requirements for all documents used
Record Keeping
within this procedure.

Continuous Please send any process improvement suggestions to the Process Owner who will evaluate and
Improvement implement accordingly.

Associated
ISO27001: 2013
Standards

Revision 3 Document No: ISMS-SOP-No.2 Page 1 of 7

 Document Classification: Internal

Contents
Annual Review Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Document Change Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
CHANGE MANAGEMENT...........................................................................................................................................4
Types of IT Changes...............................................................................................................................................4
Raising Change Requests.......................................................................................................................................4
Feasibility and Impact Assessment of Change Requests........................................................................................4
Approval / Rejection of Change Requests..............................................................................................................5
Preparing for Operational Implementation of the Change....................................................................................5
Management Sign-off prior to Operational Change...............................................................................................6
Operational Implementation of the Change..........................................................................................................6
Change Request Closure........................................................................................................................................6
Retention of ‘Closed’ Change Requests.................................................................................................................6

APPENDIX A CHANGE CLASSIFICATION GUIDELINES..................................................................................................7

Annual Document Review Record

Confirmed that all documents have been reviewed and are current and up to date
Name Signed Date
Reviewed By Author

Approved by Process Owner

Document Change Record

Date Revision No. Page/Step No. Reason for and Details of Change

25/10/18 1 ALL First issue of this ISMS SOP.

Document Classification: Internal added to all pages

22/01/19 2 ALL Author/Process Owner changed to Information Security &
compliance Manager.

02/10/19 3 ALL CIO replaced with ISMF

Revision 3 Document No: ISMS-SOP-No.2 Page 2 of 7

 Document Classification: Internal

CHANGE MANAGEMENT

Types of IT Changes
Within Wilson James, there are 3 types of IT changes – Routine, Standard and Emergency. The main differences
between the 3 are the timescales for their implementation and the process followed to grant Change approval.
Emergency Changes (ECR’s) usually result from a requirement to apply a fix to a system or service to restore
service or prevent an outage.
An Emergency change is subject to approval by at least one member of the management team but may be
implemented with the actual change record being retrospectively completed in the interests of restoring service.
Standard Changes to existing systems and infrastructure require at least a 5 day lead time and will be fully
approved before they are implemented.
Routine Changes will initially be approved via the same process as a Standard change, but subsequent iterations
of this change will be contained within the same record and therefore not need to be ‘re-approved’.
‘Emergency’ changes are subject to retrospective assessment, approval and documentation in compliance with
this change management policy.

Raising Change Requests

All changes to operational IT services or components shall be initiated by the Requestor who will complete a
formal Change Request. The Requestor shall ensure that the appropriate approval for the implementation of the
change be sought and given prior to its implementation.
No Changes will be implemented without the requisite approval being given.

Special Note:
It is possible that at any time, the Change Request may be cancelled or rejected by the Requestor or by an
authorised person, e.g. the Requestor’s line Manager, or rejected by the Change Advisory Board (CAB). In all
cases, relevant parties shall be kept informed. If a Change Request is cancelled or rejected, then Wilson James IT
shall ensure that the status of the Change Request is updated.

Feasibility and Impact Assessment of Change Requests

All changes shall be formally assessed for their feasibility, risk and impact. Consideration shall be given to any
benefits and adverse effects on Wilson James’ business operations and security.

Classifying changes as Major or Minor will be based upon the Risk and Impact of the request. A Major change
would be classified as one that has a high risk in terms of potential user/service impact and is complex in its
nature. High impact would be a change where its failure would have significant effect on the service/users being
changed. A minor change is accordingly low risk/impact.

Wilson James IT shall ensure that a suitable Assessor(s) is appointed, and that the Change Request record is
completed. If necessary, further questions may be asked of the Requestor and the Manager who approved the
Change Request.

Revision 3 Document No: ISMS-SOP-No.2 Page 3 of 7

 Document Classification: Internal

Once the assessment is completed, the Assessor shall ensure that the status of the Change Request within the
Change system is updated.

Approval / Rejection of Change Requests

Wilson James IT shall make arrangements to regularly review Change Requests for approval or rejection based on
the outputs of feasibility, risk and impact assessments. Change Requests are formally reviewed on a weekly -
basis via the CAB meeting.
This will require the involvement of relevant staff within Wilson James IT. Where necessary i.e. because of the
seriousness of the change, e.g. significant financial costs, relevant senior management will also be involved in the
approval / rejection process.
Each approval and rejection shall be recorded on the relevant Change Request - record, including justifications for
each approval and rejection.
If unanimous agreement cannot be reached, the Change Request shall be
1. Rejected and feedback shall be given to the Requestor on the outcome and reasons as soon as possible; or
2. Further discussions shall be entered into between Wilson James IT and the Requestor to resolve the issues
that are preventing the approval of the Change Request.
If agreement is reached, Wilson James IT shall ensure that the decision to approve or reject the change is
communicated to the Change Requestor.
Once the approval / rejection process is completed for each Change Request, Wilson James IT shall ensure that
the status of the Change Request within the Change system is updated.

Preparing for Operational Implementation of the Change

Depending on the nature of the change, a number of activities are likely to be undertaken to prepare for
operational implementation of the change.

Any standard changes that could have an impact on the production environment will only be actioned within the
next maintenance window to reduce the perceived impact on the business. This may need an addition to the
original lead time as they will be applied in the next maintenance window after a period of a least 5 days.

Information Systems Acquisition, Development, Testing and Maintenance

When relevant to the change, staff shall comply with Wilson James’s Information Systems Acquisition,
Development, Testing and Maintenance Policy, which is separately documented.
Wherever possible, changes shall be tested in a test environment which is not a part of the production
environment. The environment shall be configured to be the same or similar to the production environment as
far as possible.
Any defects picked up by testing shall be passed back to the relevant party, e.g. third party software vendor,
internal project team, software development team. Once the defects have been addressed, the change shall be
re-tested. In most cases, this shall require a full re-test, but the re-testing may be reduced if authorised
representatives of Wilson James IT and / or relevant Business Units justify that a full re-test is unnecessary, in
which case, the decision and reasons shall be clearly marked in the test documents.

Revision 3 Document No: ISMS-SOP-No.2 Page 4 of 7

 Document Classification: Internal

Change Fall-back Process

Despite following a formal change management process, there remains a possibility that a change may not be
successfully implemented, and may lead to a ‘major’ problem i.e. the inability of Wilson James to continue
operating its business in a proper manner or the introduction of a significant security vulnerability. For these
reasons, it is important to ensure that Wilson James has a formal roll-back process in place to recover from a
problematic change.
This roll-back plan will be presented as part of the Change approval process and form part of the approval of the
overall change

IT Documentation Updates
All relevant IT documentation shall be updated by responsible parties to ensure that it is consistent with the
change. This includes, but is not limited to technical specifications, operational manuals, user guides, IT security
policy, procedures and guidelines, and business continuity plans and IT disaster recovery plans.

Management Sign-off prior to Operational Change

Wilson James’ readiness to implement an operational change shall be signed-off (approved) via the Wilson James
IT Change Management approval process before the change is implemented into operations. Those who are
responsible for sign-off shall ensure that all appropriate documentation is in place.
Once the operational change has been approved, Wilson James IT shall ensure that all affected users are
forewarned of the change timetable, and of any possible disruption to normal IT services. Notifications shall be
issued as soon as possible to provide affected users with enough time to make alternative arrangements, if
necessary.

Operational Implementation of the Change

Following approval, the change shall be implemented the implementation of the change shall be verified as
successful or otherwise by the Requestor’s / and implementer. Each successful implementation of the change
shall be recorded in the Change Request
If implementation problems occur, then the Requestor’s / implementers and Wilson James IT shall judge whether
the problem is a ‘minor’ problem (i.e. the problem is acceptable in the short-term, and can be remedied by a
‘minor’ change), or whether the problem is a ‘major’ problem which requires the ‘roll-back’ process to be
invoked. All parties with vested interests shall be kept informed of decisions made.
Upon successful implementation, the Change record shall be updated, including the status of the change.

Change Request Closure

When the change is fully implemented and proven to be stable, Wilson James IT shall ensure that the Change
Request is closed, and shall ensure that all vested parties are informed that the Change Request has been closed.
The Change record shall be updated, including the status of the change.

Revision 3 Document No: ISMS-SOP-No.2 Page 5 of 7

 Document Classification: Internal

Retention of ‘Closed’ Change Requests

Wilson James IT shall ensure that ‘Closed’ Change Requests are retained for at least 3 years.

Revision 3 Document No: ISMS-SOP-No.2 Page 6 of 7

 Document Classification: Internal

APPENDIX A

CHANGE CLASSIFICATION GUIDELINES

A change shall be classified as a ‘Routine’ change, a ‘Standard’ change or an ‘Emergency’ change, as follows.
‘Standard’ change
A ‘Standard’ change is a change that could lead to a significant security incident or significant disruption to Wilson
James’s services if the change is not properly managed.
‘Standard’ changes will be classified as Major or Minor based upon the Risk and Impact of the request. A Major
change would be classified as one that has a high risk in terms of potential user/service impact and is complex in
its nature. High impact would be a change where its failure would have significant effect on the service/users
being changed. A minor change is accordingly low risk/impact.
‘Standard’ changes include:
1. Installation of a new IT system
2. Replacement of an existing IT system
3. Upgrade of an existing IT system, e.g. upgrade of major hardware components (CPU, disk, memory) or a new
software release, module, patch or fix
4. Installation of a new IT network component, e.g. firewall, intrusion detection / protection system (IDS / IPS),
router, switch, external connection, or Virtual Local Area Network (VLAN)
5. Replacement of an IT network component
6. Upgrade of an IT network component, e.g. with a new software release
7. Change to application data outside of the application, e.g. via direct SQL
8. Change to IT security controls, e.g. reconfiguring firewall rulesets, authentication, access and audit logging
controls
9. Any change/addition/removal to/of a CI (Configuration Item) that is part of a live production system or
service used within Wilson James

‘Routine’ change
A ‘Routine’ change is a change that is highly unlikely to lead to a significant security incident or significant
disruption to Wilson James’s services. It is a change that does not impact on current security policies, procedures
and controls.
‘Routine’ changes include:
1. Installation of minor ‘tried and tested’ software modules, such as patches and fixes

‘Emergency’ change
An ‘Emergency’ change is a change that needs to be implemented into operations as soon as practically possible.
This is because the change is justified from a business and / or security perspective, e.g. following identification of
a significant flaw in software functionality or an important IT vulnerability. These types of change shall be kept to
a minimum. ‘Emergency’ changes are often subject to retrospective assessment, approval and documentation in
compliance with this change management policy.

Revision 3 Document No: ISMS-SOP-No.2 Page 7 of 7