:Approved by

<date of approval > Abdullatif Galadari

Information Technology Director
Document review and approval
Revision history
Version Author Date Revision
1.0 Neha Vyas 24th April 2014 Document Created
Reviewed the document and formatted the
Somaya AlWejdani 5th May 2014
1.1 template
1.2 Somaya AlWejdani 19th June 2014 Review and update
1.3 Somaya AlWejdani 23rd June 2014 Review and Update
1.4 Huda AlHamadi 17th July 2014 Review
1.5 Neha Vyas 20th July 2014 Review and Update
Abhinav
23rd Nov 2014 Reviewed & Updated
1.6 Srinivasaraghavan
Abhinav
16th May 2015 Revised
1.7 Srinivasaraghavan
1.8 Huda Alhamadi 7th Aug 2016 Added the user responsibilities

This document has been approved by

Version Name Signature Date reviewed
1.5 Abdullatif Galadari (IT Director) 4/8/2014
1.7 Abdullatif Galadari (IT Director) 16th- May-2015
1.8 Abdullatif Galadari (IT Director) 11th- August-2016

FEWA Internal
Page 2 of 12 Version 1.8
Table of Contents
1 PURPOSE.................................................................................................................................... 4
2 SCOPE........................................................................................................................................ 4
3 DEFINITIONS & ABBREVIATIONS................................................................................................. 4
4 ROLES AND RESPONSIBILITIES..................................................................................................... 4
5 CHANGE MANAGEMENT SCOPE.................................................................................................. 5
6 CHANGE MANAGEMENT POLICY................................................................................................. 6
5.1 CHANGE CONTROL PLANNED CHANGES...............................................................................................7
5.1.1 CHANGE REQUEST INITIATION - RFC.................................................................................................7
5.1.2 CHANGE VALIDATION - CAB MEETINGS.............................................................................................8
5.1.3 POST CAB MEETINGS....................................................................................................................8
5.1.4 CHANGE IMPLEMENTATION.............................................................................................................9
5.2 CHANGE CONTROL UNPLANNED CHANGES.........................................................................................10
5.3 CHANGE REPORTING........................................................................................................................10
5.4 CHANGE MONITORING.....................................................................................................................10
7 COMPLIANCE............................................................................................................................ 11
8 RELATED DOCUMENTS.............................................................................................................. 11

1 Purpose

This policy specifies the change management policy for the IT department at FEWA. Change
management establishes the process for controlling modifications to hardware, software,
firmware, and documentation to ensure the information resources are protected against
undocumented modification before, during, and after system implementation.
The purpose of Change Management is to ensure that all elements are in place, all parties
notified and trained, and the schedule for implementation is coordinated with all other
activities in the organization. The overriding goal is to provide a high level of availability and
service to FEWA employees.

FEWA Internal
Page 3 of 12 Version 1.8
2 Scope

This policy applies to all FEWA employees, contractors, consultants and temporary staf
hereafter referred to as users.

3 Definitions & Abbreviations

Term Definition
ISMS Information Security Management System
CISO Chief Information Security Officer
Change Advisory Board
CAB IT Director, CISO and the IT staf who are responsible for implementation of
the change will be a part of the CAB
RFC Request for Change
UAT User Acceptance Testing

4 Roles and Responsibilities

Role Responsibilities
Ensure the complete implementation and enforcement of this
policy on the users
CISO
Review of changes implemented with the IT Director on a
monthly basis
Review all requested changes and provide assessment of the
CAB expected business and technical risks associated with the RFC
Provide feedback as to the requested changes
The Change Requestor is responsible for providing sufficient
information on the change request
Change Requestor Assists the Change Manager and CAB in determining the RFC
priority and, at the conclusion of the change, participates in the
post-implementation review
The end users are responsible for:
Stakeholders / End-Users Assessment of the change impact
Provide UAT approval
Accountable for the overall process operation, including
Change Manager monitoring the process to identify and rectify issues and remove
bottle necks
All users are responsible to read, understand and adhere to

Users/Employees this policy in their day to day activities.

FEWA Internal
Page 4 of 12 Version 1.8
5 Change Management Scope

Change Management exists to coordinate and inform users of all changes that impact any
shared computing system or service (for example, servers and network devices) under the
custodianship of the organizations IT department.
The intended scope of the Change Management Process is to cover all of the FEWAs
computing systems and platforms. The primary functional components covered in the Change
Management process include, but not limited to, the following:

a) Project Management: Changes handled through the formal or informal FEWA IT

project management process (for production systems)

b) Hardware / IT Infrastructure - Installation, modification, removal or relocation of

network or server infrastructure devices

c) Software Installation, service packs, upgrade or removal of software products

including operating systems, access methods, commercial of-the-shelf packages,
internally developed packages and utilities

d) Database Changes to databases or files such as additions, reorganizations and major

maintenance

e) Application Application changes being moved to production as well as the integration

of new application systems and the removal of obsolete elements

f) System Configurations - Updates, additions, and deletion to system configuration files

g) Planned Changes - Requests for creation, deletion, or revision to job schedules, back-
up schedules or other regularly scheduled jobs managed by the IT Department.

h) Telephony Installation, modification, de-installation, or relocation of PBX equipment

and services.

i) Desktop Any modification (such as service packs) or relocation of desktop equipment

and services.

j) Generic and Miscellaneous Changes Any high impact changes that are required to
complete tasks associated with normal job requirements such as cabling changes,
environmental changes, etc.
The following may not be included within the scope of the change management process:

FEWA Internal
Page 5 of 12 Version 1.8
 a) Changes to non-production network or server infrastructure, services or resources.
b) Changes made within the daily administrative process. Examples of daily administrative
tasks are:
i. Password resets
ii. User adds/deletes
iii. User modifications
iv. Adding, deleting or revising security groups
c) Rebooting workstations when there is no change to the configuration of the system
d) Desktop operating system or application patches that are not service packs
e) File permission changes.
f) Desktop telephony moves, adds, and changes

The Change Advisory Board (CAB) may modify the scope periodically to include items in the
scope of the overall Change Management process.

6 Change Management Policy

Changes are essentially of two kinds: Planned and Unplanned. Planned changes are carried out
in a systematic manner. Unplanned changes must be avoided and must be carried out only in
case they are required to ensure that the production environment is not afected adversely.
Changes if not carried out in a secure manner, may afect the live/ production environment in
an adverse manner
This policy shall ensure that:
a) Potential impact of requested changes are assessed, especially with regard to:
i. Existing security controls;
ii. Other systems and applications that will be impacted and may require updates;
iii. Documentation updates.
b) Changes are only implemented after formal approval has been given by the IT Director
or by the person with delegated responsibility of the system, application, documents
c) Details of the changes are communicated to all relevant personnel to allow appropriate
reviews to take place before implementation;

FEWA Internal
Page 6 of 12 Version 1.8
 d) For system changes, that procedures and responsibilities for aborting and/or
recovering from unsuccessful changes are documented;
e) Record of authorization levels is maintained (who can authorize what);
f) Audit log is maintained of all change requests.

5.1 Change Control Planned Changes

A Planned change is carried out in a systematic manner. These changes are approved by the
CAB. The following steps are included in case of a planned change:
a) Change Request Initiation
b) Change Validation
c) Change Implementation
d) User Acceptance

5.1.1 Change Request Initiation - RFC

For any in scope (refer section 5.1) change requests an RFC (request for change) is required,
this RFC is to be added to the service desk software by the change manager. The following
items are required for the successful inclusion of an RFC:

a) Change Requestor name

b) Change category, this is the system/application/service that will be afected directly by
the change
c) IT Staf / vendor who will be lead for the change
d) Impact Analysis: This is the business, department, group or user who will be impacted
by the change
e) Urgency of the change: Urgency is a value that reflects how soon the defect shall be
resolved to avoid business consequences. This shall be discussed with the Change
Manager before entry
f) Services afected: The applications or services that will be directly or indirectly
impacted by the change
g) Change Type: Major, Minor, Significant or Standard

FEWA Internal
Page 7 of 12 Version 1.8
 h) Proposed start & end date and time
i) Title for the change: This should be meaningful and directly related to the change
taking place
j) Detailed description of the change to be taking place
k) Roll out Plan: A detailed roll out document should be attached
l) Related incident ticket information to the RFC (if applicable)
Once the RFC is completed and saved, it is the responsibility of the Change Manager to ensure
the RFC is distributed to the CAB members.

5.1.2 Change Validation - CAB meetings

CAB meetings shall take place whenever an RFC has been raised to validate the change request.
Typically this should be no longer than one hour in duration, but in certain cases with many
change requests this may run longer, this will depend on the number and complexity of the RFC
raised. When urgent major changes arise there may not be time to convene the CAB. For these
cases an ECAB should be identified with the authority to make emergency decisions.
The Change Manager shall provide the following to CAB members before the meeting:
a) Notify CAB members of meeting timings and agenda, including details on submitted
RFC
b) Minutes from last CAB meeting
c) Update report of failed changes, if any. Also provide an incident report (if there is one)
tracking the number of incidents related to a planned change
CAB members are expected to review all RFC prior to attendance at the meeting
The CAB meeting agenda shall include at least the following:
a) Discussion of all raised RFC awaiting CAB approval.
b) Review of accepted changes with proposed move to implementation date
c) Post implementation review of RFC from last meeting
d) Review of change calendar for any upcoming changes

Based on the change plan, impact analysis and conflict with other changes the CAB members
take a unanimous decision to Accept or Reject a change.

FEWA Internal
Page 8 of 12 Version 1.8
5.1.3 Post CAB Meetings

The Change Manager shall carry out the following activities following the CAB meeting:
a) Use the Service Desk software to send out the approval request to CAB members
b) Notify change requestor of change status, if the change is accepted or rejected
c) In the event of a rejection, the Change Manager shall clearly outline the reasons for
rejection and the requirements for resubmission to CAB, if there are any
d) In the event of acceptance, the Change Manager shall confirm the date and time of the
change, and prepare and send a notification e-mail to all data owners, service
stakeholders and impacted users notifying them of the planned change. Notification
should be given, where possible, at least 48 hours before the planned change
e) Update the change calendar to reflect any accepted changes or changes to schedule
for previously accepted changes
f) Create the meeting of minutes for the CAB meeting

CAB members are expected to carry out the following tasks following the meeting:

a) Through the Service desk software they are required to approve, or reject the
proposed change
b) The CAB members should also include any notes for the approvals that they think are
relevant, or that were discussed within the meeting

5.1.4 Change Implementation

The IT staf is responsible for the implementation of any approved/accepted changes. All
changes shall be carried out at the agreed date and time, deviation from the agreed schedule is
not permitted unless approved by CAB.

As a part of implementation of the change:

a) All tasks are carried out as part of the change; this shall be recorded on the Service
desk software under the correct RFC number.

FEWA Internal
Page 9 of 12 Version 1.8
 b) Work log is maintained for the change, this shall be logged in Service desk software
under the correct RFC number. This work log will contain information on any technical
details / IT staf / vendor staf that were involved in the change.
c) All changes shall be testing in the test environment before migrating to production.
Result of the testing of the changes shall be documented.
d) UAT approval shall be taken from the change requestor/ stakeholders / end-user, if
applicable
e) Success/Failure of the planned change should be reported to the Change Manager,
including any relevant information on this status
f) Update system documentation or user manuals to reflect any changes , if applicable

5.2 Change Control Unplanned Changes

a) Unplanned changes must be carried out only in case there are critical production
issues, hardware failure at a crucial period which require the change to be carried out.
b) Approval may be taken from any CAB member in case of an unplanned change. This
approval may also be taken verbally. However, after unplanned changes are carried
out, normal change procedures must be expedited.
c) Unplanned changes must be documented and reviewed subsequent to the change.
d) In case of emergencies, a request for change can be raised through an email addressed
to the CISO and IT director.
e) Only authorized persons should be allowed to do emergency changes.
f) All emergency changes should be ratified through normal change management
procedures afterwards to analyze the emergencies.

5.3 Change Reporting

The Change Manager is responsible for providing monthly reporting on the change
management process to CAB. This should contain the following information:
a) Total volume of change requests, including category.
b) Monthly change requests accepted.
c) Monthly change requests declined.

FEWA Internal
Page 10 of 12 Version 1.8
 d) Success/failure percentage for accepted changes.
e) Details of failed changes

5.4 Change Monitoring

Every change request shall be monitored throughout the process for:

a) CAB approvals
b) Impact assessment and feasibility study
c) User acceptance test and other tests, if applicable
d) Turnaround time to carry out the change

Also on a periodic basis the process should be monitored to measure:

a) Average turnaround time of Change request
b) Number of completed changes as against the pending ones
c) Number of emergency changes addressed

Also a periodic CAB review shall be taken for:

a) Number of deviations from the standard configuration
b) Number of emergency fixes for which the normal change management process was
not applied
c) Number of errors introduced into systems due to changes
d) Ratio of accepted to refused change requests
e) Number of disruptions (loss of availability) caused by poorly managed change.
f) Reduced number of emergency fixes

7 Compliance

All users shall comply with this policy. In case of breach/violation to this policy, the user shall be
subjected to investigation and disciplinary action supervised by HR. HR disciplinary actions and
procedures apply. Violations shall be notified directly to IT Support and HR.
Strict confidentiality shall be maintained on all notified violations.

FEWA Internal
Page 11 of 12 Version 1.8
8 Related Documents
FEWA_ISMS_Change Management Procedure
FEWA_ISMS_Change Request Form
FEWA_ISMS_Management Review Form

FEWA Internal
Page 12 of 12 Version 1.8